pfSense – Why ARP Requests Are Ignored

arppfsense

I'm configuring pfSense 2.4.3p1 as a transparent firewall. It's running in virtual machine with two vtnet paravirtualized adapters:

  • WAN (vtnet0) connected to a 'far-side' network containing the gateway, DNS and DHCP servers
  • LAN (vtnet1) connected to a 'near-side' network containing clients

The firewall is to explicitly join the broadcast domains of the two segments such that they're both within 192.168.1.1/24. NAT is disabled. pf will be enabled but for now it's passing all traffic while I debug other issues. A bridge exists containing members WAN and LAN, assigned to an interface LANBR.

I've tried several configurations, and none of them seems to have a working bridge:

  • WAN having a DHCP IP, others without IP: WAN receives IP, can ping gateway at 192.168.1.1, but LAN clients cannot reach firewall or gateway
  • LANBR having a DHCP IP: cannot get IP from WAN interface
  • LAN having a DHCP IP: cannot get IP from WAN interface

In every case, clients on the LAN cannot ping hosts on the WAN. Running tcpdump while a client tries to ping 192.168.1.1 shows that ARP requests are coming from the client, getting ignored by pfSense, passed through to the WAN, and no response is coming back:

On the client

ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.163: Destination host unreachable.
Reply from 192.168.1.163: Destination host unreachable.

On the firewall

tcpdump -e -i vtnet0 -n -t arp

0a:... > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.windows, length 28
0a:... > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.windows, length 28
0a:... > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.windows, length 28
0a:... > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.windows, length 28

This is especially strange, given that pfSense definitely knows about that host:

arp -a
? (192.168.1.1) at 0c:... on vtnet0 expires in 1170 seconds [ethernet]

What's going on?

Best Answer

A bridge exists containing members WAN and LAN, assigned to an interface LANBR.

A bridge is a L2-Device, and has only interest in IP addressing for the purpose of configuring/managing the bridge itself. To work as a bridge, it does not need IP adresses.

Any port being a member of a bridge should not be interested in having/getting an IPv4 or IPv6 address whatsoever, and the device's configuration logic should prevent this.

Edit (after comment):

It seems that pfsense's concept of where a bridge's IP address may active is a bit more flexible than what I'd expected; a bridge's IP address may be on either member port or the virtual bridge interface.

Still, I recommend to avoid assigning a bridge's IP address to any member interface - that somewhat counteracts what a bridge is and how it is supposed to work. Switch ports don't have IP addresses either, and if a switch - which is nothing but a multiport bridge - has an IP address, it's on an SVI (Switch Virtual Interface), while dismissing as corner case the possibility configure "routed ports" on contemporary L3 switches.

Therefore, I uphold my recommendation (below) to run the bridge's IP on the virtual bridge interface only.

If at all, the Bridge's IP address should be on the LANBR interface only [1]; if it works properly, that address becomes accessible from any member port of the bridge, if the L2-firewalling policies on the member interfaces or the bridge itself permit.

That being said - if no traffic passes through the bridge (regardless if it has an IP or not), then there's something preventing it. Default L2 firewalling policies, perhaps, especially w/regards to broadcasts? DHCP is based on broadcast, to start with...

Edit (after comment):

Quoting from: https://www.netgate.com/docs/pfsense/interfaces/interface-bridges.html

By default, traffic is filtered on the member interfaces and not on the bridge interface itself. This behavior may be changed by toggling the values of net.link.bridge.pfil_member and net.link.bridge.pfil_bridge under System > Advanced on the System Tunables tab. With them set at 0 and 1, respectively, then filtering would be performed on the bridge only.

I think there's a hint in there. L2 filtering rules (or the removal thereof) must take into account the given filtering modes of both bridge and/or bridge member port(s).

[1] However, assigning that address via DHCP might turn out to be tricky; the given DHCP client might have some issues or need some help to determine which Client Identifier or MAC-Address&NIC to use for the DHCP request. Be sure to try static addressing at first, with an IP address within the same subnet, but outside the DHCP scope(s).

Related Topic