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

    Block traffic when VPN is down

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 8.4k 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.
    • D
      DunlapsS3CGuy
      last edited by

      The goal is to block outbound traffic to the internet when the VPN is down. And only for specific clients. I have some clients routing through the VPN and some routing directly to the internet.

      I searched for a while on this subject and wanted to post what i came to realize for anyone else that might be looking.

      I ended up with 3 firewall rules.  See picture.

      I found another https://forum.pfsense.org/index.php?topic=58694.0 that talked about creating a NAT deny rule for vpn clients trying hitting the WAN GW, but it seemed like traffic would still go out, but just not return appropriately.

      Please chime in if this is incorrect or if there's a better way to do this.
      ![Screen Shot 2014-11-23 at 10.49.06 AM.png](/public/imported_attachments/1/Screen Shot 2014-11-23 at 10.49.06 AM.png)
      ![Screen Shot 2014-11-23 at 10.49.06 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-23 at 10.49.06 AM.png_thumb)

      1 Reply Last reply Reply Quote 0
      • H
        heper
        last edited by

        might want to check the negate networks

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

          This is a little complicated.  The rules you have won't work.

          There are two ways that I have found to do this, first is system-wide.  There is a checkbox in System->Advanced->Miscellaneous:

          Skip rules when gateway is down
          By default, when a rule has a specific gateway set, and this gateway is down, rule is created and traffic is sent to default gateway.This option overrides that behavior and the rule is not created when gateway is down

          That will do what you want but it's a bit heavy-handed for my liking and might prevent something else from working some months/years in the future.

          I have taken to marking traffic you want to be VPN-only and using a floating rule on your WAN out to reject it.

          On the firewall rule that policy routes traffic to the VPN, go to the Advanced->Advanced settings and mark the traffic with something like "NO_WAN_EGRESS".

          Then create a rule on the floating tab.  Make it a reject rule, select Apply action immediately on match (quick), select your WAN interface(s), direction OUT, then set the advanced option to match on "NO_WAN_EGRESS".  And you're done.  You can now mark any traffic matched by any rule with "NO_WAN_EGRESS" and it will be blocked outbound at your WAN edge.

          I also make an alias for RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16) (I know - all not technically in 1918) and block traffic in the same way on WAN(s) out with a matching dest address.

          Note also that this is one of the niche cases where an Interfaces->Assign->Interface Groups group makes sense to use.  If you create an interface group for all your multi-WAN WAN interfaces, you only have to make one rule and it will cover them all.  Make a change to your WANs and all you have to do is remember to update the group.  All your rules will follow.  You can make the group with only one interface.  Then update the group if you ever go multiwan.

          ![Screen Shot 2014-11-23 at 12.37.18 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-23 at 12.37.18 PM.png)
          ![Screen Shot 2014-11-23 at 12.37.18 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-23 at 12.37.18 PM.png_thumb)
          ![Screen Shot 2014-11-23 at 12.48.38 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-23 at 12.48.38 PM.png)
          ![Screen Shot 2014-11-23 at 12.48.38 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-23 at 12.48.38 PM.png_thumb)

          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
          • D
            DunlapsS3CGuy
            last edited by

            @Derelict:

            The rules you have won't work.

            Actually it is working. I can see the packets being dropped in the log. I also tried your solution below with the floating rule and that also works. I know there are many ways to skin a cat.  :)

            Can you please go into more detail on your comment though? Is it that b/c marking the traffic and blocking it with a floating rule is more flexible or that mine is problematic for other reasons?

            Skip rules when gateway is down
            By default, when a rule has a specific gateway set, and this gateway is down, rule is created and traffic is sent to default gateway.This option overrides that behavior and the rule is not created when gateway is down

            I also found this setting and tried it to no avail.

            Many Thanks!

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

              That checkbox applies to all gateways all the time.  I'd rather just mark traffic I don't want to get out and have specific rules for just that.

              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
              • D
                DunlapsS3CGuy
                last edited by

                I see - Appreciate the info!

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