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

    Unexpected behaviour on bridged interfaces

    Firewalling
    5
    19
    3.3k
    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.
    • A
      alex11
      last edited by

      Hello forum,

      I observed something which is quite inexplicable to me. Please refer to the attached PNG for a drawing of my network setup.

      I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass. My observations, however, are as follows:

      1. Connection from [172.16.0.2] to [172.16.0.3:1194/UDP] dropped and logged as expected.
      2. Connection from [172.16.0.2] to [172.16.0.1:5000/UDP] dropped and logged as expected.
      3. Connection from [172.16.0.2] to [172.16.0.1:1194/UDP] successful.

      The last result puzzles me. Why would the LAN interface allow a connection to the WAN's IP if it is configured to drop any packets to an RFC1918 IP?

      Is it some weird corner case? Or has it to do with the bridging mode which under the hood works other than one would expect?

      Thanks for any help.
      pfsense.png
      pfsense.png_thumb

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        No idea what you're trying to do there with WAN and LAN on the same subnet and it looks like you have WAN and LAN bridged with workstations on both sides.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • A
          alex11
          last edited by

          @Derelict:

          No idea what you're trying to do there with WAN and LAN on the same subnet and it looks like you have WAN and LAN bridged with workstations on both sides.

          This diagram is massively simplified and is only meant to give you an example of what the issue is. Think of workstation 1 as the router to the public internet and pfSense acting as a VPN server. I don't like the setup much myself but there are boundary condiitons beyond my power which force me to choose this configuration.

          And bridging a subnet across a firewall may be unusual but is imho a legit means of managing traffic.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            When I have to make a bridge I generally put the IP address on the bridge interface itself.

            What are the settings for the net.link.bridge.pfil_member and net.link.bridge.pfil_bridge entries in System > Advanced > System Tunables ?

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • A
              alex11
              last edited by

              I stuck with the standard setting as mentioned here
              https://doc.pfsense.org/index.php/Interface_Bridges

              I do understand the difference to my configuration. However, filtering traffic on the bridge interface itself sounds like a workaround which is perfectly fine. Nevertheless, I would like to understand what the matter is with my setup, simply for the sake of understanding :).

              1 Reply Last reply Reply Quote 0
              • chpalmerC
                chpalmer
                last edited by

                I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass.

                Why?  Did you explicitly block them?

                Triggering snowflakes one by one..
                Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                1 Reply Last reply Reply Quote 0
                • A
                  alex11
                  last edited by

                  @chpalmer:

                  I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass.

                  Why?  Did you explicitly block them?

                  Yes, I do have an explicit rule dropping all traffic to RFC1918 subnets. Strangely enough, as per the logs this rule fires for all connection attempts but the one described as no. 3 in my original post.

                  BTW, even if I hadn't any explicit drop rule, the default drop rule would fire unless I have a pass rule?

                  1 Reply Last reply Reply Quote 0
                  • chpalmerC
                    chpalmer
                    last edited by

                    @alex11:

                    Yes, I do have an explicit rule dropping all traffic to RFC1918 subnets. Strangely enough, as per the logs this rule fires for all connection attempts but the one described as no. 3 in my original post.

                    BTW, even if I hadn't any explicit drop rule, the default drop rule would fire unless I have a pass rule?

                    :)

                    Don't know.  You haven't shared that with the forum here yet.  Any rules at all?  Keep in mind that rules affect incoming traffic on an interface.  So each end of the bridge would have its own rules.  Its got to be a configuration problem or misunderstanding on how rules work in this specific instance by you or yours or there would be loads of people including me complaining.

                    Asked by Derelict-

                    What are the settings for the net.link.bridge.pfil_member and net.link.bridge.pfil_bridge entries in System > Advanced > System Tunables ?

                    ??  We all know what the article says but something could be different than you expect. Please look and report back.

                    Screenshots of your rules would be nice as well.  ;D

                    Triggering snowflakes one by one..
                    Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                    1 Reply Last reply Reply Quote 0
                    • A
                      alex11
                      last edited by

                      Sorry, I cannot provide any screenshots right now, only a typed list of my rules:

                      The rules on the LAN interface are:

                      allow IPv4 UDP    | 0.0.0.0 | * | 255.255.255.255 | 67 | * | none | (DHCP)
                      allow IPv4 TCP/UDP | *      | * | 172.16.0.3      | 53 | * | none | (DNS)
                      drop  IPv4/6 *    | *      | * | RFC1918        | *  | * | none
                      allow IPv4 TCP/UDP | *      | * | *              | *  | * | none
                      allow IPv4 ICMP    | *      | * | *              | *  | * | none

                      1 Reply Last reply Reply Quote 0
                      • A
                        alex11
                        last edited by

                        Re the pfil_* values: Currently I only have access to the backup xml file and there is no "pfil_*" entry in it. I reckon that means they have the default values…

                        1 Reply Last reply Reply Quote 0
                        • chpalmerC
                          chpalmer
                          last edited by

                          Im going to guess this points at an alias.  I believe you must have a config error in the way your alias is built.

                          drop  IPv4/6 *    | *      | * | RFC1918        | *  | * | none

                          Otherwise this rule is letting everything through-

                          allow IPv4 TCP/UDP | *      | * | *              | *  | * | none

                          Triggering snowflakes one by one..
                          Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                          1 Reply Last reply Reply Quote 0
                          • A
                            alex11
                            last edited by

                            Correct, "RFC1918" is an alias for the three private subnets as per https://en.wikipedia.org/wiki/IP_address#Private_addresses. What I have in the xml file is
                            <alias>[…]

                            <address>10.0.0.0/8 172.16.0.0/12 192.168.0.0/16</address>

                            […]</alias>

                            What puzzles me is that the RFC1918 drop rule works as expected but for this one case when I connect to the WAN interface's IP and port on which the VPN runs (e.g. in the examples 1 and 2 the rule works as it should). I have set up other aliases, both for IP ranges and ports, which also work fine. I am thus inclined to believe that my aliases are fine.

                            I am at my wit's end.

                            1 Reply Last reply Reply Quote 0
                            • C
                              cmb
                              last edited by

                              That kind of config with bridging isn't a good idea, with the same IP subnet on multiple interfaces. What's probably happening is that OpenVPN connection attempt hits your WAN rules, because that IP is showing up in the ARP cache for WAN.

                              1 Reply Last reply Reply Quote 0
                              • A
                                alex11
                                last edited by

                                @cmb:

                                That kind of config with bridging isn't a good idea, with the same IP subnet on multiple interfaces. What's probably happening is that OpenVPN connection attempt hits your WAN rules, because that IP is showing up in the ARP cache for WAN.

                                Thanks for the info. This supports my conjecture in the original post the the matter is rather a corner case than a misconfiguration, right? The fact that OpenVPN is reachable from the LAN is not a problem for me, I just don't understand it. By the same token, however, I would assume that other hosts on different sides of the bridged network might be able to connect to each other but the firewall rules work perfectly when restricting access from workstation 1 to workstation 2.

                                So, to rephrase my question: Can I be sure that the firewall rules work as one would expect for all traffic except that in which the WAN interface's IP is involved? That would be fine in my case.

                                Thanks!

                                1 Reply Last reply Reply Quote 0
                                • A
                                  alex11
                                  last edited by

                                  Today I added an explicit block rule for traffic from 172.16.0.2 to 172.16.0.1 on the WAN interface and, voilà, OpenVPN is no longer reachable.

                                  I do not quite understand this but I reckon it must have to do with what cmb posted even though I find it rather counterintuitive  ;).

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    gcu_greyarea
                                    last edited by

                                    That really is odd. Do you have a Floating Rule that might allow traffic from 172.16.0.2 to 172.16.0.1?

                                    I agree with Derelict to put the IP on the Bridge Interface itself as opposed to one of the member interfaces. I also filter on the bridge (pfil.bridge=1) and not on the members.

                                    I'm in a simular situation as you are in that I must bridge and there isn't much info available on bridged setups.

                                    Since you OVPN Server is listening on 172.16.0.1:1194 there might be a chance that the OVPN Server is overriding the Packet filter… .??? And maybe this behavior is only exposed in bridged setups ? Possibly a bug?

                                    1 Reply Last reply Reply Quote 0
                                    • G
                                      gcu_greyarea
                                      last edited by

                                      Which IF does the openvpn server run on? Bridge or Wan?

                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        alex11
                                        last edited by

                                        OVPN is configured to listen on all interfaces since I need it on two but apparently cannot specify 2 out of many. Hence I have it listen on all and block all but those two interfaces. However, the LAN and the bridge interfaces don't have an IP set.

                                        Re floating rules: none configured whatsoever.

                                        I am still in the dark wrt to this odd behaviour. However, since the firewall is in productive use I stick with the concept "never touch a running system" ;). Everything else seems to be working fine, though.

                                        1 Reply Last reply Reply Quote 0
                                        • A
                                          alex11
                                          last edited by

                                          Things are going from odd to erratic ;).

                                          I didn't touch the config since last week and on Friday everything was was described above. Then I turned on my computer this morning and, alas, pfsense did indeed block traffic to OVPN, coming from the LAN to the WAN interface.

                                          Now I am utterly bewildered…?

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