Skip to content
Connects but no throughput
Got a problem with Viscosity or need help? Ask here!
Hi,
I have setup OpenVPN on a pfsense box and have been connecting happily until very recently.
Whenever I connect now the connection establishes and I get assigned an IP but there is no throughput and nothing has changed on the server side.
Attached is my connection log (public IP replaced with 999.999.999.999)
I have been scratching my head with this for a few days and I have (limited) physical access to the server so can investigate that side too.
Is someone able to point me in the right direction with what is going on and how I might be able to fix this.
I have setup OpenVPN on a pfsense box and have been connecting happily until very recently.
Whenever I connect now the connection establishes and I get assigned an IP but there is no throughput and nothing has changed on the server side.
Attached is my connection log (public IP replaced with 999.999.999.999)
Code: Select all
And my routing tables after connection is established
Dec 14 07:49:28: Viscosity Mac 1.6.7 (1364)
Dec 14 07:49:28: Viscosity OpenVPN Engine Started
Dec 14 07:49:28: Running on Mac OS X 10.12.1
Dec 14 07:49:28: ---------
Dec 14 07:49:28: Checking reachability status of connection...
Dec 14 07:49:28: Connection is reachable. Starting connection attempt.
Dec 14 07:49:28: OpenVPN 2.3.13 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Nov 4 2016
Dec 14 07:49:28: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Dec 14 07:49:31: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/connection.O91lgy/ta.key' as a OpenVPN static key file
Dec 14 07:49:31: UDPv4 link local (bound): [undef]
Dec 14 07:49:31: UDPv4 link remote: [AF_INET]999.999.999.999:1194
Dec 14 07:49:32: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Dec 14 07:49:32: [WorkVPN] Peer Connection Initiated with [AF_INET]999.999.999.999:1194
Dec 14 07:49:34: Opening utun (connect(AF_SYS_CONTROL)): Resource busy
Dec 14 07:49:34: Opened utun device utun1
Dec 14 07:49:34: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Dec 14 07:49:34: /sbin/ifconfig utun1 delete
Dec 14 07:49:34: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Dec 14 07:49:34: /sbin/ifconfig utun1 10.8.0.2 10.8.0.2 netmask 255.255.255.0 mtu 1500 up
Dec 14 07:49:34: Initialization Sequence Completed
Dec 14 07:49:34: DNS mode set to: Off
Code: Select all
I am able to ping myself 10.8.0.2 with replies that indicate it is going through the tunnel and back however when I try to ping either of the the server interfaces 10.8.0.1 or 192.168.1.1 I get no responses and thus will not get any responses on the remote network as the gateway is not avalible.Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default living_room UGSc 65 0 en0
10.8/24 10.8.0.2 UGSc 1 3 utun1
10.8.0.2 10.8.0.2 UH 2 8 utun1
127 localhost UCS 0 0 lo0
localhost localhost UH 3 3777 lo0
192.168.1 10.8.0.1 UGSc 0 3 utun1
192.168.20 link#4 UCS 6 0 en0
192.168.20.2 a0:d3:c1:d8:bd:2f UHLWI 0 0 en0 1181
192.168.20.4 84:38:35:3f:88:d6 UHLWI 0 0 en0 1199
192.168.20.5/32 link#4 UCS 0 0 en0
192.168.20.6 c4:54:44:38:dc:7d UHLWIi 1 40 en0 1165
192.168.20.9 e0:ac:cb:7c:9:2e UHLWI 0 0 en0 1184
192.168.20.15 5c:f6:dc:e1:93:a0 UHLWI 0 9 en0 1198
192.168.20.102/32 link#4 UCS 1 0 en0
living_room 64:70:2:aa:9f:97 UHLWIir 63 576 en0 1170
192.168.20.255 ff:ff:ff:ff:ff:ff UHLWbI 0 11 en0
224.0.0/4 link#4 UmCS 2 0 en0
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 8 en0
255.255.255.255/32 link#4 UCS 1 0 en0
broadcasthost ff:ff:ff:ff:ff:ff UHLWbI 0 5 en0
I have been scratching my head with this for a few days and I have (limited) physical access to the server so can investigate that side too.
Is someone able to point me in the right direction with what is going on and how I might be able to fix this.
Hi mappers,
It appears your 10.8/24 route is correctly in place on the client side, so from a client perspective you should be able to access anything in the 10.8.x.x range. Most likely the routing on the server, or firewall rules, have changed and are preventing access. Make sure the NAT rules (if applicable) are still in place, the firewall rules on the server are allowing VPN traffic to flow between the subnets.
Cheers,
James
It appears your 10.8/24 route is correctly in place on the client side, so from a client perspective you should be able to access anything in the 10.8.x.x range. Most likely the routing on the server, or firewall rules, have changed and are preventing access. Make sure the NAT rules (if applicable) are still in place, the firewall rules on the server are allowing VPN traffic to flow between the subnets.
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
2 posts
Page 1 of 1