Fresh Install of 7.4 - Can't ping gateway - No internet access

[jsalas424]

I used the latest iso for did a fresh install. I used the network setup options part of the installer with the following parameters:

Address: 192.168.1.10/24
Gateway: 192.168.1.1
DNS: 192.168.1.1

I can connect to the web portal with 192.168.1.10:8006:


The gateway (pfsense) can ping the server:

PING 192.168.1.10 (192.168.1.10): 56 data bytes
64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=0.146 ms
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.122 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.140 ms

--- 192.168.1.10 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.122/0.136/0.146/0.010 ms

But there seems to be a unidirectional block, the server can't ping the gateway:

root@pveserver01:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10245ms

The pfsense logs show that it received a lease:


Even more confusing, I can still ping the other devices on this subnet:

root@pveserver01:~# ping 192.168.1.15
PING 192.168.1.15 (192.168.1.15) 56(84) bytes of data.
64 bytes from 192.168.1.15: icmp_seq=1 ttl=64 time=0.400 ms
64 bytes from 192.168.1.15: icmp_seq=2 ttl=64 time=0.422 ms
64 bytes from 192.168.1.15: icmp_seq=3 ttl=64 time=0.318 ms
^C
--- 192.168.1.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.318/0.380/0.422/0.044 ms

And of course, those devices can ping the gatway:

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2.256 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.342 ms

More verbose version of my networking config:

root@pveserver01:~# cat  /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface eno1 inet manual

iface enp3s0f0 inet manual

iface enp3s0f1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Some supporting details:

root@pveserver01:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 18:03:73:32:b6:7c brd ff:ff:ff:ff:ff:ff
    altname enp0s25
3: enp3s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 68:05:ca:01:41:b6 brd ff:ff:ff:ff:ff:ff
4: enp3s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 68:05:ca:01:41:b7 brd ff:ff:ff:ff:ff:ff
5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 18:03:73:32:b6:7c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::1a03:73ff:fe32:b67c/64 scope link
       valid_lft forever preferred_lft forever
root@pveserver01:~# ip route
default via 192.168.1.1 dev vmbr0 proto kernel onlink
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.10

 

[bbgeek17]

Can you ping from Proxmox to other device?
There is nothing in Proxmox standard setup that would block outgoing ICMP, its likely that you either have a strange rule on pfsense, or a duplicate IP in the network.
Examine your ARP tables, or give arp-scan a try.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[jsalas424]

Yes I can ping other devices, there’s a code chunk in there showing the results of pinging 192.168.1.15

I see the pveserver in the ARP table and no duplicates:


But just to be safe, I cleared the ARP table. That didn't help.

 

[jsalas424]

Here's an interesting something. My ARP monitor sent me a "Arpwatch Notification : flip flop" message:

           hostname: pveserver01.TracheNet
         ip address: 192.168.1.10
   ethernet address: 18:03:73:32:b6:7c
    ethernet vendor: Dell Inc.
old ethernet address: c2:c8:66:bb:9e:de
old ethernet vendor: <unknown>
          timestamp: Thursday, March 23, 2023 22:36:04 -0400
 previous timestamp: Thursday, March 23, 2023 22:24:02 -0400
              delta: 12 minutes
             
           hostname: pveserver01.TracheNet
         ip address: 192.168.1.10
   ethernet address: c2:c8:66:bb:9e:de
    ethernet vendor: <unknown>
old ethernet address: 18:03:73:32:b6:7c
old ethernet vendor: Dell Inc.
          timestamp: Thursday, March 23, 2023 22:37:07 -0400
 previous timestamp: Thursday, March 23, 2023 22:37:07 -0400
              delta: 0 seconds

But ip addr now suggests that it's still the mac address starting in 18: which is the one in my DHCP config:

root@pveserver01:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 18:03:73:32:b6:7c brd ff:ff:ff:ff:ff:ff
    altname enp0s25

Looks like this shows up as two mac addresses for the same device?

 

[bbgeek17]

Looks like this shows up as two mac addresses for the same device?

that would be the duplicate IP. Shutdown PVE, wait a bit and see if you can identify the device through open tcp/port or some other way.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[jsalas424]

that would be the duplicate IP. Shutdown PVE, wait a bit and see if you can identify the device through open tcp/port or some other way.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

The "other" mac address that flashes in "c2:c8:66:bb:9e:de" seems to be what gets assigned to both the VLANs and some ethernet connected devices. I don't think this is a duplicate we're hunting down but worth the hunt.




So I cleared all DHCP leases, restart the DHCP service, and cleared the ARP table just to play it safe. Didn't help.

The other odd thing I see is that the pveserver (192.168.1.10) is being assigned a "Permanent" status in the ARP table instead of how my other hardwired devices appear, with expirations. I wondered if having a static DHCP lease in was causing this, but even after removing it that didn't change:

 

[shanoviachan]

Hi, seems the issue described here is similar to mine. Besides i cannot even ping the server from pfsense. It just appears in the ARP table and seems to get a lease.


In my temporary setup, the server would need to be on subnet 60 (usually WLAN but for testing reason that subnet is currently also assigned to my ethernet port)


EDIT: I have reactivated my fritzbox as a router to see if the issue disappears and it does. Looks like the issue is somehow in pfsense routes or rules. I am not pro enough to figure out what might be wrong but eventually @jsalas424 can based on this feedback?

 

[N0REAVER]

I had a similar issue and the problem was in the DHCP Server if you have checked the:
[ ] Enable Static ARP entries
and you didn't have static dhcp leases for those hosts.

 

[xinutel]

I solved this problem by flushing the arp table on my OPNSense router.