pfSense not responding to some ARP requests
-
@keyser I’m hesitant to do this. This is a lot of config tired to the existing LAGG interface and its associated VLANs. Hundreds of firewall rules, suricata rules, pfsense and package configurations….
I’m also thinking the other tests have ruled out the LAGG as an issue: running with only one cable/port pair connected, seeing the arp request packets are making it all the way to pfsense based on the pfsense pcap.
Is there a reason to suspect the LAGG config in pfsense is the source of issue — and if it turns out to be, is there a path to fixing it?
-
@rtadams89 I'm not saying the LAGG pfsense config is the culprit, I'm saying the switch <-> pfsense LAGG interaction is the culprit. That is usually the case in scenarios/symtomps like yours. But the problem can be on either side in terms of config inconsistency (usually the problem).
But it can be - albeit theoretical - hardware/LAGG implementation inconsistency. -
@keyser ahh I see what you are saying. If just disconnecting one cable isn’t enough, I should be able to delete 1 of the physical interfaces out of the LAGG assignment on the pfsense side, leaving a LAGG with just one physical interfaces assigned (will pfsense let me do that?), break the LAGG config on the switch, and just keep the cable connecting the pfsense LAGG to the switch in place. Does that plan work?
-
@rtadams89 said in pfSense not responding to some ARP requests:
@keyser ahh I see what you are saying. If just disconnecting one cable isn’t enough, I should be able to delete 1 of the physical interfaces out of the LAGG assignment on the pfsense side, leaving a LAGG with just one physical interfaces assigned (will pfsense let me do that?), break the LAGG config on the switch, and just keep the cable connecting the pfsense LAGG to the switch in place. Does that plan work?
Exactly, that should work. But using the LAGG with only one link defined is still a LAG, and likely exibits the same problem. So you need step 2 by defining the VLAN tags on the free’d up link, and use that for uplink instead.
-
@keyser There is no practical way for me to completely eliminate the LAGG (too many things tied to the LAGG virtual interface on the pfsense side), but I did the following -- disconnected one of the two Ethernet cables previously part of the LAGG. Removed all the LAGG configuration on the switch side. As such, the Switch thinks it just has a single uplink to pfSense, and pfsense sees only one active physical link in it's LAGG group to the switch. The problem persists. I can still see the ARP request packets making it to pfsense (based off a pfsense packet capture on that interface) and no ARP reply going back out.
As I think through this, the fact that a tcpdump running on pfsense shows the ARP request coming in eliminates any hardware issues (on the switch or pfsense side). Is it possible pfsense is deliberately rejecting the request (due to some sort of rate limit or other reason)? Where would that show up in logs? Is it possible pfsense is for some reason replying on the wrong interface? Is there a way to do a packet capture on all interfaces simultaneously to see if this is the case?
-
@rtadams89 Well, i can’t think of a situation where pfSense would answer on another interface (except if you configured a bridge of the Lagg with another interface).
The reason I’m asking for the removal of the LAGG is because those does have a setup that causes them to ignore broadcasts on one interface in certain situations…Anyhow, I have no other suggestions - just the observation that I have never seen or heard of a situation where pfSense would intermittently not reply to ARP on an interface. I assume you do not have Ethernet Filtering active?
-
I've been digging into this over the last couple of day. The short answer is, this isn't pfsense. It seems that 3 of my switches (across 2 different manufactures) all have the same issue. They frequently send out arp requests for the gateway IP from their management IP, but tagged with a vlan tag (when they should be untagged). I know 2 of these switches (TP-Link brand) use realtek chipsets. I don't know about the other but I may pop it open to see if I can identify the chip. My best guess is this is just an issue in the Realtek chipset or the Realtek sdk/example firmware I'm guessing all these are using. The only think that still has me a little surprised is that I cannot find anyone else reporting this same issue. With how popular these switches, and the underlying chipsets are, I would think this would be more widely noticed and talked about.
-
@rtadams89 tplink and switches not a good mix.. Been quite a few years now - but they had an issue for the longest time where they would not allow you to remove vlan 1, even if you put a port in vlan X as access, ie native not tagged. It would still leave vlan 1 on there also as untagged.
Took them a few years to fix - they kept saying that was normal operation. And when they did finally fix it for v3 of the switch - they didn't backport it say v2 and v1 of the switches. Some smart person here posted a way to make the v2 switches take the v3 firmware - and now the switch reported it was v3 hardware ;)
What tag is it sending for its management IP in the arp? What is the 3rd model of switch are you seeing this in? Is it maybe Omada? Which is just different brand of tp-link.
Personally I would just trash those switches - that company clearly doesn't understand how tags and vlans work IMHO..
-
@johnpoz I see this happening on a TL-SG105E 5.0, a TL-SG108PE, and a XikeStor SKS3200M-8GPY1XF (Chinese suspicious switch -- tested just to rule out TP-Link). All of these switches have 5-7 VLANs trunked to/through them. I see the management ARP requests getting tagged with any of the VLANs the switch processes, but seems to usually be the VLAN that is organically the most chatty on that switch. Not all ARPs are mis-tagged, some do come out without a VLAN tag at all as expected. I have not seen any get tagged with VLAN 1.
-
@rtadams89 if me I would just trash those shit switches.. But yeah going to have a problem if you are looking to arp the IP of an interface that is native (untagged) and switch is tagging the arp.
Privacy Policy · Cookie Policy