Routing all the traffic through the OpenVPN tunnel

Hello,

Last week I decided to setup a second wireless router as a dedicated VPN router, so I could connect all my devices requiring VPN access to the second router. I bought a Torguard subscription and bought a used Buffalo WBMR-HP-G300H from ebay for dirt price.

For the sake of simplicity, let us assume router A to be the one that's connected to the internet through ADSL and router B (Buffalo) is the one where I would like to setup VPN.

I installed the 17.01.4 LEDE on router B and configured the lan interface as a static IP addresses assigning 192.168.1.100 to it. The gateway is set to 192.168.1.1 which is the IP address of router A. The DHCP is disabled on router B with DNS server set to 8.8.8.8. Completed the wireless setup on B, and I could connect to the internet through it.

Followed the documentation here: https://openwrt.org/docs/guide-user/services/vpn/openvpn.torguard and configured the OpenVPN client on router B.

The OpenVPN connection is established and works without a glitch, following are the logs for the same:

Sat Jul 14 11:53:05 2018 VERIFY OK: depth=1, C=US, ST=FL, L=Orlando, O=TorGuard, OU=VPN, CN=TG-OVPN-CA, name=TorGuard, emailAddress=sysadmin@torguard.net
Sat Jul 14 11:53:05 2018 VERIFY OK: nsCertType=SERVER
Sat Jul 14 11:53:05 2018 VERIFY OK: depth=0, C=US, ST=FL, L=Orlando, O=TorGuard, OU=VPN, CN=TG-OVPN-CA, name=TorGuard, emailAddress=sysadmin@torguard.net
Sat Jul 14 11:53:05 2018 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1560', remote='link-mtu 1544'
Sat Jul 14 11:53:05 2018 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Sat Jul 14 11:53:05 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat Jul 14 11:53:05 2018 [TG-OVPN-CA] Peer Connection Initiated with [AF_INET]82.103.138.208:443


Sat Jul 14 11:53:06 2018 SENT CONTROL [TG-OVPN-CA]: 'PUSH_REQUEST' (status=1)
Sat Jul 14 11:53:06 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.9.0.1,dhcp-option DNS 10.8.0.1,route 10.8.0.1,topology net30,ping 5,ping-restart 30,socket-flags TCP_NODELAY,ifconfig 10.8.0.18 10.8.0.17,peer-id 0,cipher AES-128-GCM'
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: --socket-flags option modified
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: route options modified
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: peer-id set
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: adjusting link_mtu to 1627
Sat Jul 14 11:53:06 2018 OPTIONS IMPORT: data channel crypto options modified
Sat Jul 14 11:53:06 2018 Data Channel: using negotiated cipher 'AES-128-GCM'
Sat Jul 14 11:53:06 2018 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sat Jul 14 11:53:06 2018 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sat Jul 14 11:53:06 2018 TUN/TAP device tun0 opened
Sat Jul 14 11:53:06 2018 TUN/TAP TX queue length set to 100
Sat Jul 14 11:53:06 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Jul 14 11:53:06 2018 /sbin/ifconfig tun0 10.8.0.18 pointopoint 10.8.0.17 mtu 1500
Sat Jul 14 11:53:06 2018 /sbin/route add -net 82.103.138.208 netmask 255.255.255.255 gw 192.168.1.1
Sat Jul 14 11:53:06 2018 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.17
Sat Jul 14 11:53:06 2018 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.17
Sat Jul 14 11:53:06 2018 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.17
Sat Jul 14 11:53:06 2018 Initialization Sequence Completed

But when I fetch my public IP (when connected to B over Wifi), I see the IP address assigned by my local ISP and not the IP address of VPN service.

Following are my router configuration:

root@LEDE:~# cat /etc/config/network

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd06:e469:a983::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'

config dsl 'dsl'
	option annex 'a'
	option firmware '/lib/firmware/adsl.bin'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option dns '8.8.8.8'
	option ipaddr '192.168.1.100'
	option gateway '192.168.1.1'

config interface 'wan'
	option ifname 'nas0'
	option proto 'pppoe'
	option username 'username'
	option password 'password'
	option ipv6 '1'

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config interface 'myvpnc'
	option proto 'none'
	option type 'bridge'
	option auto '1'
	option _orig_ifname 'tun0'
	option _orig_bridge 'true'
	option ifname 'tun0'
root@LEDE:~# cat /etc/config/firewall

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

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

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

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

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

config zone
	option name 'myvpnc_fw'
	option network 'myvpnc'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'myvpnc_fw'

This is how the traceroute looks like:

traceroute to lede-project.org (139.59.209.225), 30 hops max, 38 byte packets
 1  192.168.1.1  0.381 ms
 2  62.52.201.190  47.622 ms
 3  62.53.22.210  19.804 ms
 4  62.53.16.31  23.038 ms
 5  62.53.0.20  23.198 ms
 6  62.53.26.2  23.548 ms
 7  62.53.2.59  23.381 ms
 8  80.81.195.151  23.698 ms
 9  *
10  139.59.209.225  23.440 ms

What am I doing wrong here? I would really appreciate some help here.

I don't have the time at the moment to figure out what the issue is, however there are a few other things that stood out:

   WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
  • OpenVPN client and server config options must mirror each other for 99% of the config options
    • Ciphers between client interface and server config do not match (server is using BF-CBC [BlowFish] and client is utilizing AES-128-CBC)

PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.9.0.1,dhcp-option DNS 10.8.0.1,route 10.8.0.1,topology net30,ping 5,ping-restart 30,socket-flags TCP_NODELAY,ifconfig 10.8.0.18 10.8.0.17,peer-id 0,cipher AES-128-GCM'
  • Net30 was depreciated years ago... topology subnet is what's superseded it.
    • If this is what TorGuard is configuring clients with, I'd inquire as to why they're using obsolete config settings... between Net30 and BlowFish, that's circa 2010 and prior.

Thanks for the help and reply, ill try changing my Cipher to match the one at the server. But isn't this just a warning? The VPN client is able to initiate a connection with the server, the problem; is traffic is not being routed through it.

Ok, so I figured it out. By setting the gateway on the wireless client to 192.168.1.100 (IP address of router B) I was able to route the traffic on the wireless client through the VPN. How can I change this on OpenWRt directly, so that I don't have to modify the network on wireless clients?

No. If client is using AES-128-GCM as a cipher and the server is using BF-CBC as a cipher, neither the client or server is going to be able to de-crypt each other's data. It would be akin to the server speaking English and the client Spanish.

  • Without knowing the output of the server's config, it's likely traffic wasn't being encrypted, however I'd have to test that hypothesis.