Filter DHCP Requests on Bridge

[skydiablo]

Hi,
I want to ensure that the DHCP traffic from clients 1 and 2 doesn't get forwarded to clients 3 and 4. I've created a rule on the bridge to block everything with a destination port of 67, but this rule is being ignored, and it's not exactly what I want. Ideally, I would like to apply this only to packets coming in on interface 1. Does anyone have an idea on how I could achieve this?

Code Select Expand


             +-----------------------+
             |Third-Party DHCP Server|
             +-------------+---------+
+--------+                 |
|Client 1+--------------+  |
+--------+              |  |
                      +-+--+-+
                      |Switch|
                      +-+--+-+
+--------+              |  |
|Client 2+--------------+  |
+--------+                 |
                           |
                           |
     +---------------------+---------+
     |OpnSense             |         |
     |          +-------+--+--+---+  |
     |          |       |Intf1|   |  |
     |          |       +-----+   |  |
     |          |                 |  |
     |          |Bridge 1   +-----+  |
     |          |           |Intf2+--+----+
     |          +-----------+-----+  |    |
     |                               |    |
     +-------------------------------+    |
                                          |
                                          |
              +--------+                  |
              |Client 3+------+        +--+---+
              +--------+      +--------+Switch|
                                       +--+---+
                                          |
              +--------+                  |
              |Client 4+------------------+
              +--------+


[Monviech (Cedrik)]

When the DHCP Server is started on the firewall, there are automatic rules generated to allow DHCP traffic. They match with "quick" before your block rules, so the DHCP traffic is still allowed.

You can see the rules when you expand "Automatically generated rules" in an Firewall: Rules: INTERFACE". "allow access to DHCP server"

Maybe you should use DHCP Snooping on your Switch to ensure that DHCP Traffic is blocked on the port connected to the opnsense.

[skydiablo]

thx, but i can not see any auto-generated rules on my bridge? and also not on intf1 ...

[Monviech (Cedrik)]

Since DHCP is a broadcast, I'm not sure if the bridge will filter it out with firewall rules.

[skydiablo]

so opnsense can not handle broadcast traffic? what about L2 traffic? i also want to limit some ARP traffic. befor switchging to opnsense, i have already done this with linux (ubuntu). here are some of my rules to handle all this stuff:

Code Select Expand


# isolate bridge - preventing to breakout from the bridge
ip link set dev br100 type bridge vlan_filtering 1

# supress trash traffic
bridge link set dev vxlan100.2 mcast_flood off
ebtables -A FORWARD -i cw100 -o vxlan100.2 -d ff:ff:ff:ff:ff:ff -j DROP

#isolate remote-gateways tunnels
bridge link set dev vxlan100.2 isolated on


can i do this also with opnsense (with or without GUI?)

[Monviech (Cedrik)]

I am really unsure here, but from my understanding there's the following:

- OPNsense uses FreeBSD13 and the Packet Filter "PF" as main firewall solution. PF filters packets on layer 3 and 4.
- OPNsense also uses IPFW for dummynet, the IPFW Firewall functionality isn't loaded in the kernel though. IPFW could also filter layer 2 in addition to 3 and 4.

Since DHCP uses a layer 2 broadcast in it's "DHCP Discover", the PF firewall can't block it because it can't filter layer 2.

Maybe the DHCP Request or Acknowledge can be filtered since they're usually on layer 3. For that, the filtering tunables have to be set onto the bridge.

https://man.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=4&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html

In this man page you can see, that you have to set certain tunables to filter layer 3 on the bridge, and that layer 2 filtering is only possible with ipfw.

Hope that helps you to decide if the OPNsense is the right choice for that spot in the network.

[CJ]

What concern are you attempting to address by blocking DHCP traffic?  Perhaps a bridge is not the right solution for what you're attempting to do.

If you don't use a bridge then you can separate each group into their own subnet and they won't see any traffic that you don't expressly allow.

[Patrick M. Hausen]

When you build a bridge with two ports you are essentially creating a 2 port switch inside OPNsense and you cannot filter anything going on between these two ports. Just like an unmanaged switch cannot do that.
This is the point.

You can theoretically revert the two tunables from the LAN Bridge documentation, removing packet filtering from the bridge interface and putting it back on the individual ports. Of course this will break all sorts of things and you will have to manually create all rules necessary for bridged operation.


These two topologies are equivalent:

Code Select Expand

  OPNsense                                               OPNsense                                           
┌─────────────────────────────────────────┐            ┌─────────────────────────────────────────┐           
│                                         │            │                                         │           
│  Bridge                                 │            │                                         │           
│ ┌────────────────────────────┐          │            │                                         │           
│ │ ┌──────┐ ┌──────┐ ┌──────┐ │ ┌──────┐ │            │ ┌──────┐   ┌──────┐  ┌──────┐  ┌──────┐ │           
│ │ │ Port │ │ Port │ │ Port │ │ │ Port │ │            │ │ Port │   │ Port │  │ Port │  │ Port │ │           
│ │ └──────┘ └──────┘ └──────┘ │ └──────┘ │            │ └───┬──┘   └──────┘  └──────┘  └──────┘ │           
│ └────────────────────────────┘          │            │     │                                   │           
└─────────────────────────────────────────┘            └─────┼───────────────────────────────────┘           
                                                             │                                               
                                                             │                                               
                                                             │                                               
                                                       ┌─────┼──────────────────────────────────────────────┐
                                                       │ ┌───┴──┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐       │
                                                       │ │ Port │ │ Port │ │ Port │ │ Port │ │ Port │       │
                                                       │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘       │
                                                       └────────────────────────────────────────────────────┘
                                                         Switch                                             

[CJ]

Code Select Expand

  OPNsense                                               OPNsense                                           
┌─────────────────────────────────────────┐            ┌─────────────────────────────────────────┐           
│                                         │            │                                         │           
│  Bridge                                 │            │                                         │           
│ ┌────────────────────────────┐          │            │                                         │           
│ │ ┌──────┐ ┌──────┐ ┌──────┐ │ ┌──────┐ │            │ ┌──────┐   ┌──────┐  ┌──────┐  ┌──────┐ │           
│ │ │ Port │ │ Port │ │ Port │ │ │ Port │ │            │ │ Port │   │ Port │  │ Port │  │ Port │ │           
│ │ └──────┘ └──────┘ └──────┘ │ └──────┘ │            │ └───┬──┘   └──────┘  └──────┘  └──────┘ │           
│ └────────────────────────────┘          │            │     │                                   │           
└─────────────────────────────────────────┘            └─────┼───────────────────────────────────┘           
                                                             │                                               
                                                             │                                               
                                                             │                                               
                                                       ┌─────┼──────────────────────────────────────────────┐
                                                       │ ┌───┴──┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐       │
                                                       │ │ Port │ │ Port │ │ Port │ │ Port │ │ Port │       │
                                                       │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘       │
                                                       └────────────────────────────────────────────────────┘
                                                         Switch                                             

How long did that take you or do you have some sort of magic ASCII diagram maker?

[Patrick M. Hausen]

@CJ

https://monodraw.helftone.com/

For another example: https://forum.opnsense.org/index.php?topic=36667.msg179092#msg179092

[skydiablo]

What concern are you attempting to address by blocking DHCP traffic?  Perhaps a bridge is not the right solution for what you're attempting to do.

If you don't use a bridge then you can separate each group into their own subnet and they won't see any traffic that you don't expressly allow.

In the end, I am operating a Wi-Fi network with a central Network Access Control (NAC). As a result, I need to utilize a Layer 2 network to transmit client MAC addresses. I am contemplating the creation of a new dedicated Linux-based gateway to manage these tasks. Initially, I will attempt to address certain issues by forcibly converting some broadcasts into unicast traffic directly to my NAC. However, I currently lack a concrete plan for handling ARP-related matters.

[Patrick M. Hausen]

The Wi-Fi access point should provide client isolation, shouldn't it?

[skydiablo]

Certainly, the Wi-Fi network is provided externally and is not under the control of OPNsense. I have multiple remote locations connected via VXLAN and terminated on a bridge (I can control traffic between these locations through private ports). However, within this bridge, there is an additional port connected to an external NAC system and another remote location with numerous Wi-Fi devices. My predicament arises from the fact that this traffic is inundating my VXLAN external locations. So, as we discuss these issues, I've come to realize that I am inadvertently overwhelming the other external Wi-Fi network with my VXLAN traffic (facepalm). The only proper solution to this problem is to connect the external Wi-Fi network to my bridge as a private port and then redirect all the traffic to the external NAC through the only non-private bridge port.

thx, to be my rubberduck ;)

[Patrick M. Hausen]

Glad to be of service. Quack.