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

    OpenVPN up but no traffic passing

    Scheduled Pinned Locked Moved OpenVPN
    23 Posts 7 Posters 17.6k 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.
    • B
      badserver
      last edited by

      Hi all,

      I'm stationed overseas and I'm trying to use pfSense with StrongVPN to access Hulu, netflix, etc. I've followed the steps outlined in forum.pfsense.org/index.php?topic=29944.0 and the VPN reports that it's up when I look at Status > OpenVPN. I've created an alias group to route only a few devices from my network out the StrongVPN connection and I've created firewall rules to handle the routing out. When I add my PC to that alias group I can't web browse at all and I'm also unable to ping the distant end virtual IP (i can ping the local virtual IP fine). Also, when doing a packet capture I can see my local virtual IP attempting to send traffic to the distant end with no response coming back. I thought it might be something with the StrongVPN server so I've already switched to a different server.

      Has anyone run into problems like this in the past? Any help would be greatly appreciated!

      1 Reply Last reply Reply Quote 0
      • B
        badserver
        last edited by

        Pulled the logs from the VPN initialization:

        Apr 27 13:13:34 openvpn[56942]: Initialization Sequence Completed
        Apr 27 13:13:34 openvpn[56942]: /sbin/route add -net 10.8.1.73 10.8.1.77 255.255.255.255
        Apr 27 13:13:34 openvpn[56942]: /sbin/route add -net 128.0.0.0 10.8.1.77 128.0.0.0
        Apr 27 13:13:34 openvpn[56942]: /sbin/route add -net 0.0.0.0 10.8.1.77 128.0.0.0
        Apr 27 13:13:34 openvpn[56942]: /sbin/route add -net 98.158.127.42 192.168.1.1 255.255.255.255
        Apr 27 13:13:32 openvpn[56942]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1562 10.8.1.78 10.8.1.77 init
        Apr 27 13:13:32 openvpn[56942]: /sbin/ifconfig ovpnc1 10.8.1.78 10.8.1.77 mtu 1500 netmask 255.255.255.255 up
        Apr 27 13:13:32 openvpn[56942]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
        Apr 27 13:13:32 openvpn[56942]: TUN/TAP device /dev/tun1 opened
        Apr 27 13:13:32 openvpn[56942]: ROUTE default_gateway=192.168.1.1
        Apr 27 13:13:32 openvpn[56942]: OPTIONS IMPORT: –ip-win32 and/or --dhcp-option options modified
        Apr 27 13:13:32 openvpn[56942]: OPTIONS IMPORT: route-related options modified
        Apr 27 13:13:32 openvpn[56942]: OPTIONS IMPORT: route options modified
        Apr 27 13:13:32 openvpn[56942]: OPTIONS IMPORT: –ifconfig/up options modified
        Apr 27 13:13:32 openvpn[56942]: OPTIONS IMPORT: timers and/or timeouts modified
        Apr 27 13:13:32 openvpn[56942]: PUSH: Received control message: 'PUSH_REPLY,ping 1,ping-restart 60,route-delay 2,route-metric 1,dhcp-option DNS 98.158.112.60,dhcp-option DNS 199.127.248.22,route 10.8.1.73,topology net30,ifconfig 10.8.1.78 10.8.1.77'
        Apr 27 13:13:31 openvpn[56942]: SENT CONTROL [vpn-in26]: 'PUSH_REQUEST' (status=1)
        Apr 27 13:13:29 openvpn[56942]: [vpn-in26] Peer Connection Initiated with 98.158.127.42:4672
        Apr 27 13:13:29 openvpn[56942]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
        Apr 27 13:13:29 openvpn[56942]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
        Apr 27 13:13:29 openvpn[56942]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
        Apr 27 13:13:29 openvpn[56942]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
        Apr 27 13:13:29 openvpn[56942]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
        Apr 27 13:13:18 openvpn[56942]: VERIFY OK: depth=0, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=vpn-in26/emailAddress=techies@reliablehosting.com
        Apr 27 13:13:18 openvpn[56942]: VERIFY OK: depth=1, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=ovpn041/emailAddress=techies@reliablehosting.com
        Apr 27 13:13:17 openvpn[56942]: TLS: Initial packet from 98.158.127.42:4672, sid=a6d70d2b fd5d4a2a
        Apr 27 13:13:17 openvpn[56942]: UDPv4 link remote: 98.158.127.42:4672
        Apr 27 13:13:17 openvpn[56942]: UDPv4 link local (bound): 192.168.1.100:4672
        Apr 27 13:13:17 openvpn[56697]: Expected Remote Options hash (VER=V4): '6a64613d'
        Apr 27 13:13:17 openvpn[56697]: Local Options hash (VER=V4): '84ab6e17'

        1 Reply Last reply Reply Quote 0
        • B
          badserver
          last edited by

          A friend of mine with an identical setup is reporting the same issue after updating to the latest firmware. Can anyone else confirm the same problem?

          1 Reply Last reply Reply Quote 0
          • R
            Reiner030
            last edited by

            what is your "latest" version? ;) … 2.0.3. or an actual snapshot of 2.1-BETA1 ?

            I had before upgrade to 2.0.3. the problem that my "old, stable" firewalls can't talk to my new BETA ones (connection was up but no traffic inside)...
            I think that was because they used different OpenVPN versions.

            Since I made the update they have now same version and connection works great with inside traffic.

            So it would be best to check your OpenVPN version on both sides and upgrade if necessary.

            1 Reply Last reply Reply Quote 0
            • B
              badserver
              last edited by

              My current version is 2.0.3, the distant end is StrongVPN's hardware. I'm not sure what they're running. I'm thinking of rolling back to an earlier release if I can't find a workaround.

              1 Reply Last reply Reply Quote 0
              • R
                Reiner030
                last edited by

                • you checked out their FAQ http://strongvpn.com/faq.shtml ?

                • too big time differences can provide "bad keys" like this ~
                    TLS Error: local/remote TLS keys are out of sync: <remote ip="">:1194 [1]

                • you can increase verbose logging by writing option "verb 2" or "verb 3" into "Advanced" box.
                    Then it should be possible to see remote OpenVPN version, too. ;)

                verb2 shows vor instance my (2.0.3 pfsense) version:
                openvpn[61445]: OpenVPN 2.2.2 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013

                • Copy&Paste is more readable then screenshots ;)

                Apr 29 20:57:02 openvpn[62042]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
                Apr 29 20:57:02 openvpn[62042]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                Apr 29 20:57:02 openvpn[62042]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                Apr 29 20:57:02 openvpn[62042]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                Apr 29 20:57:02 openvpn[62042]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                Apr 29 20:57:02 openvpn[62042]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 172.16.4.1 172.16.4.2'                **
                Apr 29 20:57:02 openvpn[62042]: VERIFY OK: depth=0, …
                Apr 29 20:57:02 openvpn[62042]: CRL CHECK OK: …
                Apr 29 20:57:02 openvpn[62042]: VERIFY SCRIPT OK: depth=0…
                Apr 29 20:57:01 openvpn[62042]: VERIFY OK: depth=1, …
                Apr 29 20:57:01 openvpn[62042]: CRL CHECK OK: …
                Apr 29 20:57:01 openvpn[62042]: VERIFY SCRIPT OK: depth=1…
                Apr 29 20:56:23 openvpn[62042]: Initialization Sequence Completed
                Apr 29 20:56:21 openvpn[62042]: [PAV-JWS1-ZWS8-Bridge] Peer Connection Initiated with <remote ip="">:1194

                ( ** interesting failure… perhaps this can be the reason why quagga routing won't setup as expected ? My Setup is on both sides 172.16.4.0/30 ...)</remote></remote>

                1 Reply Last reply Reply Quote 0
                • R
                  Reiner030
                  last edited by

                  http://strongvpn.com/setup.shtml refers btw to http://forum.pfsense.org/index.php?topic=29944.0

                  so you used all there given options yet which fits your needs?

                  -Note 2: for ease, here are the "advanced configuration" options you can copy and paste: (remember to keep the trailing ; in place.) --->

verb 5;tun-mtu 1500;fragment 1300;keysize 128;redirect-gateway def1;persist-key;
                  1 Reply Last reply Reply Quote 0
                  • B
                    badserver
                    last edited by

                    That's correct, I followed the steps given in http://forum.pfsense.org/index.php/topic,29944.0.html. I substituted some of their settings for the settings provided in the ovpn0xx.ovpn file. My verb is set to 5 right now, but when I get home I'll switch to 2 and re initiate the VPN and let you know. Thanks!

                    1 Reply Last reply Reply Quote 0
                    • R
                      Reiner030
                      last edited by

                      mmh,

                      ah sorry, yesterday was too late - mixed it with another post which had posted only 2 small pics from log…

                      I think this line is the problem:
                      Apr 27 13:13:32    openvpn[56942]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
                      Apr 27 13:13:32    openvpn[56942]: TUN/TAP device /dev/tun1 opened

                      can you fully stop/start the service without this error?

                      Perhaps it's enough to kill the pid which is holding the tun device

                      ovpns5: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
                      options=80000 <linkstate>inet6 fe80::225:90ff:fe26:1f22%ovpns5 prefixlen 64 scopeid 0x6e
                      inet 172.16.4.1 –> 172.16.4.2 netmask 0xffffffff
                      nd6 options=43 <performnud,accept_rtadv>Opened by PID 3002

                      => here by pid 3002 …  if not, then hopely a reboot helps...</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>

                      1 Reply Last reply Reply Quote 0
                      • B
                        badserver
                        last edited by

                        I've tried multiple reboots with no joy. When I stop and start the service this is what I get:

                        Apr 30 18:45:44 openvpn[1886]: Initialization Sequence Completed
                        Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 10.8.1.73 10.8.1.77 255.255.255.255
                        Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 128.0.0.0 10.8.1.77 128.0.0.0
                        Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 0.0.0.0 10.8.1.77 128.0.0.0
                        Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 98.158.127.42 192.168.1.1 255.255.255.255
                        Apr 30 18:45:42 openvpn[1886]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1562 10.8.1.78 10.8.1.77 init
                        Apr 30 18:45:42 openvpn[1886]: /sbin/ifconfig ovpnc1 10.8.1.78 10.8.1.77 mtu 1500 netmask 255.255.255.255 up
                        Apr 30 18:45:42 openvpn[1886]: TUN/TAP device /dev/tun1 opened
                        Apr 30 18:45:42 openvpn[1886]: ROUTE default_gateway=192.168.1.1
                        Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ip-win32 and/or --dhcp-option options modified
                        Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route-related options modified
                        Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route options modified
                        Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ifconfig/up options modified
                        Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: timers and/or timeouts modified
                        Apr 30 18:45:42 openvpn[1886]: PUSH: Received control message: 'PUSH_REPLY,ping 1,ping-restart 60,route-delay 2,route-metric 1,dhcp-option DNS 98.158.112.60,dhcp-option DNS 199.127.248.22,route 10.8.1.73,topology net30,ifconfig 10.8.1.78 10.8.1.77'
                        Apr 30 18:45:42 openvpn[1886]: SENT CONTROL [vpn-in26]: 'PUSH_REQUEST' (status=1)
                        Apr 30 18:45:40 openvpn[1886]: [vpn-in26] Peer Connection Initiated with 98.158.127.42:4672
                        Apr 30 18:45:40 openvpn[1886]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
                        Apr 30 18:45:40 openvpn[1886]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                        Apr 30 18:45:40 openvpn[1886]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                        Apr 30 18:45:40 openvpn[1886]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                        Apr 30 18:45:40 openvpn[1886]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                        Apr 30 18:45:36 openvpn[1886]: VERIFY OK: depth=0, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=vpn-in26/emailAddress=techies@reliablehosting.com
                        Apr 30 18:45:36 openvpn[1886]: VERIFY OK: depth=1, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=ovpn041/emailAddress=techies@reliablehosting.com
                        Apr 30 18:45:32 openvpn[1886]: TLS: Initial packet from 98.158.127.42:4672, sid=be10c338 72e02aff
                        Apr 30 18:45:32 openvpn[1886]: UDPv4 link remote: 98.158.127.42:4672
                        Apr 30 18:45:32 openvpn[1886]: UDPv4 link local (bound): 192.168.1.100:4672
                        Apr 30 18:45:32 openvpn[1841]: Expected Remote Options hash (VER=V4): '6a64613d'
                        Apr 30 18:45:32 openvpn[1841]: Local Options hash (VER=V4): '84ab6e17'
                        Apr 30 18:45:32 openvpn[1841]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 0,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
                        Apr 30 18:45:32 openvpn[1841]: Local Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
                        Apr 30 18:45:32 openvpn[1841]: Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
                        Apr 30 18:45:32 openvpn[1841]: Data Channel MTU parms [ L:1562 D:1450 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
                        Apr 30 18:45:32 openvpn[1841]: Socket Buffers: R=[42080->65536] S=[57344->65536]
                        Apr 30 18:45:32 openvpn[1841]: Control Channel MTU parms [ L:1562 D:166 EF:66 EB:0 ET:0 EL:0 ]
                        Apr 30 18:45:32 openvpn[1841]: LZO compression initialized
                        Apr 30 18:45:32 openvpn[1841]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
                        Apr 30 18:45:32 openvpn[1841]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
                        Apr 30 18:45:32 openvpn[1841]: Control Channel Authentication: using '/var/etc/openvpn/client1.tls-auth' as a OpenVPN static key file
                        Apr 30 18:45:32 openvpn[1841]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
                        Apr 30 18:45:32 openvpn[1841]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
                        Apr 30 18:45:32 openvpn[1841]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
                        Apr 30 18:45:32 openvpn[1841]: OpenVPN 2.2.2 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
                        Apr 30 18:45:32 openvpn[1841]: auth_user_pass_file = '[UNDEF]'
                        Apr 30 18:45:32 openvpn[1841]: pull = ENABLED
                        Apr 30 18:45:32 openvpn[1841]: client = ENABLED
                        Apr 30 18:45:32 openvpn[1841]: port_share_port = 0
                        Apr 30 18:45:32 openvpn[1841]: port_share_host = '[UNDEF]'
                        Apr 30 18:45:32 openvpn[1841]: ssl_flags = 0
                        Apr 30 18:45:32 openvpn[1841]: auth_user_pass_verify_script_via_file = DISABLED

                        1 Reply Last reply Reply Quote 0
                        • R
                          Reiner030
                          last edited by

                          mmh from log seems all ok…

                          interesting part should be:
                          @badserver:

                          Apr 30 18:45:44 openvpn[1886]: Initialization Sequence Completed
                          Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 10.8.1.73 10.8.1.77 255.255.255.255
                          Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 128.0.0.0 10.8.1.77 128.0.0.0
                          Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 0.0.0.0 10.8.1.77 128.0.0.0
                          Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 98.158.127.42 192.168.1.1 255.255.255.255
                          Apr 30 18:45:42 openvpn[1886]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1562 10.8.1.78 10.8.1.77 init
                          Apr 30 18:45:42 openvpn[1886]: /sbin/ifconfig ovpnc1 10.8.1.78 10.8.1.77 mtu 1500 netmask 255.255.255.255 up
                          Apr 30 18:45:42 openvpn[1886]: TUN/TAP device /dev/tun1 opened
                          Apr 30 18:45:42 openvpn[1886]: ROUTE default_gateway=192.168.1.1
                          Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ip-win32 and/or --dhcp-option options modified
                          Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route-related options modified
                          Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route options modified
                          Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ifconfig/up options modified
                          Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: timers and/or timeouts modified
                          Apr 30 18:45:42 openvpn[1886]: PUSH: Received control message: 'PUSH_REPLY,ping 1,ping-restart 60,route-delay 2,route-metric 1,dhcp-option DNS 98.158.112.60,dhcp-option DNS 199.127.248.22,route 10.8.1.73,topology net30,ifconfig 10.8.1.78 10.8.1.77'
                          Apr 30 18:45:42 openvpn[1886]: SENT CONTROL [vpn-in26]: 'PUSH_REQUEST' (status=1)
                          Apr 30 18:45:40 openvpn[1886]: [vpn-in26] Peer Connection Initiated with 98.158.127.42:4672

                          • can you ping the other side?
                          • can you see with tcpdump traffic on your interface (tcpdump -ni ovpnc1) ?
                          1 Reply Last reply Reply Quote 0
                          • B
                            badserver
                            last edited by

                            Ok, sorry for the long delay. Moved to a new house and had to wait for internet setup.

                            So, I can not ping the other side and all tcpdump traffic shows my internal hosts going out with no return traffic.

                            1 Reply Last reply Reply Quote 0
                            • R
                              Reiner030
                              last edited by

                              @badserver:

                              So, I can not ping the other side and all tcpdump traffic shows my internal hosts going out with no return traffic.

                              Mmh, can you tcpdump other side, too? So that you can see that traffic goes out and perhaps come back?
                              I guess that on other side the back routes are missing. so that the remote side did not know where to route the traffic.

                              1 Reply Last reply Reply Quote 0
                              • B
                                badserver
                                last edited by

                                Unfortunately the distant end is a StrongVPN node so I have no way to do a dump on the other side. A co-worker is having the exact same symptoms but his worked fine before he upgraded to 2.0.3. I set mine up with 2.0.3 and it's never worked for me.

                                1 Reply Last reply Reply Quote 0
                                • R
                                  Reiner030
                                  last edited by

                                  @badserver:

                                  Unfortunately the distant end is a StrongVPN node so I have no way to do a dump on the other side. A co-worker is having the exact same symptoms but his worked fine before he upgraded to 2.0.3. I set mine up with 2.0.3 and it's never worked for me.

                                  can you perhaps downgrade then to pfsense 2.0.2 ?

                                  http://files.nyi.pfsense.org/mirror/downloads/old/

                                  http://blog.pfsense.org/?p=694

                                  "biggest" change could be the Version update:

                                  • OpenVPN 2.2 stock again (Removed IPv6 patches since those are only needed on 2.1 now)

                                  and

                                  OpenVPN

                                  *    Clear the route for an OpenVPN endpoint IP when restarting the VPN, to avoid a situation where a learned route from OSPF or elsewhere could prevent an instance from restarting properly
                                  *    Always clear the OpenVPN route when using shared key, no matter how the tunnel network “CIDR” is set
                                  *    Use the actual OpenVPN restart routine when starting/stopping from services rather than killing/restarting manually
                                  *    Allow editing an imported CRL, and refresh OpenVPN CRLs when saving. [#2652]
                                  *    Fix interface assignment descriptions when using > 10 OpenVPN instances

                                  1 Reply Last reply Reply Quote 0
                                  • ?
                                    A Former User
                                    last edited by

                                    Have you done the Outbound NAT Rules ? It sounds to me that you missed that bit.

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      badserver
                                      last edited by

                                      I won't have time to downgrade until later this week, but I will post the results once I do it.

                                      Just out of curiosity, is there anyone out there that is running 2.0.3, connecting to StrongVPN (or any other commercial VPN provider) and routing traffic across it with no issues?

                                      1 Reply Last reply Reply Quote 0
                                      • R
                                        Reiner030
                                        last edited by

                                        no Idea… In knew someone who uses in his old company https://www.overplay.net/ for VPN connections...
                                        Perhaps you'll try an alternative to check if it's problematic only at StrongVPN.
                                        So this is the reason you can open ticket to StronVPN that there is a versions conflict in their system and hope they fix it quick or you switch to the functional alternative.

                                        1 Reply Last reply Reply Quote 0
                                        • C
                                          chevyn8
                                          last edited by

                                          After update, my openvpn is not usable (connect and not passing most of the traffic), looking for instructions to downgrade.  Using 3rd party and openvpn client.

                                          1 Reply Last reply Reply Quote 0
                                          • B
                                            badserver
                                            last edited by

                                            Alright, I finally got the time to downgrade to 2.0.2 and I'm having the same results. I'll download 2.0.1 and downgrade even further tomorrow, but right now it's not looking good.

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