PFSense VLAN problems (ARP and DHCP not working)
PFSense VLAN problems (ARP and DHCP not working)
This article discusses an unusual problem we’ve never seen before, intended for those who appreciate the odd. If you have any insights, please let me know. We’ve already deemed this matter unworthy of extra effort. The firewall in question is a pre-existing model with 579 days of continuous operation. Initially running version 2.3.2, it was upgraded to 2.4.4_1 during troubleshooting. The setup includes a Supermicro C2758 server with four network interfaces and PFSense running directly on the hardware.
We attempted to add new VLANs to the firewall’s LAN port, configured interfaces, static IPs, and applied basic allow rules. However, accessing devices in the subnets failed. We verified that VLAN tags were correct on switches and that devices appeared on the expected IPs. Pings worked within subnets but not through the firewall, while the firewall couldn’t reach them. ARP and DHCP functions operated normally, suggesting a firewall rule issue. After resetting the firewall settings and reapplying rules, we still faced problems. The existing VLANs functioned properly, but new ones consistently encountered this obstacle.
Our only option now is to back up, reset, and reinstall—though we lack both budget and time for that. We’re told this situation will persist until the customer decides to upgrade their network, which would require a new firewall. This is especially concerning since PFSense (including NetGate appliances) isn’t approved by Starwood.
We hope this case sparked some laughter and curiosity.
Typically, when you set up a new interface—whether VLAN or standard—without adding any firewall rules, DHCP should function correctly. This is just one of PFSense's oddities. Your other inquiries are solid, and I'll check them out today.
Your DHCP settings apply to each interface individually, not just the newly created ones. Devices will initially use the default interface before switching to the new VLANs. I can provide a screenshot of the interfaces and their firewall configurations if needed.
Devices in the updated VLANs receive IP addresses from the correct DHCP server for that VLAN/subnet, not from the original default server. Their MAC addresses appear in the firewall’s ARP table alongside the assigned IPs, with an additional ARP entry for the firewall’s local IP within each VLAN. The firewall also acknowledges ARP requests from clients in the same VLAN. I won’t be taking screenshots, but I’m confident based on my previous posts that I understand how to configure a new VLAN in PFSense. We’ve already removed these new VLANs from the system, so there’s no need to invest further time on this matter—many engineers, including one from a partner using only PFSense, have reviewed it.
All switches use HP switches, which means there aren’t access or trunk ports. Each new VLAN was set up on the switches first before the firewall. We transferred the configuration of a comparable VLAN to the new one. On the links connecting switches and to PFSense’s LAN, every VLAN is tagged. We’re confident the VLAN settings on the switches are correct since ARP is working properly.
Not necessarily. If you can't reach the VLAN interface on the switch from the firewall's VLAN side, there might be a VLAN configuration problem. I'm not very familiar with HP switches, but I understand their tagging setup is unusual—tagging each port individually by VLAN. -Could the two VLAN interfaces communicate? -Would it be possible to ping the firewall's VLAN interface from a device in the same VLAN using Wireshark and see if an ARP reply appears?
We all have significant experience with HP equipment and confirmed the VLAN configurations on the switches were accurate. Regarding the firewall, we understand it has an entry in its ARP table for a MAC address assigned statically (not via DHCP), and similarly, it learns the router’s MAC address. This exchange happens without any additional protocols since it's not an IPv6 network. We also observed this pattern with downstream devices such as a wireless controller. In a new VLAN, two devices other than the firewall can communicate by pinging each other. Pings to or from the firewall in another VLAN stop working. We lack the capability to capture packets from non-firewall endpoints (no remotely accessible client machine), but the described behavior suggests ARP responses are functioning correctly.