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

    Prevent Certain LAN ips from accessing WAN when OpenVPN goes down

    Scheduled Pinned Locked Moved OpenVPN
    52 Posts 11 Posters 26.7k 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.
    • K
      kejianshi
      last edited by

      I don't know that that would fix your problems.  No matter how the traffic arrives at the VPN gateway it seems it might get to the WEB unless the VPN blocks traffic when down.  An easy fix would be to run those devices off a second small device that acts as a VPN client, like a small DD-WRT router instead of using pfsense as VPN client.  Then you could easily block any traffic not on a VPN port.  Short of that, I guess we have to wait for answer from ubber genius more than us…

      1 Reply Last reply Reply Quote 0
      • M
        m3ki
        last edited by

        ok….. so I feel stupid now :)

        I may have some progress now.

        I have reread the other post over an over so it seems to somewhat work...
        I still forward packets to VPN GW but also added DO NOT NAT rule for 192.168.1.5 on WAN. This seems to do the trick but I don't think it's right packets should theoretically go out. How do I drop them?

        Status now if VPN is up olive goes through VPN properly.
        If VPN is down Olive cannot ping google.

        ![Screen Shot 2013-08-10 at 9.57.53 AM.png](/public/imported_attachments/1/Screen Shot 2013-08-10 at 9.57.53 AM.png)
        ![Screen Shot 2013-08-10 at 9.57.53 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2013-08-10 at 9.57.53 AM.png_thumb)
        ![Screen Shot 2013-08-10 at 9.56.43 AM.png](/public/imported_attachments/1/Screen Shot 2013-08-10 at 9.56.43 AM.png)
        ![Screen Shot 2013-08-10 at 9.56.43 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2013-08-10 at 9.56.43 AM.png_thumb)

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

          I wouldn't feel stupid - I didn't think to try killing it there in outbound NAT.  Nice.

          1 Reply Last reply Reply Quote 0
          • M
            m3ki
            last edited by

            :) Yeah but stuff still goes out and isp still dropping it I assume. I have to drop it at the firewall.
            I wish there was a book on pfsense with some diagram on how packets traverse the firewall.

            1 Reply Last reply Reply Quote 0
            • panzP
              panz
              last edited by

              @m3ki:

              the rule I used was…
              Anything on WAN interface, Direction OUT,coming from 192.168.1.5 - to Anywhere BLOCK <--- this didnt work.
              I also tried same as above going to WAN Subnet. that didnt work either.

              I've setup the following rule, works perfectly:
              Firewall: Rules –> Floating tab

              IMPORTANT: it's NOT a quick rule!
              Action: Block
              Interface: WAN
              Direction: any <-- (if set to OUT, it doesn't work!)
              Source : any [here you need to enter 192.168.1.5]
              Destination: any
              [_/] Log packets that are handled by this rule
              Description: FLOAT01_NO_INTERNET_IF_AIRVPN_IS_DOWN

              pfSense 2.3.2-RELEASE-p1 (amd64)
              motherboard: MSI C847MS-E33 Micro ATX (with Intel Celeron CPU 847 @ 1.10 GHz) ~ PSU: Corsair VS350 ~ RAM: Kingston KVR1333D3E9S 4096 MB 240-pin DIMM DDR3 SDRAM 1.5 volt ~ NIC: Intel EXPI9301CTBLK (LAN) ~ NIC: D-Link DFE-528TX (CAM) ~ Hard Disk: Western Digital WD10JFCX Red ~ Case: Cooler Master HAF XB ~ power consumption: 21 Watts.

              1 Reply Last reply Reply Quote 0
              • N
                Nadar
                last edited by

                To my surprise I just tested this and can confirm the problem on 2.1 RC1. I also use policy routing, not default gateway, to route the VPN traffic, and I have nothing else that passes traffic for packets coming from "VPN subnet". It's seems clear to me that the "pass" on the LAN rule is a match for "pass" and thus no further rules are processed and no more consideration is made to whether that packet should be allowed. What I don't understand is why pfSense fall back to the routing table when the policy routing doesn't work. I can see that this could be wanted behaviour in some cases, but certainly not in all (it could for example route bandwith intensive traffic down an expensive link when the cheap link went down). I disagree that this should be an option in the VPN client, I'd rather have the chance to decide this on a per (policy routing) rule basis.

                I havent tested with a floating block rule like panz suggests, but if that indeed works it makes me even more interested to get a detailed explanation to how and when firewall rules are processed. Are the floating rules processed before or after the interface rules, and are they processed several times for a single packet (that is for each interface it passes)? I've yet to find a detailed explanation for this, but I'm sure it must exist here somewhere? It's hard to design rules when you're not sure how they are processed.

                1 Reply Last reply Reply Quote 0
                • panzP
                  panz
                  last edited by

                  @Nadar:

                  Are the floating rules processed before or after the interface rules, and are they processed several times for a single packet (that is for each interface it passes)? I've yet to find a detailed explanation for this, but I'm sure it must exist here somewhere? It's hard to design rules when you're not sure how they are processed.

                  Floating rules are processed before the others.

                  All others interface rules are processed top –> down with the condition: first match = stop processing (so, if a packet matches the rules it encountered, further processing is halted).

                  One thing to consider is stateful inspection: if a packet is a reply to a legitimate one (= reply packet is matching the table) then it is allowed.

                  See "Firewalling with OpenBSD's PF packet filter" http://home.nuug.no/~peter/pf/en/

                  pfSense 2.3.2-RELEASE-p1 (amd64)
                  motherboard: MSI C847MS-E33 Micro ATX (with Intel Celeron CPU 847 @ 1.10 GHz) ~ PSU: Corsair VS350 ~ RAM: Kingston KVR1333D3E9S 4096 MB 240-pin DIMM DDR3 SDRAM 1.5 volt ~ NIC: Intel EXPI9301CTBLK (LAN) ~ NIC: D-Link DFE-528TX (CAM) ~ Hard Disk: Western Digital WD10JFCX Red ~ Case: Cooler Master HAF XB ~ power consumption: 21 Watts.

                  1 Reply Last reply Reply Quote 0
                  • F
                    FastLaneJB
                    last edited by

                    Hi all,

                    This has also been bugging me for a while and I'd just given up but with the event of 2.1 final I decided to reload my firewall from scratch and have another go. Tried a few of the suggestions in this thread that hadn't occured to me before but nothing seemed to work. However I believe I've cracked it in my limited testing and once you see why, the answer is obvious :)

                    Go to Advanced and then Miscellaneous and down in Gateway Monitoring you'll see "Skip rules when gateway is down" which on my fresh 2.1 install is off by default. It has the following description.

                    "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"

                    So basically when the VPN Gateway is down it puts the rule in but with the default gateway ruining the whole point.

                    With this ticked I then set the "Default allow LAN to any rule" and "Default allow LAN IPv6 to any rule" to run if Source is NOT my VPN Alias.

                    So now those hosts have Internet when the VPN is up via the VPN. When it goes down they lose Internet completely.

                    Hope this helps others. Took a while to figure it out.

                    1 Reply Last reply Reply Quote 0
                    • N
                      Nadar
                      last edited by

                      Great find FastLaneJB! I simply enabled this (I have a "VPN source net" instead of a VPN source alias - with no default allow rule), and it seems to behave largely as wanted. I do however still get some traffic to and from my "VPN source net" a while after taking down the VPN, but I haven't properly investigated the cause. It could have several reasons, not necessarily related to pfSense, and I'll have to take a closer look to figure out exactly what's happening.

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

                        thanks to fastlane and everyone else for the information.  Unfortunately, this doesnt seem to work for me.

                        I am trying to block all LAN traffic when my VPN goes down, and am about ready to drive myself crazy.

                        Anyone have any thoughts?

                        cheers

                        1 Reply Last reply Reply Quote 0
                        • panzP
                          panz
                          last edited by

                          @FastLaneJB:

                          Hi all,

                          This has also been bugging me for a while and I'd just given up but with the event of 2.1 final I decided to reload my firewall from scratch and have another go. Tried a few of the suggestions in this thread that hadn't occured to me before but nothing seemed to work. However I believe I've cracked it in my limited testing and once you see why, the answer is obvious :)

                          Go to Advanced and then Miscellaneous and down in Gateway Monitoring you'll see "Skip rules when gateway is down" which on my fresh 2.1 install is off by default. It has the following description.

                          "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"

                          So basically when the VPN Gateway is down it puts the rule in but with the default gateway ruining the whole point.

                          With this ticked I then set the "Default allow LAN to any rule" and "Default allow LAN IPv6 to any rule" to run if Source is NOT my VPN Alias.

                          So now those hosts have Internet when the VPN is up via the VPN. When it goes down they lose Internet completely.

                          Hope this helps others. Took a while to figure it out.

                          This doesn't solve 2 problems.

                          1. DNS leaks. The pfsense firewall itself will send out DNS queries even if your method is applied;

                          2. this method doesn't allow the creation of automated rules for VPN traffic itself so, for example, Amazon S3 won't work or will work intermittently, being "caught" by the default deny IPv4/IPv6 rule.

                          pfSense 2.3.2-RELEASE-p1 (amd64)
                          motherboard: MSI C847MS-E33 Micro ATX (with Intel Celeron CPU 847 @ 1.10 GHz) ~ PSU: Corsair VS350 ~ RAM: Kingston KVR1333D3E9S 4096 MB 240-pin DIMM DDR3 SDRAM 1.5 volt ~ NIC: Intel EXPI9301CTBLK (LAN) ~ NIC: D-Link DFE-528TX (CAM) ~ Hard Disk: Western Digital WD10JFCX Red ~ Case: Cooler Master HAF XB ~ power consumption: 21 Watts.

                          1 Reply Last reply Reply Quote 0
                          • N
                            Nadar
                            last edited by

                            @panz:

                            This doesn't solve 2 problems.

                            1. DNS leaks. The pfsense firewall itself will send out DNS queries even if your method is applied;

                            2. this method doesn't allow the creation of automated rules for VPN traffic itself so, for example, Amazon S3 won't work or will work intermittently, being "caught" by the default deny IPv4/IPv6 rule.

                            I don't see the relevance of your "problems" and this thread. The thread title is "Prevent Certain LAN ips from accessing WAN when OpenVPN goes down", and the way I understand that is that it's about preventing pfSense from rerouting policy routed traffic to the default gateway once the "policy routed gateway" becomes unavailable, and as such it seems spot on.

                            Regarding 1) That depends on how you configure your network. If you configure the client(s) in question to solely use VPN provided DNS servers, this DNS traffic will also cease when the VPN goes down. I don't know why you would want pfSense itself, or the DNS forwarder, to loose DNS connectivity in that situation, but if that's what you want you could probably also configure them to only use the VPN provider's DNS.

                            1. I don't even understand what you mean or how you create automated rules for VPN traffic, but provided that these automated rules were created correctly this solution should apply to them as well.
                            1 Reply Last reply Reply Quote 0
                            • panzP
                              panz
                              last edited by

                              @Nadar:

                              I don't see the relevance of your "problems" and this thread. The thread title is "Prevent Certain LAN ips from accessing WAN when OpenVPN goes down", and the way I understand that is that it's about preventing pfSense from rerouting policy routed traffic to the default gateway once the "policy routed gateway" becomes unavailable, and as such it seems spot on.

                              I think that all of us are using a VPN for privacy and security, so preventing DNS leaks is a matter we should deal with.

                              See https://redmine.pfsense.org/issues/753

                              @Nadar:

                              1. I don't even understand what you mean or how you create automated rules for VPN traffic, but provided that these automated rules were created correctly this solution should apply to them as well.

                              Perhaps you should take a look at your /tmp/rules.debug  ::)

                              pfSense 2.3.2-RELEASE-p1 (amd64)
                              motherboard: MSI C847MS-E33 Micro ATX (with Intel Celeron CPU 847 @ 1.10 GHz) ~ PSU: Corsair VS350 ~ RAM: Kingston KVR1333D3E9S 4096 MB 240-pin DIMM DDR3 SDRAM 1.5 volt ~ NIC: Intel EXPI9301CTBLK (LAN) ~ NIC: D-Link DFE-528TX (CAM) ~ Hard Disk: Western Digital WD10JFCX Red ~ Case: Cooler Master HAF XB ~ power consumption: 21 Watts.

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

                                I also have my WAN send data through OpenVPN. After about 5 days the VPN goes down and then stops all traffic (which is preferred). Is there a way for pfsense to detect that the VPN connect is down and then automatically restart the service? or maybe there is a way to have a rule that restarts the VPN connection every 3 days?

                                1 Reply Last reply Reply Quote 0
                                • M
                                  m3ki
                                  last edited by

                                  In Client VPN settings there is an option resolv-retry infinite checkbox, or you can passit as a parameter in advanced box.

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

                                    @m3ki:

                                    In Client VPN settings there is an option resolv-retry infinite checkbox, or you can passit as a parameter in advanced box.

                                    I am not seeing the option resolv-rety infinite in client settings. I have "Infinitely resolve server" checked if that is what you are refering to but that does not seem to fix the VPN when it goes down. Could you explain how "passit" works in the advanced box? I have a very basic knowledge of home network systems so please feel free to explain it as if I have no clue.

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      m3ki
                                      last edited by

                                      What I mean to say is you can add any parameters that are available to any openvpn client just type them on each line of advanced box.

                                      ie
                                      resolv-retry infinite;
                                      But I don't think this setting is what you need. This setting seems to infinitely establish connection until successful.

                                      All other settings can be found here:
                                      http://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html

                                      On my system pfsense automatically reconnects when the connection fails.

                                      It's best to check your logs of openvpn to see what happens when connection fails. You can see that in Status->System Logs->openvpn.

                                      Though I am the original poster and my issue with blocking connections was resolved I am not sure getting off topic is acceptable in this forum.
                                      I would be more happy to help with anything I know. It's probably best to make another topic for this :)
                                      Make a thread and maybe let us know where to go.
                                      There you can post your logs and I am sure everyone will try to help.

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

                                        Could anyone here help me, I am trying to configure a floating rule to block traffic (WAN) from a specific IP/port (192.168.12.5:47864) when VPN goes down, but still allow everything else via WAN on (192.168.12.5).

                                        I configured a floating rule as mentioned previously in this thread as such:

                                        Action: block
                                        NOT A QUICK RULE
                                        Interface: WAN
                                        Direction: Any
                                        TCP/IP Version: IPv4
                                        Protocol: TCP/UDP
                                        Source: 192.168.12.5
                                        Source port range (to&from): 47864
                                        Destination: any
                                        Destination port range: any
                                        log: checked
                                        Description: Kill WAN if VPN DOWN

                                        But tested by disabling openvpn, then watched as the traffic resumed on WAN (fail).

                                        Thanks for help all!

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

                                          Again, it's post-NAT so you can't match on the source address.  See the other thread which is the same solution

                                          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
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.