Simple way to route all traffic via gateway with OpenVPN

You need VPN when you are connected to unsecured WIFI. Also VPN is needed when this public wifi or your ISP is restricting you. One example of such restrictions is blocking P2P programs and alike.

Good way to overcome those problems is OpenVPN. This can be quite complicated to set up but simple configurations is actually simple.

Firstly is needed server. Server can be your home router or some small server in datacentre that has extra bandwith left over. Your laptop will be called client which sends all(or some) of your traffic through one TCP/IP connection to server and server forwards it so it looks like traffic is originating from server.

Lets have our internal ips 10.66.77.1 for server and 10.66.77.2 for client. Network is selected in the middle of 10.0.0.0/24 network because then it has smaller chance of colliding with your existing network.

Server needs ip forwarding and nat to be enabled. You achieve this with following commands. 10.66.77.0/24 and eth0 needs to be changed to your actual values.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.66.77.0/24 -o eth0 -j MASQUERADE

Next we need static key. Bear in mind that this need to be kept secret. Key generating looks like:

openvpn --genkey --secret static.key
chmod 600 static.key

Now preparation is ready and you can make OpenVPN configuration file. By default OpenVPN uses UDP and port 1194. UDP is not reliable and 1194 can be blocked from where you are trying to connect. Usually open ports from everywhere are 21(ftp), 22(ssh) 80(http) and 443(https) and some more. If you are hosting websites in your server then 80 and 443 are used by webserver and not usable. There is rarely ftp actually used as there is better alternatives like ssh so I chose 21 to be my VPN port.

Server configuration file server.ovpn:

dev tun
proto tcp-server
port 21
ifconfig 10.66.77.1 10.66.77.2
secret static.key

Client configuration file client.ovpn:

remote yourserver.com 21 tcp-client
dev tun
ifconfig 10.66.77.2 10.66.77.1
secret static.key
redirect-gateway def1

“redirect-gateway def1” changes client routing table so that all traffic is directed via server. Without it only traffic sent to servers ip 10.66.77.1 will be sent there. Most materials in web recommend to add to server config push “redirect-gateway def1” but this is not working in some cases so better add this config directly to client.

Now it is almost ready, just need to start up the VPN and enjoy.

Server:

openvpn --config server.ovpn

Client

openvpn --config client.ovpn

Test from client machine

ping 10.66.77.1

If ping is replied then it works. Solution works on linux machines like ubuntu or fedora. For windows configuration is same but starting client is bit different depending on client implementation.

Possible problems:

  • Firewall is blocking port
  • ip forwarding and nat is not set up in server
  • redirect-gateway def1 is missing from cleint conf
  • old openvpn process is hanging in server and thus connection does not complete. Could happen if you started the process from command line and lost connection to the server. In this case kill the old openvpn process before starting new.

On successful connection server will show output like this:

Wed May 9 06:08:11 2018 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Wed May 9 06:08:11 2018 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Wed May 9 06:08:11 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Wed May 9 06:08:11 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Wed May 9 06:08:11 2018 TUN/TAP device tun0 opened
Wed May 9 06:08:11 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 9 06:08:11 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed May 9 06:08:11 2018 /sbin/ip addr add dev tun0 local 10.66.77.1 peer 10.66.77.2
Wed May 9 06:08:11 2018 Listening for incoming TCP connection on [undef]
Wed May 9 06:08:48 2018 TCP connection established with [AF_INET]212.30.199.69:59542
Wed May 9 06:08:48 2018 TCPv4_SERVER link local (bound): [undef]
Wed May 9 06:08:48 2018 TCPv4_SERVER link remote: [AF_INET]212.30.199.69:59542
Wed May 9 06:08:48 2018 Peer Connection Initiated with [AF_INET]212.30.199.69:59542
Wed May 9 06:08:49 2018 Initialization Sequence Completed

And in the client:
Wed May 9 07:08:47 2018 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Wed May 9 07:08:47 2018 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Wed May 9 07:08:47 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Wed May 9 07:08:47 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Wed May 9 07:08:47 2018 TUN/TAP device tun0 opened
Wed May 9 07:08:47 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 9 07:08:47 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed May 9 07:08:47 2018 /sbin/ip addr add dev tun0 local 10.66.77.2 peer 10.66.77.1
Wed May 9 07:08:47 2018 Attempting to establish TCP connection with [AF_INET]78.46.215.33:21 [nonblock]
Wed May 9 07:08:48 2018 TCP connection established with [AF_INET]78.46.215.33:21
Wed May 9 07:08:48 2018 TCPv4_CLIENT link local: [undef]
Wed May 9 07:08:48 2018 TCPv4_CLIENT link remote: [AF_INET]78.46.215.33:21
Wed May 9 07:08:48 2018 Peer Connection Initiated with [AF_INET]78.46.215.33:21
Wed May 9 07:08:49 2018 Initialization Sequence Completed

Definitely make sure that “Initialization Sequence Completed” is shown on both sides, it could happen that the connection finalizing takes a while even though it is usually around one second or so.


9 thoughts on “Simple way to route all traffic via gateway with OpenVPN

  1. It took me FOREVER to find a tutorial that mentioned the fact that:

    redirect-gateway def1

    has problems for some when imposed by the server, but works when stated in the client configuration. I thought that I was doing something wrong!

    Thank you for that gem, you have saved me so much time and effort.

  2. will this help in case public WIFI block RDP connections and other client applications?

  3. Big thanks for the write-up.

    I got my VPN going with a simple static key setup; connection was happening but no routing. The answer is right here in the first set of commands – I just tweaked it a little:

    # iptables -t nat -A POSTROUTING -s single_client_ip/32 -o eth0 -j SNAT –to-source server_static_ip

    On Debian, afterwards, I run ‘iptables-save > iptables.rules’ and load this from a script in /etc/network/if-pre-up.d/

    Numerous hours of head scratching were had until I stumbled upon your page and experienced my epiphany.

Leave a Reply

Your email address will not be published.


*