PFSense VLAN problems (ARP and DHCP not working)
PFSense VLAN problems (ARP and DHCP not working)
Improper tagging or missing tags still allow packets to pass through the firewall, which are handled at layer 2 before moving to rules at layer 3 for routing. This is often due to tagging issues rather than firewall involvement. The same subnet is involved, but the problem lies with VLAN configuration. If an ARP request was sent and broadcasted to the wrong VLAN, the firewall would process it, but that doesn’t guarantee devices receive a valid response. You just need a device on the new VLAN to capture traffic with Wireshark and observe the actual activity.
If ARP packets are crossing between VLANs, we’ve encountered a significant problem. This is precisely what VLANs are designed to stop. Since this doesn’t seem to be your case, here’s the relevant switch setup: vlan 936 is functional, while vlan 100 isn’t. This configuration reflects a straightforward scenario—we handle numerous VLANs and subnets in hotels, and minor human errors can occur, but the VLAN settings on the switch are correct.
I understand your experience with VLAN configurations. There were times when VLANs didn't transmit properly through a Realtek interface and HP ProCurve 2920. I switched to an Intel 1G card using the em* driver, which resolved the issue instantly—no need to recreate VLAN interfaces in pf. Earlier, on pf version 2.2, I couldn't reach the default gateway even with NAT or firewall settings. Once the interface changed, the problem disappeared. It seems the setup should follow this order: WAN → PF → (trunk port with VLANs allowed) → HP switch → access ports (VLANs in trunk list) → client. Also, ensure HP doesn't have ARP-protect enabled, as that caused similar issues before. I don't use HP switches much anymore and rarely run into these problems now.
I hope the Supermicro C2758 platform uses all Intel NICs, though I haven’t checked. If there’s a NIC problem, we’ll switch to a Cisco ASA or Watchguard, which will happen whenever they have budget for network work. The configuration is essentially what you expected. On the port connecting to PFSense, all VLANs are tagged—acting like a trunk port. The HP lacks ARP-protect, and during troubleshooting we turned off some security features. We ended up with the simplest setup that supported the necessary VLANs plus the ones being tested.
The SM board includes the i354 network controller which previously had several issues in older versions of pfSense from the 2.1 era. Are you using the ix driver or the igb driver on your setup? I reviewed my emails and KB documents, but updates have been made over time. There’s a command related to an ix driver problem that I found in a KB article, though it’s quite old and connected to VLAN hardware filtering. It appears in a separate KB file at the bottom of one I wrote. Try running `ifconfig ix0 - vlanhwfilter` and see if it resolves the issue. Make sure you select the right interface—ix0 might be your WAN interface, for example.
I understand this might be a potential VLAN setup issue. Which ports are currently untagged, and which ones are you attempting to reach via ping?
Testing from both the switches and a wireless controller. Switch01: int 25 name Switch02: int 26 name PFSense_LAN vlan 100 tag 25-26 ip address 10.0.3.130 255.255.255.128 vlan 101 tag 25-26 ip address dhcp vlan 936 tag 25-26 ip address 10.0.1.50 255.255.255.0 Switch02: int 1 name WLC int 50 name Switch01 vlan 100 tag 50 ip address 10.0.3.131 255.255.255.128 vlan 101 tag 50 untag 1 no ip address vlan 936 tag 50 ip address 10.0.1.51 255.255.255.0
Check the connection when pinging those IPs and see if a reply comes. For setting up port forwarding to 100 in PF-Sense, configure the rule properly and ensure the correct port is assigned.
PFSense is set up with VLAN 100 as 10.0.3.129/25. It has a correct firewall rule on that VLAN—allowing all traffic from XXX net and also accepting all traffic from any source. Pings from PFSense to the switches respond normally, while pings from the switches to PFSense do not return. Despite this, each switch’s MAC address is stored in its ARP table for 10.0.3.130 and 10.0.3.131, which were learned dynamically. The switches also have the firewall’s MAC address recorded for 10.0.3.129.