OpenVPN up but no traffic passing
-
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!
-
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' -
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?
-
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.
-
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.
-
-
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>
-
-
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;
-
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!
-
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 openedcan 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>
-
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 -
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) ?
-
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.
-
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. -
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.
-
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 -
Have you done the Outbound NAT Rules ? It sounds to me that you missed that bit.
-
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?
-
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. -
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.
-
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.