How to reject DHCP broadcasts across bridged networks?

lada04

Hi all,

This problem drives me nuts since some time: Filtering DHCP requests between two networks.

Network A (192.168.0.0/23) and B (192.168.1.0/23) at different locations are connected via openvpn. Both networks are bridged between a LAN, WLAN and the respective OpenVNP interface.
The masks are overlapping intentionally to simplify access (smb network etc.). The bridges are used to enable UPnP multicasts. On both networks a DHCP server is running with different address ranges. The addresses should only be provided by the server within the local part of the network.
The problem is, that both DHCP servers reply to DHCP requests on either network, as broadcasts are exchanged between the networks.
Therefore I've setup reject-rules on both openvpn interfaces, first only on the broadcast:

IPv4 UDP 	* 	* 	255.255.255.255 	67 - 68 	* 	none

As this was not effective, I've tried a more general rule:

IPv4+6 UDP 	* 	67 - 68 	* 	67 - 68 	* 	none

Although packets are rejected:


Aug 20 11:33:02 pf filterlog: 86,16777216,,1422815671,ovpnc4,match,block,in,4,0x0,,128,18,0,none,17,udp,349,192.168.0.41,255.255.255.255,68,67,329

the DHCP server on network A still responds to requests from network B:

11:33:01.880986 IP 192.168.0.41.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c4:85:xx:xx:xx:xx, length 321
11:33:01.882610 IP 192.168.0.1.67 > 192.168.0.41.68: BOOTP/DHCP, Reply, length 302

I don't understand how this can happen.

How could I isolate both DHCP-servers?

Many thanks your help or suggestions!

JKnott

Bridges can't block anything. They're supposed to be transparent. About all you can do is configure the DHCP servers to hand out addresses only to specific MAC addresses. Also, your "overlapping" configuration breaks a lot of things. In fact, despite that trailing 1, they are the exact same network.

lada04

Thanks for the quick reply.
Does this mean that any rule on member interfaces of a bridge are never effective?

kpa

A transparent bridge is certainly capable of filtering just about anything but pfSense is configured to automatically pass DHCP across the bridge. I think you could filter DHCP with floating rules but I haven't tried myself on a bridged setup.

NogBadTheBad

sounds like your doing your bridge wrong, there should be only one subnet.

https://doc.pfsense.org/index.php/Interface_Bridges

switch off the dhcp server on the wifi side or even better buy an AP.

JKnott

@kpa:

A transparent bridge is certainly capable of filtering just about anything but pfSense is configured to automatically pass DHCP across the bridge. I think you could filter DHCP with floating rules but I haven't tried myself on a bridged setup.

If it's filtering, it's no longer transparent.

lada04

Many thanks for the comments and suggestions.

Basically, there are two bridges at two different pfsense routers at different locations, each bridging
[LAN, WLAN-AP, OPENVPN]
on either side, each has only the bridge interface assigned with an IP.

Both are linked via openvpn (over the wan interface) as the vpn is included in the bridge (on one side the server, on the other the client).

And yes, the idea was both bridges should function as one network, making upnp work (server on network B, clients on A and B), thats why the 'overlapping' ip-mask. Possibly this was a strange idea…

The system tuneables are still default:

net.link.bridge.pfil_member 	default (1)
net.link.bridge.pfil_bridge 	default (0)

As I understood, this should allow filtering on the members interfaces, and I expected to isolate both DHCP-servers in this way.
The behaviour would be explained, if DHCP is always forwarded, independent on the rules, as mentioned by kpa.

I could run only one DHCP-server (on one of the boxes), but if the WAN interface fails, the other router will not provide addresses via DHCP…

Derelict

Did you put the block rules on the OpenVPN assigned interface tabs or the OpenVPN tabs?

If you placed the rules on the assigned interface tabs (where they probably should be) did you also make sure the rules on the OpenVPN tabs did not also match the traffic and pass it? Rules on the OpenVPN tabs are processed first so if they match the assigned interface rules will never match. Not exactly sure how this works with filters on bridge members. I don't know if the OpenVPN tab rules can even match bridge members.

It seems like what you are trying to do should work.

I would probably try to block this with floating outbound rules on the OpenVPN assigned interfaces in the out direction. That way you are keeping the unwanted broadcast traffic off the VPN link entirely.

Block, Quick, OpenVPN_Interface, out, UDP 67-68

lada04

Did you put the block rules on the OpenVPN assigned interface tabs or the OpenVPN tabs?

As I wasn't sure which interface will be effective, I have the sames rule on both, the 'native' OpenVPN tab and the assigned one:

So should I disable the rules on the native one?

What I don't understand is that I see rejected/blocked packages in the filter.log, but still the DHCP requests are replied (from the wrong side, meaning the DHCP-server on the other end of the tunnel).