Periodic connection drops for specific client
-
Yeah with Derelict here - while there are times that you might want to adjust the arp cache time, or set a static arp entry.
This is not any sort of fix to your problem of why your having issues with arp in the first place..
-
Thanks for the responses guys. Indeed, even though static entries seem to eradicate the issue, there is no actual justification why this would be required.
To be honest, I was thinking of digging into the ARP resolution/traffic on specific interfaces on both the client and firewall. I will keep this post updated.
The most "annoying" thing with this timeout is that the client experiences total connection for about a minute or so, however a new entry is registered on the firewall side eventually.
Any thoughts or ideas on what to look for specifically (if that rings any bell) and/or how to troubleshoot this further are more than welcome!
-
Well I would prob set the arp cache time to something much lower than 20 minutes so you could get more info to work without having to wait 20 minutes between..
Then watch the traffic via sniff on both firewall interface and your client.. Are you seeing the arps go out, and seen on the other end - but not getting answered, or answered by the sender never gets the reply?. Or is the devices not even sending arp out?
Do you have an issue with dupe IP or something using the same mac? etc.. Do you have something flapping between interfaces moving a vitual mac around?
-
OK so what I have seen so far is the following:
- I set the cache timeout to 120sec for troubleshooting.
- 5 seconds before the timeout, pfsense generates some ARP requests (broadcast) to ff:ff:ff:ff:ff:ff. However, no requests are seen on the client interfaces.
- At some point, depending on the client, each makes an ARP request to pfsense to find out where the gateway is. When this happens pfsense updates the cache and everything is good.
- On MacOS clients, no issue is observed because apparently it generates an ARP request every 1m30sec (at least the clients I have tested with).
- On Linux and Windows clients, the same behavior is observed, i.e. pfsense is trying to find out their MAC addresses, but on Windows the client generates an ARP request much faster than the Linux client (that's why that linux client experiences losses).
- The Linux client, when on a wired connection, it sends an ARP request to find out the gateway every 20sec on VLANx. On a different VLANy (again wired), the client responds properly when pfsense sends a broadcast and the client does not initiate ARP requests on the other hand.
I hope some of it makes sense. I'm still testing some other scenarios to verify the setup.
-
If the broadcast ARP request is not making it to the client it obviously cannot respond.
The problem is in your Layer 2 (switches, wifi, etc)
-
@salousama said in Periodic connection drops for specific client:
5 seconds before the timeout, pfsense generates some ARP requests (broadcast) to ff:ff:ff:ff:ff:ff. However, no requests are seen on the client interfaces.
And the client is wireless? Your AP could be preventing the arp from going out on the wifi? But allow clients arp from wireless to be sent to your wired network.
unifi for example has a setting to block broadcast/multicast from lan to wlan.. Because broadcast is sent at low data rate.. What specific wifi AP are you using?
Such a scenario would explain that point you made.. If your client having the issue is wireless.
-
@johnpoz Thanks for the response. Yes the client is wireless, so it only makes sense that the AP is doing something. Unfortunately, I have a TL-WA901ND in multi-sssid mode (connecting to a D-Link 1100-08).
I'm going to replace it soon from what I'm seeing, for example its LAN interface broadcasts to its controlled VLANs (the multi-sssid mode) :) I have a client on VLANx and it captured the native VLAN broadcast ...
-
@salousama said in Periodic connection drops for specific client:
TL-WA901ND
Yeah tplink and how vlans work seems to be an issue with their budget gear atleast.. Their entry level smart switches wouldn't allow you to remove vlan 1 from ports.
So yeah get some real AP if you want to do vlans would be my suggestion.
-
That's probably the next step indeed..Apparently the AP does not understand the tagging from the firewall, one example of this is the following:
- port 1 on the switch is the trunk port for pfsense.
- port 8 is the trunk port for the AP.
- VLAN99 has port 1 (tagged) and 7, 8 untagged (typically it should be the native VLAN, but without port 1 tagged one cannot get DHCP from port 7).
- VLAN60 has port 1 and port 8 tagged.
- Management interface of the AP receives an IP from VLAN99 (for example 192.168.99.x).
From the firewall, if I do some arping on vlan60 and vlan99 e.g:
arping -i iface.60 192.168.60.x arping -i iface.99 192.168.60.x
No arp requests reach the clients wireless interfaces as we've discussed above in the first case, however in the second case all requests are visible to the clients :)
# firewall arping -i iface.60 192.168.60.x ARPING 192.168.60.x Timeout Timeout ... # Client sees no traffic
# Firewall arping -i iface.99 192.168.60.x ARPING 192.168.60.x Timeout Timeout # Client sees the requests, however the firewall reports Timeouts above, the ARP table is refreshed though. xxx FW_MAC > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.60.x tell 192.168.99.1, length 46 xxx CLIENT_MAC > FW_MAC, ethertype ARP (0x0806), length 42: Reply 192.168.60.x is-at CLIENT_MAC, length 28 xxx FW_MAC > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.60.x tell 192.168.99.1, length 46 xxx CLIENT_MAC > FW_MAC, ethertype ARP (0x0806), length 42: Reply 192.168.60.x is-at CLIENT_MAC, length 28
I was thinking maybe the switch was misconfigured, but I can verify the AP having the same issue with multiple configs...
Anyway, I'm just providing some context for completeness. Again thanks @johnpoz for the support.
-
I'm seeing the same behavior on my network for both wired and wireless clients.
https://forum.netgate.com/topic/157090/periodic-drops/4Thank you for this post, it let me isolate the cause of the network disruption. I'm still not sure what the root cause is, but at least I have a starting point.