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

    pfsense constantly losing connectivity to NordVPN

    Scheduled Pinned Locked Moved OpenVPN
    18 Posts 4 Posters 3.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.
    • P
      pftdm007
      last edited by pftdm007

      Hello,

      after having setup nordvpn with openvpn, it worked flawlessly for a few weeks then about a week ago, it's been constantly losing internet connectivity.

      Symptoms:

      • No internet, cannot resolve anything, no ping, etc
      • pfsense dashboard shows the gateway as Offline or "Unknown" and the OpenVPN client instance as DOWN (red arrow pointing downwards)
      • Firewall logs are NOT blocking Nord's DNS or their recommended VPN server
      • Snort is NOT blocking anything (anyway its NOT running on WAN)
      • pfblocker or DNSBL are apparently NOT blocking anything (pfblocker would show up in FW logs), and DNSBL would show in the Alerts logs

      System reboot doesnt help.
      Restarting OpenVPN service doesnt help

      The only workaround I found is:

      • Switching the system default gateway (system > Routing) to "automatic" or WAN
      • Restarting OpenVPN service or rebooting pfsense
      • Re-switching the default GW to NORDVPN

      Until this re-occurs...

      OpenVPN logs starting when the VPN was down, performing the above workaround until the connection is restored:

      ...
Apr 7 17:00:25	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 17:00:16	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:58:44	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:58:44	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 16:58:44	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:58:44	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:58:04	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:58:04	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 16:58:04	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:58:04	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: CMD 'status 2'
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:53:13	openvpn	50845	Initialization Sequence Completed
Apr 7 16:53:13	openvpn	50845	/usr/local/sbin/ovpn-linkup ovpnc1 1500 1585 xxx.xxx.xxx.xxx 255.255.255.0 init
Apr 7 16:53:13	openvpn	50845	/sbin/route add -net xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx 255.255.255.0
Apr 7 16:53:13	openvpn	50845	/sbin/ifconfig ovpnc1 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx mtu 1500 netmask 255.255.255.0 up
Apr 7 16:53:13	openvpn	50845	TUN/TAP device /dev/tun1 opened
Apr 7 16:53:13	openvpn	50845	TUN/TAP device ovpnc1 exists previously, keep at program end
Apr 7 16:53:13	openvpn	50845	ROUTE_GATEWAY xxx.xxx.xxx.xxx/255.255.255.0 IFACE=em5 HWADDR=XX:XX:XX:XX:XX:XX
Apr 7 16:53:12	openvpn	50845	/usr/local/sbin/ovpn-linkdown ovpnc1 1500 1585 xxx.xxx.xxx.xxx 255.255.255.0 init
Apr 7 16:53:12	openvpn	50845	Closing TUN/TAP interface
Apr 7 16:53:12	openvpn	50845	NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Apr 7 16:53:12	openvpn	50845	Preserving previous TUN/TAP instance: ovpnc1
Apr 7 16:53:12	openvpn	50845	Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 7 16:53:12	openvpn	50845	Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 7 16:53:12	openvpn	50845	Data Channel: using negotiated cipher 'AES-256-GCM'
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: data channel crypto options modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: adjusting link_mtu to 1657
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: peer-id set
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: route-related options modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: route options modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: --ifconfig/up options modified
Apr 7 16:53:12	openvpn	50845	Socket Buffers: R=[524288->524288] S=[524288->524288]
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: compression parms modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: explicit notify parm(s) modified
Apr 7 16:53:12	openvpn	50845	OPTIONS IMPORT: timers and/or timeouts modified
Apr 7 16:53:12	openvpn	50845	PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway xxx.xxx.xxx.xxx,topology subnet,ping 60,ping-restart 180,ifconfig xxx.xxx.xxx.xxx 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Apr 7 16:53:12	openvpn	50845	SENT CONTROL [ca1234.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Apr 7 16:53:11	openvpn	50845	[ca1234.nordvpn.com] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
Apr 7 16:53:11	openvpn	50845	Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512
Apr 7 16:53:11	openvpn	50845	VERIFY OK: depth=0, CN=ca1234.nordvpn.com
Apr 7 16:53:11	openvpn	50845	VERIFY EKU OK
Apr 7 16:53:11	openvpn	50845	++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Apr 7 16:53:11	openvpn	50845	Validating certificate extended key usage
Apr 7 16:53:11	openvpn	50845	VERIFY KU OK
Apr 7 16:53:11	openvpn	50845	VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA7
Apr 7 16:53:11	openvpn	50845	VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Apr 7 16:53:11	openvpn	50845	VERIFY WARNING: depth=2, unable to get certificate CRL: C=PA, O=NordVPN, CN=NordVPN Root CA
Apr 7 16:53:11	openvpn	50845	VERIFY WARNING: depth=1, unable to get certificate CRL: C=PA, O=NordVPN, CN=NordVPN CA7
Apr 7 16:53:11	openvpn	50845	VERIFY WARNING: depth=0, unable to get certificate CRL: CN=ca1234.nordvpn.com
Apr 7 16:53:11	openvpn	50845	TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:1194, sid=dsfsdfsf sdfsdfdsf
Apr 7 16:53:11	openvpn	50845	UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Apr 7 16:53:11	openvpn	50845	UDPv4 link local (bound): [AF_INET]xxx.xxx.xxx.xxx12:0
Apr 7 16:53:11	openvpn	50845	Socket Buffers: R=[42080->524288] S=[57344->524288]
Apr 7 16:53:11	openvpn	50845	TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Apr 7 16:53:11	openvpn	50845	Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:53:11	openvpn	50845	Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:53:11	openvpn	50845	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 7 16:52:45	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:45	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:45	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:36	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:35	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:52:03	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:52:03	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:52:03	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:51:53	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:51:23	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:51:23	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:51:23	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:51:13	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:50:32	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: Client disconnected
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: CMD 'state 1'
Apr 7 16:48:26	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:48:11	openvpn	50845	Restart pause, 300 second(s)
Apr 7 16:48:11	openvpn	50845	SIGUSR1[soft,init_instance] received, process restarting
Apr 7 16:48:11	openvpn	50845	Could not determine IPv4/IPv6 protocol
Apr 7 16:48:11	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:47:55	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:47:39	openvpn	50845	Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:47:39	openvpn	50845	Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:47:39	openvpn	50845	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 7 16:42:39	openvpn	50845	Restart pause, 300 second(s)
Apr 7 16:42:39	openvpn	50845	SIGUSR1[soft,init_instance] received, process restarting
Apr 7 16:42:39	openvpn	50845	Could not determine IPv4/IPv6 protocol
Apr 7 16:42:39	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:42:22	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:42:06	openvpn	50845	Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:42:06	openvpn	50845	Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:42:06	openvpn	50845	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 7 16:37:06	openvpn	50845	Restart pause, 300 second(s)
Apr 7 16:37:06	openvpn	50845	SIGUSR1[soft,init_instance] received, process restarting
Apr 7 16:37:06	openvpn	50845	Could not determine IPv4/IPv6 protocol
Apr 7 16:37:06	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:36:50	openvpn	50845	RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)
Apr 7 16:36:33	openvpn	50845	Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:36:33	openvpn	50845	Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 7 16:36:33	openvpn	50845	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
...

      I am worried about the recurring:

      Apr 7 16:58:04	openvpn	50845	MANAGEMENT: Client connected from /var/etc/openvpn/client1/sock
Apr 7 16:57:54	openvpn	50845	MANAGEMENT: Client disconnected

      Clearly OpenVPN is LOSING connection to Nord's servers:

      RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)

      But WHY? Anybody has an idea how to troubleshoot this? Unfortunately I cannot predict when this will re-occur and WHY this started only about a week ago and why it didnt happen since the beginning....

      Looking forward to replies from the VPN Gurus!

      V T 2 Replies Last reply Reply Quote 0
      • V
        Vova 0
        last edited by 

        
* [code_text](link url
        P 1 Reply Last reply Reply Quote 0
        • P
          pftdm007 @Vova 0
          last edited by

          @vova-0 What ???

          1 Reply Last reply Reply Quote 0
          • V
            viragomann @pftdm007
            last edited by

            @pftdm007 said in pfsense constantly losing connectivity to NordVPN:

            Re-switching the default GW to NORDVPN

            That's a bad idea, I think.

            Better select "Automatic" for the default gateway.
            I guess, NordVPN will push the default route to you. So the gateway changes anyway, when the VPN is established. Otherwise you could set that in the client settings.

            P 1 Reply Last reply Reply Quote 0
            • P
              pftdm007 @viragomann
              last edited by pftdm007

              @viragomann

              When I select "automatic", my public IP becomes visible... That's an issue I had while setting up everything and could NEVER find the cause of this issue... Very strange, NordVPN were unable to troubleshoot....

              The workaround was to manually set the default GW to NORDVPN which made my public IP hidden.

              Perhaps that workaround is causing other issues afterall... Your thoughts?

              P V 2 Replies Last reply Reply Quote 0
              • P
                pftdm007 @pftdm007
                last edited by

                I think DNSBL is the root cause of all my problems. I just realized that on the subnets behind DNSBL, my public IP is visible to the internet, but on the subnets not behind DNSBL, the public IP is hidden.

                Moreover, DNSBL seems to be intermittently working as sometimes forbidden websites are accessible, sometimes not...

                I think the overall issue is some sort of bug or corruption or just that it is impossible to use OpenVPN+DNSBL+VLAN's with pfsense... Hopefully I am wrong.

                Out of curiosity, are anyone using DNSBL alongside OpenVPN?

                If so, how are the DNS servers passed to the LAN clients behind the VPN? Where are these DNS server defined ??

                1 Reply Last reply Reply Quote 0
                • V
                  viragomann @pftdm007
                  last edited by

                  @pftdm007 said in pfsense constantly losing connectivity to NordVPN:

                  The workaround was to manually set the default GW to NORDVPN which made my public IP hidden.
                  Perhaps that workaround is causing other issues afterall... Your thoughts?

                  By setting the default gateway to NordVPN will cause that there is no traffic able to going out, when the VPN is down. Hence also DNS request cannot be not passed out and resolution will fail.

                  This can only work, if you state an IP for the VPN server and the VPN connection is up all the time.

                  I think DNSBL is the root cause of all my problems. I just realized that on the subnets behind DNSBL, my public IP is visible to the internet, but on the subnets not behind DNSBL, the public IP is hidden.

                  So you might rather talk about DNS leaks than your upstream traffic going out to WAN?

                  How is the DNSBL done in your setup? Is it on pfSense or on an other server?

                  P 1 Reply Last reply Reply Quote 0
                  • T
                    TheNarc @pftdm007
                    last edited by

                    @pftdm007 said in pfsense constantly losing connectivity to NordVPN:

                    RESOLVE: Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve)

                    How do you have DNS configured? This makes me wonder if it's getting into a situation where it's trying to resolve hostnames via your VPN gateway when the VPN connection is down. I would highly recommend using IP addresses instead of hostnames in your VPN client configurations so that the establishment of VPN client connections is not dependent on DNS at all.

                    1 Reply Last reply Reply Quote 0
                    • P
                      pftdm007 @viragomann
                      last edited by pftdm007

                      @viragomann said in pfsense constantly losing connectivity to NordVPN:

                      So you might rather talk about DNS leaks than your upstream traffic going out to WAN?

                      Yes I am. Long story short, if I do a "whats my IP" search, google returns Nord's IP, Duckduckgo returns my public (real) IP from ISP, expressvpn also returns my real IP, etc... Its all over the place. Clearly something's not right. Just to be clear, this ONLY happens when the system default GW is set to automatic or WAN... Not with Nordvpn. However setting the default GW to Nordvpn, the issue I described here initially will happen (Cannot resolve host address: ca1234.nordvpn.com:1194 (Name does not resolve))

                      Also DNSBL is on pfsense, on the same machine as OpenVPN. DNSBL protects VLAN 1 & 2, while VLAN3 bypasses DNSBL completely (the DNS servers IP's are passed to the clients from the DHCP server settings).

                      In short:
                      VLAN 1 -> DNS servers blank in DHCP server so unbound is used , FW rules send traffic to Nord's gateway

                      VLAN 2 -> Identical to VLAN1

                      VLAN 3 -> DNS servers are specified by DHCP server so DNSBL is completely bypassed, FW rules send traffic to Nord's gateway

                      @thenarc said in pfsense constantly losing connectivity to NordVPN:

                      How do you have DNS configured? This makes me wonder if it's getting into a situation where it's trying to resolve hostnames via your VPN gateway when the VPN connection is down. I would highly recommend using IP addresses instead of hostnames in your VPN client configurations so that the establishment of VPN client connections is not dependent on DNS at all.

                      I will try using Nord's IP instead of the FQDN in OpenVPN's client config and see what happens, but in the end, why do I need to set the system's default gateway to Nordvpn instead of automatic to prevent DNS leakage (or my real IP being visible)?

                      V 2 Replies Last reply Reply Quote 0
                      • V
                        viragomann @pftdm007
                        last edited by

                        @pftdm007
                        So you will have to direct DNS upstream traffic from unbound is directed out to the VPN gateway.

                        If you only need the Resolver for VLANs which should not get internet access, when the DNS is down anyway, you can simply state to VPN interface only for outgoing connections in the settings.

                        If you want unbound to also resolve when the VPN is down, you will have to run it in forwarder mode. So it directs DNS requests to the servers stated in General settings accordingly to the routing table.

                        P 1 Reply Last reply Reply Quote 0
                        • P
                          pftdm007 @viragomann
                          last edited by

                          @viragomann said in pfsense constantly losing connectivity to NordVPN:

                          So you will have to direct DNS upstream traffic from unbound is directed out to the VPN gateway.

                          Not sure I understand that. Can you elaborate a bit? Unbound is serving VLAN 1 & 2 because I want DNSBL on those. VLAN3 doesnt need DNSBL (its a DMZ) so I am passing Nord's DNS servers directly via the DHCP server settings. Simple enough.

                          @viragomann said in pfsense constantly losing connectivity to NordVPN:

                          If you only need the Resolver for VLANs which should not get internet access, when the DNS is down anyway, you can simply state to VPN interface only for outgoing connections in the settings.

                          Sorry, this sentence doesnt make sense to me.

                          @viragomann said in pfsense constantly losing connectivity to NordVPN:

                          If you want unbound to also resolve when the VPN is down, you will have to run it in forwarder mode.

                          Its already running in FW mode, always has been.

                          1 Reply Last reply Reply Quote 0
                          • V
                            viragomann @pftdm007
                            last edited by

                            @pftdm007 said in pfsense constantly losing connectivity to NordVPN:

                            why do I need to set the system's default gateway to Nordvpn instead of automatic to prevent DNS leakage (or my real IP being visible)?

                            Presumably because NordVPN is not the default gateway.
                            I guess, you have checked "Don't pull or don't add routes" in the client settings.

                            @pftdm007 said in pfsense constantly losing connectivity to NordVPN:

                            @viragomann said in pfsense constantly losing connectivity to NordVPN:

                            So you will have to direct DNS upstream traffic from unbound is directed out to the VPN gateway.

                            Not sure I understand that. Can you elaborate a bit? Unbound is serving VLAN 1 & 2 because I want DNSBL on those. VLAN3 doesnt need DNSBL (its a DMZ) so I am passing Nord's DNS servers directly via the DHCP server settings. Simple enough.

                            pfSense routes out upstream traffic accordingly to its routing table as already mentioned. So if your WAN gateway is the default, DNS traffic goes out on WAN.

                            Hence if you want VLAN 1 & 2 to use unbound cause of DNSBL you have to direct outgoing requests from unbound to the vpn gateway.

                            My assumption is that VLAN 1 & 2 should never go out to the WAN, but only to the VPN. If that's the case, you can also direct ounbound's upstream strictly to the VPN gateway.
                            But I think, that won't be possible in forwarder mode, except if you state the NordVPN's IP in the client settings.

                            P 1 Reply Last reply Reply Quote 0
                            • P
                              pftdm007 @viragomann
                              last edited by

                              @viragomann

                              @viragomann said in pfsense constantly losing connectivity to NordVPN:

                              I guess, you have checked "Don't pull or don't add routes" in the client settings.

                              You are right. This was recommended by Nord's if I recall correctly to minimize chance of DNS leaks...

                              @viragomann said in pfsense constantly losing connectivity to NordVPN:

                              Hence if you want VLAN 1 & 2 to use unbound cause of DNSBL you have to direct outgoing requests from unbound to the vpn gateway.

                              Already setup Unbound to use only the VPN gateways.

                              @viragomann said in pfsense constantly losing connectivity to NordVPN:

                              My assumption is that VLAN 1 & 2 should never go out to the WAN, but only to the VPN

                              NONE of the VLAN's should go out thru WAN, all should go thru VPN. The only distinction is that VLAN3 doesnt use Unbound for DNS resolution but use Nord's DNS directly. However, it is forced to go out thru VPN because of the FW rule which forces traffic to use the VPN gateway.

                              Thats the only interface behaving 100% as expected. Bypassing unbound seems to do the trick........

                              1 Reply Last reply Reply Quote 0
                              • P
                                pftdm007
                                last edited by pftdm007

                                Regarding the main issue of this thread

                                It is still a no go... A few days ago I setup a multi-gateway VPN group following the instructions found here. First of all, congrats to whoever wrote this site, its flawless and super well detailed.

                                Things worked out very reliably until now. FYI I work from home and use my internet connection with pfsense all day. About 10mins ago, I got a notification email from pfsense saying

                                Notifications in this message: 1
================================
16:49:13 MONITOR: NORDVPN3_VPNV4 has packet loss, omitting from routing group NORDVPN_Group
10.8.0.1|10.8.0.3|NORDVPN3_VPNV4|15.596ms|4.6ms|27%|down|highloss

                                I tried to send emails, browse the web, here we go again. No internet.

                                I am no longer seeing DNS resolution issues in OpenVPN's logs because it is now configured with Nord's IP adresses instead of their FQDN.

                                When the connection crashed, the dashboard widget had the 3rd VPN gateway (from the group) saying Status = "Unknown" & RTT, RTTsd & Loss = "Pending"

                                I restarted all three OpenVPN services under Status > OpenVPN and the internet came back. However, things are not perfect yet (see screenshot).

                                pfs.png
                                So whats going on with this ? Is it Nordvpn having issues ? I will send them this forum thread so they can see for themselves, but I suspect an issue with pfsense or openvpn more than anything else at this point.

                                Not to complain per se, but before setting up this VPN "stuff" (!) pfsense was rock solid for many years...

                                T 1 Reply Last reply Reply Quote 0
                                • T
                                  TheNarc @pftdm007
                                  last edited by

                                  @pftdm007 I can say from experience that Nord's servers (and I would venture to guess most VPN providers' servers) have relatively frequent transient latency and packet loss spikes. It's definitely not something you'd want to rely on for anything where ~100% uptime is mission critical.

                                  P 1 Reply Last reply Reply Quote 0
                                  • P
                                    pftdm007 @TheNarc
                                    last edited by

                                    @thenarc

                                    I feel the same, but why pfsense doesnt use the leftover interface from the VPN group that still is connected to their servers?

                                    In other words, why am I losing 100% connectivity to the internet if only one or 2 of the gateways are down? Shouldn't the 3rd one take over and cover everything until the other two that are down or experiencing timeouts,packet loss come back to normal?

                                    T 1 Reply Last reply Reply Quote 0
                                    • T
                                      TheNarc @pftdm007
                                      last edited by

                                      @pftdm007 You're correct, it should. And in my experience it does, but in can take a minute or two as existing connections through the tunnel that went down are broken and then need to be re-established through one that's still up. So it's not something that would be transparent for sure, but you're saying it just doesn't happen at all no matter how long you wait?

                                      I'm wondering whether you may want to try this option ( System > Advanced > Miscellaneous) to immediately kill all connections when a gateway goes down to (hopefully/maybe) reduce the lag time between a tunnel going down and any active connections using it being forced to reestablish over a tunnel that's still up. Of course it will have the byproduct of also killing any connections that are already going through a tunnel that's still up and making them reestablish as well. But maybe worth trying to see if it improves your observed behavior.

                                      fd9ddecd-6676-486a-a0b3-4f707b39d00d-image.png

                                      P 1 Reply Last reply Reply Quote 0
                                      • P
                                        pftdm007 @TheNarc
                                        last edited by pftdm007

                                        @thenarc said in pfsense constantly losing connectivity to NordVPN:

                                        So it's not something that would be transparent for sure, but you're saying it just doesn't happen at all no matter how long you wait?

                                        Yes, at least whne it happened yesterday I waited about 5 minutes or so but the status of the gateways stayed the same, and the connection was still down. After I force restarted the Openvpn service, the gateways went back up (albeit 2 of them still screwed up as per screenshot I posted above).

                                        @thenarc said in pfsense constantly losing connectivity to NordVPN:

                                        making them reestablish as well. But maybe worth trying to see if it improves your observed behavior.

                                        I agree with you, that makes sense, it has pretty much the same effect as issuing a force restart on the underlying services (without of course restarting them for real)... But I wonder, can it cause data corruption or other issues with services that are actively communicating, etc? I have in mind, for example, if I am on a VOIP call, will my call be dropped or will I only see a small "hiccup" and nothing else? This is more of a general networking question than a VPN question.....

                                        EDIT: I just realised that my VOIP ATA has been offline for many hours, if not for more than a day hence causing me to miss several phone calls... The ATA couldnt, for some esoteric reasons, establish a connection to the VOIP server even if the FW rules are all in order (and worked for many years before implementing this disaster of vpn). Rebooting pfsense solved it but I dont trust this for long. Will give myself a few days then I'm reverting everything and cancelling nordvpn.

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