Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Block DHCP broadcast from DHCP ON Domain Controller

    Scheduled Pinned Locked Moved DHCP and DNS
    11 Posts 3 Posters 4.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • johnpozJ
      johnpoz LAYER 8 Global Moderator
      last edited by

      And why are you using tap if you don't want bridge?

      If you were using tun then you would not see broadcast traffic from the other side.  Are you running the same network space on the each side, example 192.168.1.0/24 on your network and his as well?

      Clearly your rules are not correct though - can you post these blocking rules you have setup?

      An intelligent man is sometimes forced to be drunk to spend time with his fools
      If you get confused: Listen to the Music Play
      Please don't Chat/PM me for help, unless mod related
      SG-4860 24.11 | Lab VMs 2.7.2, 24.11

      1 Reply Last reply Reply Quote 0
      • U
        UFNTech01
        last edited by

        Thanks for replying so quickly.

        From the OpenVPN site: "By bridging a physical ethernet NIC with an OpenVPN-driven TAP interface at two separate locations, it is possible to logically merge both ethernet networks, as if they were a single ethernet subnet."

        That said, both sites are part of the same broadcast domain/network, 10.10.0.0/16.

        The reason we went with a TAP Bridged configuration is to allow for seamless connectivity between connected devices. This makes it easy to play LAN Games, Host LAN Parties {xbox, xbox 360, lan games like starcraft 1, unreal tournament 2004} as well as stream movies and music {e.g. via Plex, DLNA, etc}.

        The goal is to achieve the above but without spilling dhcp traffic across the bridge.

        We have tried the following IPTables rules:

        Attempt 1:

        Attempt 2:

        However, none of these have worked, as IP Addresses continue to be swapped across sites, and we have verified DHCP spillover via Wireshark.

        My brother has done a lot of searching on the internet, and it seems this is a problem inherent to the type of connection we have. Might it be due to these broadcasts being layer 2 and iptables not being able to catch them?

        1 Reply Last reply Reply Quote 0
        • pttP
          ptt Rebel Alliance
          last edited by

          Regardless the correctness of your rules, The Rules are Evaluated from Top to Bottom and "first match wins", so, if you want your Block rules catch any traffic you must move them above the pass rules…

          dhcp_firewall_rules_a.png
          dhcp_firewall_rules_a.png_thumb
          dhcp_firewall_rules_b.png
          dhcp_firewall_rules_b.png_thumb

          1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator
            last edited by

            Not sure where you go the idea that dhcp was layer 2?

            But yeah that first rule allows anything.. So your dhcp blocking rules are never seen.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.7.2, 24.11

            1 Reply Last reply Reply Quote 0
            • pttP
              ptt Rebel Alliance
              last edited by

              @johnpoz:

              Not sure where you go the idea that dhcp was layer 2?

              From the same place of:    :P

              @UFNTech01:

              We have tried the following IPTables rules

              Might it be due to these broadcasts being layer 2 and iptables not being able to catch them?

              @UFNTech01

              pfSense Firewall uses Packet Filter (pf), Not Iptables

              1 Reply Last reply Reply Quote 0
              • U
                UFNTech01
                last edited by

                @ptt: I've updated the firewall rules as per your datum, and I'm happy to say that these settings worked!

                DHCP Broadcasts are no longer traversing the bridge. I've verified this with Wireshark.

                I am indebted to you.

                @johnpoz, my apologies, I was unclear. What I meant was that the DHCP Client sends a DHCPDiscover broadcast across Layer 2  (as well as Layer 3).  I was of the impression that pfSense could not catch this type of traffic.

                Again, @ptt, thanks for clarifying on what firewall technology was working under the hood. It's very clear I need to RTF(pfsense)M.

                So to recap, my firewall rules are set as follows:

                For IPV4/IPV6, block any UDP traffic originating from any source with a source port of either 67 or 68 destined to anything with a destination port of either 67 or 68.

                Illustrated below:

                And here are some keywords for google to cache:

                kwd:{networking,pfsense,openvpn,site2site,connection,bridge,network,tap,dhcp,broadcast,block,filter,gateway,windows,dhcpoffer,dhcprequest,dhcpack

                Again, much obliged to all.

                1 Reply Last reply Reply Quote 0
                • pttP
                  ptt Rebel Alliance
                  last edited by

                  Glad to see you have it sorted out….  :)

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    "DHCPDiscover broadcast across Layer 2"

                    Again - why do you think that dhcp is a layer 2 protocol?  Because broadcasts are sent to the all FFs mac??  Maybe you need to re address your understanding at a basic level ;)

                    So what layer is UDP?  Which dhcp uses right, so can't be any lower than that – and then think about it some more is there a client and a server involved?  So what layer does that put it...  Starts with A as a hint, and Comes after 6 but before the user level 8 ;)

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                    1 Reply Last reply Reply Quote 0
                    • U
                      UFNTech01
                      last edited by

                      @johnpoz, I understand that DHCP works on the application layer of the OSI Model. In my original post, I was referring to layer 2 broadcasts being produced by the DHCP client, not that DHCP itself is a Layer 2 protocol. Thanks again, and sorry for the confusion.

                      1 Reply Last reply Reply Quote 0
                      • johnpozJ
                        johnpoz LAYER 8 Global Moderator
                        last edited by

                        Your still confused!!!  I give up – think what you want..  But dhcp has nothing to do with layer 2 at all, nothing!!  Yes all traffic has a layer 2 part of it where macs are used.. And yes broadcasts go to the all FFs address.  That's common with every single protocol ;)

                        From your statement pfsense wouldn't be able to firewall anything..

                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                        If you get confused: Listen to the Music Play
                        Please don't Chat/PM me for help, unless mod related
                        SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.