OpenWrt Forum Archive

Topic: tunnel all LAN internet traffic through OpenVPN via WWAN

The content of this topic has been archived on 31 Dec 2017. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi there,

I recently managed to set up OpenWRT with OpenVPN to act as a gateway and send all Internet-bound traffic on my LAN through tun0 (which itself goes over wwan), so all my traffic pops out at my remote OpenVPN server.

I'm going to post what I did here in preparation for posting it on the wiki and/or community documentation. I would like people to comment on it, and I have a question too: how can I alter this so traffic is NOT forwarded when tun0 is down? I don't ever want Internet traffic from LAN to go over WWAN, only tun0.

* * *

Wifi Routed Client Mode

You can set OpenWRT up to connect to a wifi network and bridge traffic from the LAN to the wifi network (WWAN) and then to the Internet via the WWAN gateway. OpenWRT can do all this while providing NAT from LAN to WWAN, and DHCP and DNS for the LAN.

Fortunately, this mostly Just Works.

This step is best done right after a fresh flash of the device.

1. Go to Network > Wifi in Luci.
2. Click the Scan button.
3. Click Join Network for the network you wish to join.
4. Enter the passphrase if applicable. Leave the network name as 'wwan'. Make sure the radio button for 'wan' is selected under Create / Assign firewall-zone. Click Submit.
5. The router will associate with the network. After it joins the network, scroll down to Interface Configuration and ensure that Mode is set to 'Client' and Network has only 'wwan' checked. Click Save & Apply.

The router should now act as a bridge to the given wifi network. If you have not touched DHCP / DNS (dnsmasq) settings, the router should give out DHCP leases on the LAN with itself as gateway and DNS server. Traffic from LAN hosts will be forwarded through the bridge to the Internet via the WWAN's gateway.

The router uses NAT from the LAN to WWAN, so if the WWAN gateway uses NAT as most home broadband does, the LAN will be double-NATed.

Tunnel LAN traffic through OpenVPN gateway

This guide uses OpenWRT's UCI configuration utility instead of editing config files. This can save space on the overlay filesystem, important for 4MB devices. You can use the commands athttps://wiki.openwrt.org/doc/uci including uci set - uci show - uci commit

Configuration and starting OpenVPN

First, copy your .ovpn config file to the /etc/openvpn/ on the router:

scp your_vpn_conf.ovpn root@openwrt:/etc/openvpn/

SSH into the router as root, and then execute the following commands:

   uci set openvpn.vpnname='openvpn'
   uci set openvpn.vpnname.enabled='1'
   uci set openvpn.vpnname.config='/etc/openvpn/your_vpn_conf.ovpn'
   uci commit
   /etc/init.d/openvpn stop # if needed
   /etc/init.d/openvpn start

Then, check /var/log/syslog to see if your configuration worked or not. I've had a .ovpn file Just Work when created from openvpn-addclient OpenVPN 2.3.4 and used OpenWRT 15.x Chaos Calmer, so if you are using a handmade .ovpn or something, take that as an indication that something is wrong with your config.

Configuring the network

OpenVPN, when working, will create a tun0 device that can be seen with ifconfig - once you get to that point, you need to tell OpenWRT to route all Internet traffic from LAN through the tunnel.

Interface
Network > Interfaces > Create new interface

- Name: tun0
- Protocol: DHCP client
- Masquerading: checked
- MSS clamping: checked
- Cover interfaces: tun0
- Allow forward, destination: check 'lan'
- Allow forward, source: check 'lan'

Click Save and apply. Reboot here. Note that it may take a minute or two after boot for the tunnel and forwarding to come up. You can watch Status > System Log in Luci. After 

netifd stops spewing "sending discover..." in the log, your tunnel and forwarding through it from LAN should work.

So, try to connect and traceroute to hosts from a machine on the LAN to ensure the tunnel is in use and working. If you have DNS problems, read on.

DNS

Your OpenVPN server should provide good DNS servers when it configures the client via DHCP. There is a potential gotcha: DNS servers set by the DHCP on 

wwan _before_ the tunnel is up can persist after the tunnel is brought up, and may not be usable from your OpenVPN server, thus causing DNS errors.

If the provider of your OpenVPN server offers DNS, you may want to use it. Using some public nameservers can mess with Anycast, connecting you to sub-optimal content servers which can cause lag and buffering on e.g. Youtube, Netflix.

In Luci, add _your OpenVPN server provider's_ DNS servers to Network > DHCP and DNS > DNS Forwardings, then click Save and Apply. Name resolution should now work when the tunnel is up.

If your service provider does not offer DNS, Google's public DNS servers do use Anycast and are likely to be geographically close to your OpenVPN server: 

8.8.8.8 and 8.8.4.4 - Google public DNS does support DNSSEC.

Other config necessary

In Luci, Network > DHCP and DNS > Advanced, ensure "filter useless" is checked.

In Network > Interfaces > wwan > Advanced, ensure "Use DNS servers advertised by peer" is NOT checked.

You may wish to reboot the router after these changes are saved.

I would like to suggest 2 adjustments to the above.

During the network scan above, after step 3, one must unselect the "Replace Wireless Config " checkbox if there is a wireless LAN or the LAN connection will be lost (replaced with the STAtion config).

You refer to a "fresh flash", but never actually indicate to install one of the 3 openvpn packages.

FWIW, only recently have I seen the use of a VPNconfig.opvn file in the /etc/openvpn folder, though I do get the impression this may have been the preferred way in BB or older.  Installing CC one finds a openvpn file (no extension) in the etc/config/ folder with preconfigured examples server and client examples (and "help").  Your approach may work better for clients connecting to services, as one should not have to reformat the file.  Don't really know.

The discussion might have continued from here.