• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Apr 27, 2013, 12:48 PM

    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 Apr 27, 2013, 1:09 PM

      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 Apr 29, 2013, 1:51 PM

        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 Apr 29, 2013, 5:26 PM

          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 Apr 29, 2013, 6:19 PM

            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 Apr 29, 2013, 6:56 PM

              • 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 Apr 29, 2013, 7:08 PM

                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 Apr 30, 2013, 5:33 AM

                  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 Apr 30, 2013, 11:45 AM

                    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 Apr 30, 2013, 6:37 PM

                      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 May 2, 2013, 2:01 PM

                        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 Jun 14, 2013, 11:44 AM

                          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 Jun 14, 2013, 7:04 PM

                            @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 Jun 17, 2013, 8:58 AM

                              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 Jun 17, 2013, 12:16 PM

                                @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 Jun 17, 2013, 1:36 PM

                                  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 Jun 19, 2013, 12:36 PM

                                    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 Jun 20, 2013, 11:45 AM

                                      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 Jun 21, 2013, 4:26 PM

                                        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 Jun 27, 2013, 6:54 PM

                                          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.
                                            This community forum collects and processes your personal information.
                                            consent.not_received