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

    Possible bug in firewall logic? Allows traffic out WAN when specified gateway is down...

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 3 Posters 607 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.
    • O
      osheikh
      last edited by osheikh

      Hi Guys. I'm no expert on this but have managed to get PFSense to do what I want over the last many years. I've encountered a rather simple situation that has left me stumped and is not behaving as one would expect. I probably missed something stupid and need you guys to point it out for me.

      The situation:

      • I have a simple rule on one of my interfaces where traffic is set to go out a particular gateway. This gateway is a VPN tunnel.
      • There is no provision for failover to another gateway. If this gateway is down, traffic should stop and give no connection.
      • If the gateway is genuinely down (route/gateway enabled and openvpn client enabled), the traffic stops as expected.
      • If I manually disable the OPENVPN instance (while leaving it in the list), the traffic immediately flows out the WAN! WHY!?
      • If I log the traffic on this rule, it says that this line is letting it through.

      How can I prevent this behaviour? My expectation is that no matter how the gateway is disabled that traffic should stop if that gateway is not available. I have other rules elsewhere where I want the same outcome but the behaviour is same there also.

      Is this a bug or have I missed something? If I add a rule blocking traffic through the WAN after this line, the traffic still goes out the WAN based on the pass rule for the VPN gateway.

      Much appreciated.

      2019-11-09_0-47-59 - VPN Rule.png

      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @osheikh
        last edited by Konstanti

        @osheikh
        Hello
        To avoid traffic leakage through the WAN interface it is necessary to use tags
        On the lan interface you create a rule with a tag and you specify the interface through which the traffic should pass
        For example,
        d5429bc6-4a10-460b-884a-a7afb8b40136-image.png
        555484a2-f373-4c3f-8d46-6eeb6e41af35-image.png

        Now you need to create a blocking rule for outgoing traffic on the wan interface (section-floating rules)
        39c4e38b-992f-4632-87d8-e3f155abe63f-image.png

        And now check the availability of tag in this same rule

        e4cbe66f-2d57-4f8a-a275-b0c6af12c2fb-image.png

        now all all traffic destined for VPN will not pass through WAN interface

        1 Reply Last reply Reply Quote 1
        • O
          osheikh
          last edited by

          Thank you!! This did exactly what I needed. I would have never figured this one out on my own. Tags really do open up the possibilities of what rules can be made to do.

          Much appreciated.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            What you really probably want is even easier:

            System > Advanced, Miscellaneous tab: Skip rules when gateway is down

            If that is unchecked (default) then when a gateway is down, the rule stays in place but without the gateway set. If that is checked, the rule is skipped (omitted from the ruleset) so it moves to the next available rule.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 1
            • O
              osheikh
              last edited by

              Thanks Jimp. Indeed this also does the job but there seems to be a place for both solutions depending on the situation. Much appreciated!

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