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

    [SOLVED] transparent filtering bridge doesn't work!

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 2 Posters 5.3k 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.
    • A
      atran
      last edited by

      i followed this doc: http://pfsense.trendchiller.com/transparent_firewall.pdf

      ISP range is 87.233.217.0/26.
      87.233.217.1 is ISP-router. (is a virtual ip (VRRP) connected to 2 physical routers: 87.233.217.61 & 87.233.217.62)

      pfsense 1.2.3-RELEASE has 3 nics:
      WAN - 87.233.217.2/26
      DMZ - 87.233.217.60/26 (greyed-out because of "bridged with" WAN selected)
      LAN - 192.168.254.0/24

      NAT rules:
      selected - Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))
      WAN     192.168.254.0/24   *   *   *   *   *   NO Auto created rule for LAN  
      (do i need a rule for the DMZ range here?)

      firewall rules:
      DMZ interface: any protocol from any source to any destination allow (*  *  *  *  *  *)
      WAN interface: ICMP from any source to any destination allow

      host behind DMZ:
      ip: 87.233.217.4
      mask: 255.255.255.192 (/26)
      gateway: 87.233.217.1 (router isp)

      problem:
      from host behind DMZ i cannot ping to gateway 87.233.217.1 or wan adres of pfsense (87.233.217.2) or any internet IP (www.google.com)
      when changed back to none-bridge and set correct IPs and NAT rules. it can ping to outside world. so pfysical connection is working.
      i though it was simple to do this bridging stuff…but..

      do i miss something here? how can i debug this?

      1 Reply Last reply Reply Quote 0
      • K
        kc8apf
        last edited by

        If the DMZ is bridged with WAN, it doesn't need any NAT rules.

        What you've described looks correct.  I have noticed that when changing bridging options that I need to reboot in order for everything to work correctly.  It's possible to get it running via a few steps, but rebooting is easier.

        Being unable to ping the pfSense WAN IP from the DMZ is a bit troubling.  That implies that your firewall rules weren't applied.  The rules apply to traffic coming in on the port they are defined on.  Since your DMZ interface allows all traffic, pfSense should respond to pings regardless of the rules on the WAN interface.

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

          i though i was right :)
          so that 1 NAT rule for lan IPs is enough…and i did reboot a few times!
          now i really dont know what i do wrong :(
          when ping from dmz host, i just get destination unreachable. weird...
          would there be any reason why the "allow any" rule on DMZ doesnt applied?
          i also tried to ping that host from the outside but the firewall log didn't showed any blocked traffic to that destination IP. weird...
          maybe something wrong at the IP-layer ?

          also weird is when i use the ping command from pfsense cli to ping that host behind the DMZ, it also is unreachable!?!
          arp table show nothing about 87.233.217.4
          should i also post screenshots of all the settings screens?

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

            do i have to add virtual IPs on de DMZ or WAN interface with bridging??

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

              stil no go…

              when i change bridge to "none" and reboot, i still can't ping the dmz interface ip (same subnet as WAN). this, i think, is because ping traffic is coming in but reply's trough wan interface. (default route)

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

                i went to console and did a tcpdump on bridge0:

                tcpdump -i bridge0

                tcpdump: WARNING: bridge0: no IPv4 address assigned
                tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes
                23:25:15.119405 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:16.228743 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:17.239585 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:18.119207 arp who-has 87.233.217.4 tell 87.233.217.62
                23:25:18.339557 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:19.428667 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:20.437208 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:21.538412 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:22.537213 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:23.556210 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:24.558579 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:25.567906 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:26.577707 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:27.588567 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:28.599082 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:29.096596 arp who-has 87.233.217.4 tell 87.233.217.62
                23:25:29.606541 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
                23:25:30.705336 IP 87.233.217.61 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20

                an arp request from 87.233.217.62 (one of the two isp routers ip) for 87.233.217.4 (host behind DMZ which is bridged to WAN) doesn't get answered, as if the broadcast didnt reach anything behind the bridged interface.

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

                  Fixed!!
                  when set pfSense in bridge mode it uses Spanning Tree (STP) to control the bridge (like a switch).
                  this maybe conflicts with my switch and its vlan's (where STP is default enabled for each port).
                  however, i just disable STP on the switch port where the WAN is connected and then i can ping to/from bridged DMZ.

                  this problem would never occured when i used 3 switches, one for each segment, instead of VLAN's on same switch.

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