3

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?

Improve this question

2 Answers 2

Reset to default
5

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).

Improve this answer
2
  • Please revise your answer after having read this page: netgate.com/docs/pfsense/interfaces/interface-bridges.html pfSense bridges are mixed L2/L3 devices supporting between zero and one IP assignments.
    – Reinderien
    Commented Sep 18, 2018 at 13:44
  • Philosophically I think I agree with you. Also note that, due to the default setting for net.link.bridge.pfil_bridge, the IP cannot be on the assigned bridge interface unless the default behaviour is changed.
    – Reinderien
    Commented Sep 19, 2018 at 13:28
3

It turns out that the paravirtualized network ports need to be put in promiscuous mode. Once that's done, everything works as expected.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.