OpenVPN client - connected but has no IP or traffic

DVS · January 12, 2018, 9:59am

Hello all,

I have been trying to figure this one out for days now and as my VPN provider hasn't been much help yet I hope someone here has a suggestion.

I am hoping to use my Linksys WRT1900ACS as a openvpn client to route most of my lan traffic through a VPN and after going through my settings several times I think the problem must be either with my tun0 interface or the OpenVPN connection. The OpenVPN service seems to start successfully and I can't see any issues in the log below:

Fri Jan 12 09:46:57 2018 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Jan 12 09:46:57 2018 library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Fri Jan 12 09:46:57 2018 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Jan 12 09:46:57 2018 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Jan 12 09:46:57 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]88.202.180.121:53
Fri Jan 12 09:46:57 2018 Socket Buffers: R=[163840->163840] S=[163840->163840]
**Fri Jan 12 09:46:57 2018 UDP link local: (not bound)**
Fri Jan 12 09:46:57 2018 UDP link remote: [AF_INET]88.202.180.121:53
Fri Jan 12 09:46:58 2018 TLS: Initial packet from [AF_INET]88.202.180.121:53, sid=099fcbf6 03a7f9f3
Fri Jan 12 09:46:58 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 12 09:46:58 2018 VERIFY OK: depth=1, C=RO, ST=BUC, O=VPN.AC, OU=VPN.AC CA, CN=VPN.AC, emailAddress=info@vpn.ac
Fri Jan 12 09:46:58 2018 VERIFY KU OK
Fri Jan 12 09:46:58 2018 Validating certificate extended key usage
Fri Jan 12 09:46:58 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jan 12 09:46:58 2018 VERIFY EKU OK
Fri Jan 12 09:46:58 2018 VERIFY OK: depth=0, CN=uk1-4096
Fri Jan 12 09:46:58 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Fri Jan 12 09:46:58 2018 [uk1-4096] Peer Connection Initiated with [AF_INET]88.202.180.121:53
Fri Jan 12 09:46:59 2018 SENT CONTROL [uk1-4096]: 'PUSH_REQUEST' (status=1)
**Fri Jan 12 09:46:59 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.10.100.1,sndbuf 524288,rcvbuf 524288,route 10.10.127.1,topology net30,ping 20,ping-restart 90,ifconfig 10.10.127.14 10.10.127.13,peer-id 2,cipher AES-128-GCM'**
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Fri Jan 12 09:46:59 2018 Socket Buffers: R=[163840->327680] S=[163840->327680]
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: route options modified
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: peer-id set
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Jan 12 09:46:59 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Jan 12 09:46:59 2018 Data Channel: using negotiated cipher 'AES-128-GCM'
Fri Jan 12 09:46:59 2018 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Fri Jan 12 09:46:59 2018 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Fri Jan 12 09:46:59 2018 TUN/TAP device tun0 opened
Fri Jan 12 09:46:59 2018 TUN/TAP TX queue length set to 100
Fri Jan 12 09:46:59 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
**Fri Jan 12 09:46:59 2018 /sbin/ifconfig tun0 10.10.127.14 pointopoint 10.10.127.13 mtu 1500**
Fri Jan 12 09:47:02 2018 Initialization Sequence Completed

The only parts I am not sure about are what I made bold, which could be the cause. For example I don't know where it is getting the 10.10.x.x address from as my network is on a 10.1.1.x range.

The tun0 interface also looks like this:

config interface 'VPN_WAN'
	option ifname 'tun0'
	option _orig_ifname 'tun0'
	option _orig_bridge 'false'
	option proto 'none'
	option auto '1'
	option delegate '0'

And OpenVPN config like this:

config openvpn 'VPNAC'
	option dev 'tun'
	option nobind '1'
	option verb '3'
	option comp_lzo 'yes'
	option tls_auth '/etc/openvpn/tlsauth.key'
	option auth 'SHA256'
	option cipher 'AES-128-CBC'
	option client '1'
	option remote_random '1'
	option tls_exit '1'
	option persist_tun '1'
	option persist_key '1'
	option port '53'
	option dev_type 'tun'
	option auth_user_pass '/etc/openvpn/userpass.txt'
	list remote 'uk1.vpn.ac'
	list remote 'uk1A.vpn.ac'
	list remote 'uk2.vpn.ac'
	list remote 'uk2A.vpn.ac'
	option tls_client '1'
	option mute_replay_warnings '1'
	option key_direction '1'
	option ca '/etc/luci-uploads/cbid.openvpn.VPNAC.ca'
	option redirect_gateway 'def1'
	option route_delay '3'
	option enabled '1'
	option remote_cert_tls 'server'
	option log '/var/log/openvpn.log'
	option log_append '/var/log/openvpn.log'
	option route_noexec '1'

If anyone has any ideas or if you need more information then please let me know.
Thank you.

whyza · January 14, 2018, 6:55am

I have been trying to figure this out for weeks.....it has to be an encryption issue ??

Setup via LUCI

connects fine

Sun Jan 14 16:27:54 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: You have disabled Replay Protection (--no-replay) which may make OpenVPN less secure
Sun Jan 14 16:27:54 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: TCP/UDP: Preserving recently used remote address: [AF_INET]169.50.128.202:1195
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: UDP link local: (not bound)
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: UDP link remote: [AF_INET]169.50.128.202:1195
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: TLS: Initial packet from [AF_INET]169.50.128.202:1195, sid=e8394cb0 9c6b9882
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: VERIFY OK: depth=1, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=ExpressVPN CA, emailAddress=support@expressvpn.com
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: VERIFY KU OK
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: Validating certificate extended key usage
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: VERIFY EKU OK
Sun Jan 14 16:27:54 2018 daemon.notice openvpn(expressvpn)[32052]: VERIFY OK: depth=0, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=Server-1562-1a, emailAddress=support@expressvpn.com
Sun Jan 14 16:27:55 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1398', remote='link-mtu 1606'
Sun Jan 14 16:27:55 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1300', remote='tun-mtu 1500'
Sun Jan 14 16:27:55 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: 'no-replay' is present in local config but missing in remote config, local='no-replay'
Sun Jan 14 16:27:55 2018 daemon.warn openvpn(expressvpn)[32052]: WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Sun Jan 14 16:27:55 2018 daemon.notice openvpn(expressvpn)[32052]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun Jan 14 16:27:55 2018 daemon.notice openvpn(expressvpn)[32052]: [Server-1562-1a] Peer Connection Initiated with [AF_INET]169.50.128.202:1195
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: SENT CONTROL [Server-1562-1a]: 'PUSH_REQUEST' (status=1)
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.81.0.1,route 10.81.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.81.1.242 10.81.1.241'
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: OPTIONS IMPORT: timers and/or timeouts modified
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: OPTIONS IMPORT: --ifconfig/up options modified
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: OPTIONS IMPORT: route options modified
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Preserving previous TUN/TAP instance: tun0
Sun Jan 14 16:27:56 2018 daemon.notice openvpn(expressvpn)[32052]: Initialization Sequence Completed

whyza · January 14, 2018, 6:56am

tcpdump shows packets going out over the tunnel but nothing coming back, nor on UDP 1195

It has to be an encryption issue ?

anyone else use expressvpn ?

stangri · January 14, 2018, 11:12am

Did you configure firewall zone and forwardings for the VPN Client?

Do you successfully pull the routing from the VPN Server (check with route in CLI)?

DVS · January 14, 2018, 11:32am

I see @whyza has pretty much the same issue as me then, I am talking with my VPN provider at the moment though they haven't been able to help just from me sending them config files and logs. They are next wanting to Teamviewer on to the LAN to have a look, so can let u know what they find on here.

Also thank you @stangri, I configured the zone forwarding correctly I believe the trouble is if I direct LAN traffic to the VPN interface then I lose my WAN connection. It should go LAN > VPN > WAN I believe?
Hmm I haven't tried pulling the routing information though...not sure how, but shall look it up and try

whyza · January 14, 2018, 11:52am

yep, zones are configured correctly

I see this on wan interface

root@LEDE:~# tcpdump -n -i eth0 port 1195
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:39:47.385896 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:48.385995 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:49.386074 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:50.386167 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:51.386310 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:52.386367 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:53.737018 IP 169.50.128.202.1195 > 192.168.0.6.33398: UDP, length 113
21:39:58.390217 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 86
21:39:58.690783 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 98
21:39:58.691565 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:58.692124 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 250
21:39:58.998419 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 1128
21:39:58.998589 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 1116
21:39:58.998592 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 346
21:39:58.999042 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:59.007241 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:59.303278 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 1128
21:39:59.303919 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 511
21:39:59.604711 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 94
21:39:59.608992 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 149
21:39:59.609825 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 581
21:39:59.916449 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 365
21:39:59.919780 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:40:00.387422 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 128
21:40:00.687775 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 94
21:40:00.687778 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 262
21:40:00.691599 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:40:01.387392 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:02.387413 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:03.387504 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:04.387586 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:05.387672 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:06.387777 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:07.387852 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:08.387991 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:09.388078 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:10.388177 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:10.689114 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 113
21:40:11.388276 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:12.388379 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:13.388479 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177

but no response to the pings inside tun0

21:23:04.937377 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id 37392, seq 819, length 64
21:23:05.938077 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id 37392, seq 820, length 64
21:23:06.938428 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id 37392, seq 821, length 64
21:23:07.939179 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id 37392, seq 822, length 64

full report

root@LEDE:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.81.1.241     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth0
10.81.0.1       10.81.1.241     255.255.255.255 UGH   0      0        0 tun0
10.81.1.241     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.81.1.241     128.0.0.0       UG    0      0        0 tun0
169.50.128.202  192.168.0.254   255.255.255.255 UGH   0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.38.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

.

root@LEDE:~# ifconfig
eth0      Link encap:Ethernet  HWaddr B8:27:EB:29:03:0C
          inet addr:192.168.0.6  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:fe29:30c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10372 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10814 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1222814 (1.1 MiB)  TX bytes:3159396 (3.0 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:256 errors:0 dropped:0 overruns:0 frame:0
          TX packets:256 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:49111 (47.9 KiB)  TX bytes:49111 (47.9 KiB)

tun0      Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.81.1.242  P-t-P:10.81.1.241  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1804 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:151089 (147.5 KiB)

wlan0     Link encap:Ethernet  HWaddr B8:27:EB:7C:56:59
          inet addr:192.168.38.1  Bcast:192.168.38.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:fe7c:5659/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1352 (1.3 KiB)

.

root@LEDE:~# tcpdump -n -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
21:39:16.382038 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id
37392, seq 1790, length 64
21:39:17.382379 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id
37392, seq 1791, length 64
21:39:18.382715 IP 10.81.1.242 > 172.217.25.142: ICMP echo request, id
37392, seq 1792, length 64

.

root@LEDE:~# tcpdump -n -i eth0 port 1195
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:39:47.385896 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:48.385995 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:49.386074 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:50.386167 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:51.386310 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:52.386367 IP 192.168.0.6.33398 > 169.50.128.202.1195: UDP, length 177
21:39:53.737018 IP 169.50.128.202.1195 > 192.168.0.6.33398: UDP, length 113
21:39:58.390217 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 86
21:39:58.690783 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 98
21:39:58.691565 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:58.692124 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 250
21:39:58.998419 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 1128
21:39:58.998589 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 1116
21:39:58.998592 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 346
21:39:58.999042 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:59.007241 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:39:59.303278 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 1128
21:39:59.303919 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 511
21:39:59.604711 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 94
21:39:59.608992 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 149
21:39:59.609825 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 581
21:39:59.916449 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 365
21:39:59.919780 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:40:00.387422 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 128
21:40:00.687775 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 94
21:40:00.687778 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 262
21:40:00.691599 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 94
21:40:01.387392 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:02.387413 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:03.387504 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:04.387586 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:05.387672 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:06.387777 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:07.387852 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:08.387991 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:09.388078 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:10.388177 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:10.689114 IP 169.50.128.202.1195 > 192.168.0.6.41596: UDP, length 113
21:40:11.388276 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:12.388379 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:13.388479 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:14.388561 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:15.388643 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177
21:40:16.389079 IP 192.168.0.6.41596 > 169.50.128.202.1195: UDP, length 177



root@LEDE:~# openvpn --version
OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL]
[MH/PKTINFO] [AEAD]
library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. 


root@LEDE:~# cat /var/etc/openvpn-expressvpn.conf
auth-nocache
client
fast-io
nobind
no-replay
persist-key
persist-tun
pull
tls-client
auth SHA512
auth-user-pass /etc/openvpn/userpass.txt
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
cipher AES-256-CBC
comp-lzo yes
dev tun
dh dh1024.pem
key /etc/openvpn/client.key
key-direction 1
keysize 256
port 1195
proto udp
rcvbuf 524288
remote netherlands-amsterdam-2-ca-version-2.expressnetw.com
remote-cert-tls server
reneg-sec 0
sndbuf 524288
tls-auth /etc/openvpn/tlsauth.key
tun-mtu 1500
verb 3

LOGS

Sun Jan 14 20:48:00 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
Ignoring option 'dh' in tls-client mode, please only include this in your
server configuration
Sun Jan 14 20:48:00 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
--keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sun Jan 14 20:48:00 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
--no-replay is DEPRECATED and will be removed in OpenVPN 2.5
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: OpenVPN
2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL]
[MH/PKTINFO] [AEAD]
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: library
versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Sun Jan 14 20:48:00 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
You have disabled Replay Protection (--no-replay) which may make OpenVPN
less secure
Sun Jan 14 20:48:00 2018 daemon.inf logread[238]: failed to send log data
to 192.168.0.11:514 via udp
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: Outgoing
Control Channel Authentication: Using 512 bit message hash 'SHA512' for
HMAC authentication
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: Incoming
Control Channel Authentication: Using 512 bit message hash 'SHA512' for
HMAC authentication
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: TCP/UDP:
Preserving recently used remote address: [AF_INET]169.50.128.202:1195
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: Socket
Buffers: R=[163840->327680] S=[163840->327680]
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: UDP link
local: (not bound)
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: UDP link
remote: [AF_INET]169.50.128.202:1195
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: TLS:
Initial packet from [AF_INET]169.50.128.202:1195, sid=b5efa1ec fd95292c
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: VERIFY
OK: depth=1, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=ExpressVPN CA
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: VERIFY
KU OK
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]:
Validating certificate extended key usage
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: ++
Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web
Server Authentication
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: VERIFY
EKU OK
Sun Jan 14 20:48:00 2018 daemon.notice openvpn(expressvpn)[3953]: VERIFY
OK: depth=0, C=VG, ST=BVI, O=ExpressVPN, OU=ExpressVPN, CN=Server-1562-1a,
Sun Jan 14 20:48:01 2018 daemon.info logread[238]: Logread connected to
192.168.0.11:514
Sun Jan 14 20:48:01 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
'link-mtu' is used inconsistently, local='link-mtu 1598', remote='link-mtu
1606'
Sun Jan 14 20:48:01 2018 daemon.inf logread[238]: failed to send log data
to 192.168.0.11:514 via udp
Sun Jan 14 20:48:01 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
'no-replay' is present in local config but missing in remote config,
local='no-replay'
Sun Jan 14 20:48:01 2018 daemon.warn openvpn(expressvpn)[3953]: WARNING:
'mtu-dynamic' is present in remote config but missing in local config,
remote='mtu-dynamic'
Sun Jan 14 20:48:01 2018 daemon.notice openvpn(expressvpn)[3953]: Control
Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit
RSA
Sun Jan 14 20:48:01 2018 daemon.notice openvpn(expressvpn)[3953]:
[Server-1562-1a] Peer Connection Initiated with
[AF_INET]169.50.128.202:1195
Sun Jan 14 20:48:02 2018 daemon.inf logread[238]: Logread connected to
192.168.0.11:514
Sun Jan 14 20:48:02 2018 daemon.notice openvpn(expressvpn)[3953]: SENT
CONTROL [Server-1562-1a]: 'PUSH_REQUEST' (status=1)
Sun Jan 14 20:48:02 2018 daemon.inf logread[238]: failed to send log data
to 192.168.0.11:514 via udp
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: PUSH:
Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option
DNS 10.81.0.1,route 10.81.0.1,topology net30,ping 10,ping-restart
60,ifconfig 10.81.1.242 10.81.1.241'
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: OPTIONS
IMPORT: timers and/or timeouts modified
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: OPTIONS
IMPORT: --ifconfig/up options modified
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: OPTIONS
IMPORT: route options modified
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: OPTIONS
IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: Outgoing
Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: Outgoing
Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: Incoming
Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: Incoming
Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: TUN/TAP
device tun0 opened
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]: TUN/TAP
TX queue length set to 100
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
/sbin/ifconfig tun0 10.81.1.242 pointopoint 10.81.1.241 mtu 1500
Sun Jan 14 20:48:03 2018 daemon.notice netifd: Interface 'expressvpn' is
enabled
Sun Jan 14 20:48:03 2018 daemon.notice netifd: Network device 'tun0' link
is up
Sun Jan 14 20:48:03 2018 daemon.notice netifd: Interface 'expressvpn' has
link connectivity
Sun Jan 14 20:48:03 2018 daemon.notice netifd: Interface 'expressvpn' is
setting up now
Sun Jan 14 20:48:03 2018 daemon.notice netifd: Interface 'expressvpn' is
now up
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
/sbin/route add -net 169.50.128.202 netmask 255.255.255.255 gw
192.168.0.254
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.81.1.241
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.81.1.241
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
/sbin/route add -net 10.81.0.1 netmask 255.255.255.255 gw 10.81.1.241
Sun Jan 14 20:48:03 2018 daemon.notice openvpn(expressvpn)[3953]:
Initialization Sequence Completed
Sun Jan 14 20:48:03 2018 user.notice firewall: Reloading firewall due to
ifup of expressvpn (tun0)

whyza · January 14, 2018, 11:58am

it is worth noting the same config works on a ubuntu box for me

DVS · January 14, 2018, 12:55pm

Also ip route looks like this for me:

root@DVS-OWRT:~# ip route
default via 172.16.10.30 dev pppoe-wan proto static 
10.1.1.0/24 dev br-lan proto kernel scope link src 10.1.1.10 
10.10.127.9 dev tun0 proto kernel scope link src 10.10.127.10 
172.16.10.30 dev pppoe-wan proto kernel scope link src xx.x.xxx.xx

I do wonder if those 10.10. addresses are coming from though as they are LAN but not part of the subnet I use it would seem.

whyza · January 14, 2018, 8:56pm

Your routing looks wrong.

the 10.10 addresses are the 2 IP's for each end of VPN tunnel, over tun0

your default route should be over the VPN/Tun0 once established

here is mine in the same format

root@LEDE:~# ip route
0.0.0.0/1 via 10.81.1.241 dev tun0 
default via 192.168.0.254 dev eth0 
10.81.0.1 via 10.81.1.241 dev tun0 
10.81.1.241 dev tun0  src 10.81.1.242 
128.0.0.0/1 via 10.81.1.241 dev tun0 
169.50.128.202 via 192.168.0.254 dev eth0 
192.168.0.0/24 dev eth0  src 192.168.0.6 
192.168.38.0/24 dev wlan0  src 192.168.38.1

expressvpn support are no use

This has to be an Bug with LEDE

What further diagnostics can I provide to assist in getting some direction ?
Further debug logging ?

Encryption works....

root@LEDE:/tmp#     openvpn --genkey --secret key --cipher AES-256-CBC
root@LEDE:/tmp#     openvpn --test-crypto --cipher AES-256-CBC --secret key
Mon Jan 15 07:07:13 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Mon Jan 15 07:07:13 2018 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Jan 15 07:07:13 2018 library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Mon Jan 15 07:07:13 2018 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Jan 15 07:07:13 2018 Entering OpenVPN crypto self-test mode.
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=1
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=2
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=3
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=4
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=5
Mon Jan 15 07:07:13 2018 TESTING ENCRYPT/DECRYPT of packet length=6
<snip>
Mon Jan 15 07:07:14 2018 TESTING ENCRYPT/DECRYPT of packet length=1498
Mon Jan 15 07:07:14 2018 TESTING ENCRYPT/DECRYPT of packet length=1499
Mon Jan 15 07:07:14 2018 TESTING ENCRYPT/DECRYPT of packet length=1500
Mon Jan 15 07:07:14 2018 OpenVPN crypto self-test mode SUCCEEDED.

root@LEDE:~# opkg list-upgradable
root@LEDE:~#

DVS · January 15, 2018, 9:45am

Heh I think you are better at diagnostics than me, so I can't suggest much there.
I should mention that currently I don't have any forwarding set up to point to the VPN since if I do I will lose WAN access...although I didn't try ip route when it was set up that way.

I have a teamviewer session scheduled tonight with my VPN provider so hopefully they will see what is wrong and might be able to help more after.

jow · January 15, 2018, 9:48am

Please try changing option proto none to option proto static but do not set any IP. The proto none setting will cause netifd to clear all ip addresses once it sees the associated interface.

DVS · January 15, 2018, 10:30am

Hmm apparently running netifd was a mistake via WAN access as I have now lost access to my router . However, I did try as you suggested @jow and change it to static before I did this, and it looked the same as before sadly with no IP address. I do wonder if it's something to do with the OpenVPN service connecting to that interface...or because I have the VPNBypass app enabled.

Or that just restarted the interfaces, as it is back up now. However the tun0/VPN interface still looks like:

stangri · January 15, 2018, 11:43pm

Post /etc/config/firewall.

DVS · January 16, 2018, 9:53am

Thanks to a Teamviewer session with my VPN provider they managed to sort the issue out, though I struggled to keep up with what they were doing. Apparently it was a DNS issue but I haven't figured out what they changed yet. I dont believe they changed the firewall though...so here is the important part of the config:

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option masq '1'
	option mtu_fix '1'
	option output 'ACCEPT'
	option input 'DROP'
	option network 'wan'
	option forward 'DROP'
	option log '1'

config zone
	option output 'ACCEPT'
	option name 'VPNAC_FW'
	option masq '1'
	option mtu_fix '1'
	option network 'VPN_WAN'
	option input 'ACCEPT'
	option forward 'ACCEPT'

config forwarding
	option dest 'wan'
	option src 'lan'

config forwarding
	option dest 'lan'
	option src 'wan'

config forwarding
	option dest 'VPNAC_FW'
	option src 'lan'

I have noticed however that some VPN providers say change input/forward to reject yet it isn't here.