Connectivity lost after clearing ARP table
-
I performed successful dirty update from 2.7.2.
However, i discovered that going to Diagnostics / ARP Table and clearing ARP table breaks access to web gui and i also lose network access completely. I have 10 VLANs configured, and none of the devices on those VLANs have access to internet either. Hard rebooting the machine manually restores the access and everything continues to function normally. I have static DHCP entries created for all devices and i also enabled static ARP entry. I thought that static ARP entries could be an issue so i removed them all, restarted device, tried doing ARP clening again and same thing happens. No network no access to gui.
The interesting part is, i have management VLAN configured and if i clear arp table, i can still connect to that network and i still have access to pfsense gui. The only difference between this VLAN and every other is the priority that i set to 7.
Also. If i log into pfsense through management network and then go to System / General Setup and just click save without changing any setting, connection is getting immediately restored on all VLANs and everything works just like when i reboot.
If you need any logs, just let me know which ones and i will upload them.
-
Moved to a separate thread.
I can't replicate that.
How do you have that device configured? Are you able to connect out from the console after doing that?
Does it connect again after ARP expires (~20mins)?
Do you have static ARP set for any devices/leases?
-
@stephenw10 said in Connectivity lost after clearing ARP table:
Moved to a separate thread.
Sry. Didnt get any notification that post was moved.
How do you have that device configured? Are you able to connect out from the console after doing that?
If by console you mean remote SSH, i cant cannect to it. I can connect directly to it via serial and i can also log in directly. This is Protectli FW6E.
Does it connect again after ARP expires (~20mins)?
I havent tested that.
Do you have static ARP set for any devices/leases?
Yes. But as i said in original post, removing them doesnt solve a problem.
-
@nimrod said in Connectivity lost after clearing ARP table:
If by console you mean remote SSH, i cant cannect to it. I can connect directly to it via serial and i can also log in directly.
Yes, I meant on the serial console. If's losing all ARP entries that might include the gateway IP. if you try to ping out from the console it would fail with an error.
You could also run
arp -a
from the console to see what values it has there after clearing the table from the webgui.What I expect to happen here is that pSense will send ARP queries for any IP not in the table and immediately re-populate it. So if that isn't happening those might be blocked somehow or you have some odd config option telling it not to. Or something else unexpected!
-
@stephenw10 said in Connectivity lost after clearing ARP table:
@nimrod said in Connectivity lost after clearing ARP table:
If by console you mean remote SSH, i cant cannect to it. I can connect directly to it via serial and i can also log in directly.
Yes, I meant on the serial console. If's losing all ARP entries that might include the gateway IP. if you try to ping out from the console it would fail with an error.
It is not failing. I pinged all gateways and interfaces and i got response from all of them. Pinging google dns also works. I was even able to to
pkg update
and i got this:[2.8.0-BETA][admin@pfSense.home.arpa]/root: pkg update Updating pfSense-core repository catalogue... Fetching meta.conf: 0% Fetching data.pkg: 0% pfSense-core repository is up to date. Updating pfSense repository catalogue... Fetching meta.conf: 0% Fetching data.pkg: 0% pfSense repository is up to date. All repositories are up to date.
You could also run
arp -a
from the console to see what values it has there after clearing the table from the webgui.Running
arp -a
before cleaning returns this:[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a ? (192.168.5.1) at mac_address on igb0 expires in 1187 seconds [ethernet] ? (192.168.5.3) at mac_address on igb0 permanent [ethernet] ? (192.168.1.200) at a mac_address on igb1 permanent [ethernet] pfSense.home.arpa (192.168.1.1) at mac_address on igb1 permanent [ethernet] ? (192.168.1.210) at mac_address on igb1 permanent [ethernet] ? (192.168.8.1) at mac_address on igb4 expires in 1194 seconds [ethernet] ? (192.168.8.103) at mac_address on igb4 permanent [ethernet] ? (10.10.50.150) at mac_address on igb5 permanent [ethernet] ? (10.10.50.10) at mac_address on igb5 permanent [ethernet] ? (10.25.0.19) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.18) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.17) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.16) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.20) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.1) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.11) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.10) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.15) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.14) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.13) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.12) at mac_address on igb5.25 permanent [vlan] ? (10.35.0.200) at mac_address on igb5.35 permanent [vlan] ? (10.35.0.1) at 0 mac_address on igb5.35 permanent [vlan] ? (10.35.0.100) at mac_address on igb5.35 permanent [vlan] ? (45.1.1.5) at mac_address on igb5.45 permanent [vlan] ? (45.1.1.1) at mac_address on igb5.45 permanent [vlan] ? (10.65.0.1) at 0 mac_address on igb5.65 permanent [vlan] ? (192.168.10.1) at mac_address on igb1.75 permanent [vlan] ? (192.168.10.100) at mac_address on igb1.75 permanent [vlan] ? (192.168.10.200) at c mac_address on igb1.75 permanent [vlan] ? (192.168.10.175) at mac_address on igb1.75 expires in 1156 seconds [vlan] ? (60.0.0.100) at bc: mac_address on igb5.100 permanent [vlan] ? (60.0.0.1) at mac_address on igb5.100 permanent [vlan] ? (70.0.0.5) at mac_address on igb5.200 permanent [vlan] ? (70.0.0.1) at mac_address on igb5.200 permanent [vlan] ? (10.85.0.20) at mac_address on igb5.85 permanent [vlan] ? (10.85.0.10) at mac_address on igb5.85 permanent [vlan] ? (10.85.0.1) at mac_address on igb5.85 permanent [vlan] ? (10.1.1.200) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.1) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.100) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.101) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.250) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.210) at mac_address on igb5.55 permanent [vlan] ? (10.1.1.150) at mac_address on igb5.55 permanent [vlan]
Running
arp -a
after cleaning returns this:[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a ? (192.168.5.1) at mac_address on igb0 expires in 1193 seconds [ethernet] ? (192.168.5.3) at mac_address on igb0 permanent [ethernet] pfSense.home.arpa (192.168.1.1) at mac_address on igb1 permanent [ethernet] ? (192.168.8.1) at mac_address on igb4 expires in 1192 seconds [ethernet] ? (192.168.8.103) at mac_address on igb4 permanent [ethernet] ? (10.10.50.150) at mac_address on igb5 expires in 1012 seconds [ethernet] ? (10.10.50.10) at mac_address on igb5 permanent [ethernet] ? (10.25.0.19) at mac_address on igb5.25 expires in 955 seconds [vlan] ? (10.25.0.16) at mac_address on igb5.25 expires in 966 seconds [vlan] ? (10.25.0.20) at mac_address on igb5.25 expires in 822 seconds [vlan] ? (10.25.0.1) at mac_address on igb5.25 permanent [vlan] ? (10.25.0.11) at mac_address on igb5.25 expires in 799 seconds [vlan] ? (10.25.0.10) at mac_address on igb5.25 expires in 830 seconds [vlan] ? (10.25.0.14) at mac_address on igb5.25 expires in 1162 seconds [vlan] ? (10.25.0.13) at mac_address on igb5.25 expires in 916 seconds [vlan] ? (10.35.0.1) at mac_address on igb5.35 permanent [vlan] ? (45.1.1.5) at mac_address on igb5.45 permanent [vlan] ? (45.1.1.1) at mac_address on igb5.45 expires in 1180 seconds [vlan] ? (10.65.0.1) at mac_address on igb5.65 permanent [vlan] ? (192.168.10.1) at mac_address on igb1.75 permanent [vlan] ? (192.168.10.100) at mac_address on igb1.75 expires in 851 seconds [vlan] ? (192.168.10.175) mac_address on igb1.75 expires in 1031 seconds [vlan] ? (60.0.0.100) at mac_address on igb5.100 expires in 1193 seconds [vlan] ? (60.0.0.1) at mac_address on igb5.100 permanent [vlan] ? (70.0.0.5) at mac_address on igb5.200 expires in 955 seconds [vlan] ? (70.0.0.1) at mac_address on igb5.200 permanent [vlan] ? (10.85.0.10) at mac_address on igb5.85 expires in 1101 seconds [vlan] ? (10.85.0.1) at mac_address on igb5.85 permanent [vlan] ? (10.1.1.1) at mac_address on igb5.55 permanent [vlan]
Normally my ip address is 10.1.1.100. Thats what i assigned to myself. As you can see, that ip address is missing when i clear arp. Even when i connect that that 10.1.1.1/24 subnet it never shows up in ARP table. Restarting DHCP service also fixes the problem. I use ISC btw.
What I expect to happen here is that pSense will send ARP queries for any IP not in the table and immediately re-populate it. So if that isn't happening those might be blocked somehow or you have some odd config option telling it not to. Or something else unexpected!
This was not an issue in 2.7.2. Never had problems when i cleared arp table. It started when i updated to beta. No configuration changes have been made aside from updating.
As for the settings, i use pfblocker. Disabling it makes no difference. I have several wireguard and openvpn client instances connecting and working as it should. I have several vlans as you see above and all of them are in different subnets. All devices have dhcp static entries with static arp enabled. As i said, before, disabling static arps makes no difference. It still hangs when clearing.
-
@nimrod said in Connectivity lost after clearing ARP table:
? (10.1.1.100) at mac_address on igb5.55 permanent [vlan]
Mmm, all those are permanent entries when I'd expect them to be learned. Are they all static DHCP leases with static ARP set? Are you running Kea?
Even, with al that if the ARP entry isn't in the table it should send a request for it. As long as it's in the local subnet.
@nimrod said in Connectivity lost after clearing ARP table:
Even when i connect that that 10.1.1.1/24 subnet it never shows up in ARP table.
What exactly do you mean by that? Isn't that the interface address for igb5.55?
-
@stephenw10 said in Connectivity lost after clearing ARP table:
@nimrod said in Connectivity lost after clearing ARP table:
? (10.1.1.100) at mac_address on igb5.55 permanent [vlan]
Mmm, all those are permanent entries when I'd expect them to be learned. Are they all static DHCP leases with static ARP set? Are you running Kea?
Correct. All are static dhcp entries with static arp enabled. All except vlan 65 which is wireless guest network. And no, im not running kea.
Even, with al that if the ARP entry isn't in the table it should send a request for it. As long as it's in the local subnet.
@nimrod said in Connectivity lost after clearing ARP table:
Even when i connect that that 10.1.1.1/24 subnet it never shows up in ARP table.
What exactly do you mean by that? Isn't that the interface address for igb5.55?
Let me try and explain.
My pc is connecting to igb5.55 via managed switch that has a port tagged with vlan 55. As soon as i plug my network cable into that port, i get the static ip address 10.1.1.100 from pfsense. And this was working flawlessly before update, and it still works until i perform arp clean. Only when i perform arp clean, then i lose all connectivity on vlan 55. If i unplug the cable and then plug it back in, i still receive ip address from pfsense but im still not able to reach any network. Internal or external until i restart dhcp server.
I also have another port on a switch tagged with vlan 75 (management vlan) and this is where i plug my pc cable in order to regain access to pfsense gui and ssh. This vlan 75 or network 192.168.10.1/24 is not affected by arp resetting.
So if you look at the first
arp -a
output you can clearly see my pc address 10.1.1.100. But after cleanup, that address is no longer there even though dhcp is assigning it after the cleanup. Only when i reset dhcp service i can see 10.1.1.100 when i runarp -a
. -
Hmm, interesting. So you actually see that address shown as current in the dhcp leases after reconnecting? But it's not in the arp table?
If you try to ping out from pfSense to 10.1.1.100 does that re-create the arp table entry?
The dhcp lease is odd because that implies pfSense has sent some traffic to the client and must have known the MAC to do so.
Is there any reason you are using static ARP entries?
-
@stephenw10 said in Connectivity lost after clearing ARP table:
Hmm, interesting. So you actually see that address shown as current in the dhcp leases after reconnecting? But it's not in the arp table?
If you try to ping out from pfSense to 10.1.1.100 does that re-create the arp table entry?
ping -c5 10.1.1.100
before clearing arp table is successful as you can see below:[2.8.0-BETA][admin@pfSense.home.arpa]/: ping -c5 10.1.1.100 PING 10.1.1.100 (10.1.1.100): 56 data bytes 64 bytes from 10.1.1.100: icmp_seq=0 ttl=64 time=3.432 ms 64 bytes from 10.1.1.100: icmp_seq=1 ttl=64 time=1.838 ms 64 bytes from 10.1.1.100: icmp_seq=2 ttl=64 time=1.840 ms 64 bytes from 10.1.1.100: icmp_seq=3 ttl=64 time=1.898 ms 64 bytes from 10.1.1.100: icmp_seq=4 ttl=64 time=79.029 ms --- 10.1.1.100 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.838/17.607/79.029/30.717 ms [2.8.0-BETA][admin@pfSense.home.arpa]/:
Executing
ping -c5 10.1.1.100
after cleanup does not recreate arp entry and there is no response.[2.8.0-BETA][admin@pfSense.home.arpa]/: ping -c5 10.1.1.100 PING 10.1.1.100 (10.1.1.100): 56 data bytes ping: sendto: Invalid argument ping: sendto: Invalid argument ping: sendto: Invalid argument ping: sendto: Invalid argument ping: sendto: Invalid argument --- 10.1.1.100 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss [2.8.0-BETA][admin@pfSense.home.arpa]/:
And again, restarting dhcp server brings everything back to life.
The dhcp lease is odd because that implies pfSense has sent some traffic to the client and must have known the MAC to do so.
Ok. Im currently connected to vlan 55 network and everything is working fine.
I executed
arp -a |grep 10.1.1.100
and my pc address is clearly showing up in arp table as you can see below:[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a |grep 10.1.1.100 ? (10.1.1.100) at mac_address on igb5.55 permanent [vlan] [2.8.0-BETA][admin@pfSense.home.arpa]/:
Then i log into pfsense web gui and perform arp clean and i immediately lose all connectivity. I then go to my switch, pull out the network cable and plug it into a port that has vlan 75 (management vlan) assigned to it, and now im able to access web gui and connect via ssh.
Once logged into a console, i executed
arp -a |grep 10.1.1.100
and i got no search results for my ip as you can see below:[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a |grep 10.1.1.100 [2.8.0-BETA][admin@pfSense.home.arpa]/:
Just to make sure that im receiving ip address from pfsense dhcp, i plug my cable back into a vlan 55 tagged port without resetting any services, and i receive ip address, but there is no connectivity at all. Then i execute
arp -a 10.1.1.100
just to make sure that ip address is not there, and sure enough, its missing as you can see below:[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a | grep 10.1.1.100 [2.8.0-BETA][admin@pfSense.home.arpa]/:
Now i go back to my switch again, i disconnect the cable from vlan 55 network, and plug it back into my vlan 75 management network. Then i connect to pfsense via web gui and restart dhcp service. I reconnect my cable back to my vlan 55 network and all connectivity is restored. Of course, executing
arp -a |grep 10.1.1.100
produces this output again.[2.8.0-BETA][admin@pfSense.home.arpa]/: arp -a |grep 10.1.1.100 ? (10.1.1.100) at mac_address on igb5.55 permanent [vlan] [2.8.0-BETA][admin@pfSense.home.arpa]/:
Is there any reason you are using static ARP entries?
For security reasons.
However, connection still hangs with or without static arp entires. It makes no difference at all.