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

    After upgrade from 1.2.3 to 2.0.1 bridging is broken

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 3 Posters 2.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.
    • S
      ssbaksa
      last edited by

      Hi.

      As subject says I have problem with bridging. After update, something what worked for more than 3 years was broken. In attached schema you can see general idea.

      Interfaces em1 and em2 are bridged. em1 has IP address x.y.202.9 with some aliases. em2 is just bridged + firewall. On both segments I have servers. Inside networks are on VLAN's and IP aliases on WAN are used to NAT each VLAN to different IP.

      Before upgrade servers x.y.202.3 and one behind firewall x.y.202.120 were accessible by inside clients/servers. Now I can't even ping servers on inside bridged segment (x.y.202.120) dough x.y.202.3 is still there. I can't ping even IP's on em1 interface.

      I have even added allow all to all interfaces as first rule but it didn't do any good.

      What can I do. Where to look for clues. Going back to 1.2.3 is not an (welcomed) option.

      BTW - This rule is something that looks strange to me:

      pass out route-to (em1 161.53.202.1) inet from 161.53.202.9 to !161.53.202.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"

      Br

      Sasa

      ![General schema.jpg](/public/imported_attachments/1/General schema.jpg)
      ![General schema.jpg_thumb](/public/imported_attachments/1/General schema.jpg_thumb)

      1 Reply Last reply Reply Quote 0
      • S
        ssbaksa
        last edited by

        To replay to myself.

        Now, in 2.0.1 if you wish bridging to function as before, you must:

        1. assign bridge to interface
        2. than assign that bridge to interface
        3. enable new interface
        4. Create pass/bloc/drop rules according to you "taste"
        5. Now you have bridge that is up & running.

        Found&Done by using few old firewalls still running old pfS versions and my favorite pfctl -sr.

        1 Reply Last reply Reply Quote 0
        • S
          ssbaksa
          last edited by

          Another update.

          It works from one bridged interface to another one.
          It is still broken from NAT'ed one to inside bridge interface.

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            There are some sysctls that control whether packet filtering is done on bridge interfaces or their members - see System -> Advanced click on System Tunables tab. Perhaps you are falling foul of those settings.

            1 Reply Last reply Reply Quote 0
            • S
              ssbaksa
              last edited by

              @wallabybob:

              There are some sysctls that control whether packet filtering is done on bridge interfaces or their members - see System -> Advanced click on System Tunables tab. Perhaps you are falling foul of those settings.

              I have also thought so but after changing this parameter there was no difference.
              Anyway I will try it again. Tnx for sugestion.

              Sasa

              1 Reply Last reply Reply Quote 0
              • S
                ssbaksa
                last edited by

                No change!

                From 172.16.84.254 icmp_seq=193 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=194 Destination Host Unreachable

                From inside VLAN:

                root@njuskalo:~# ping 161.53.202.90
                PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
                64 bytes from 161.53.202.90: icmp_seq=1 ttl=64 time=0.376 ms
                64 bytes from 161.53.202.90: icmp_seq=2 ttl=64 time=0.331 ms
                64 bytes from 161.53.202.90: icmp_seq=3 ttl=64 time=0.299 ms
                64 bytes from 161.53.202.90: icmp_seq=4 ttl=64 time=0.442 ms

                From bridged network interface:

                root@master:~# ping 161.53.202.90
                PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
                From 172.16.84.254 icmp_seq=6 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=7 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=8 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=9 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=10 Destination Host Unreachable
                From 172.16.84.254 icmp_seq=11 Destination Host Unreachable

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  After changing the sysctls you will have to reload the firewall rules (or reboot). Possibly also the state table?  :-\

                  You should see something in the firewall logs to indicate where/if it is being blocked.

                  Steve

                  1 Reply Last reply Reply Quote 0
                  • S
                    ssbaksa
                    last edited by

                    @stephenw10:

                    After changing the sysctls you will have to reload the firewall rules (or reboot). Possibly also the state table?  :-
                    You should see something in the firewall logs to indicate where/if it is being blocked.
                    Steve

                    Rebooted (not only once) Weird thing is that there is no log for that traffic. Isn't state table cleared with reboot?
                    I have used this option to:

                    Disable reply-to Disable reply-to on WAN rules
                    With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.

                    but no positive result. This is hell. I am using pfSense (M0n0Wall before that) for years and this is problem which makes me frustrated. I am missing something obvious but…

                    root@master:~# ping 161.53.202.90
                    PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
                    From 172.16.84.254 icmp_seq=6 Destination Host Unreachable
                    From 172.16.84.254 icmp_seq=7 Destination Host Unreachable
                    From 172.16.84.254 icmp_seq=8 Destination Host Unreachable
                    ^C
                    --- 161.53.202.90 ping statistics ---
                    8 packets transmitted, 0 received, +3 errors, 100% packet loss, time 7008ms

                    root@master:~# traceroute 161.53.202.90
                    traceroute to 161.53.202.90 (161.53.202.90), 30 hops max, 60 byte packets
                    1  zidic.efos.loc (172.16.84.254)  0.127 ms  0.118 ms  0.109 ms
                    2  zidic.efos.loc (172.16.84.254)  0.142 ms !H  0.134 ms !H  0.170 ms !H

                    1 Reply Last reply Reply Quote 0
                    • S
                      ssbaksa
                      last edited by

                      Well, just to inform those interested.

                      After a struggle decision was laid and I have moved my FW to version 1.2.3 and all was back as it was.
                      No problems with bridging and NAT.

                      Sasa Baksa

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