Route ALL Traffic Through an OpenVPN Tunnel

This particular topic is what drove me to put all of this together in the first place. I had to compile information from 3 separate web pages to get traffic routing with internet connectivity working through the VPN tunnel.

First, edit your server.conf file for OpenVPN and modify the following lines as shown:

vim /etc/openvpn/server.conf
#ROUTE ALL TRAFFIC THROUGH TUNNEL
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.20.1"   #MODIFY THIS LINE!

You need to replace the “192.168.20.1” address above with the IP address of a DNS server in your network that the OpenVPN server can communicate with. IF you don’t know one, and you know your OpenVPN server has internet access, you can use Google’s DNS server if you want at 8.8.8.8

Then:

service openvpn restart

Your OpenVPN service is configured but your server is not. You need to do several more things…
First you need to modify your system modules file…

vim /etc/modules

add the following two lines to the bottom of your modules file exactly as you see them here:

ip_tables
ipt_MASQUERADE

Save and close your modules file. We still have more to do :)… Next you need to modify your sysctl.conf file.

vim /etc/sysctl.conf

Uncomment (remove the “#” from in front of…) the following line:

net.ipv4.ip_forward=1

Save and close that file. net.ipv4.ip_forward should = 1. If it is set to “0” make sure you set it to “1” before saving/closing that file. Almost there…

Reboot your server and when it comes back up, log in and elevate your privileges again:

shutdown now -r
...rebooting....
...then you login...
sudo -s

The modules should be active now. So now we need to so set a routing rule with iptables. Run these two commands:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -L

The first command sets the rule, the second command should output the following (note you should see the rule at the bottom):

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere       #SEE HERE! THIS RULE SHOULD BE HERE!

Assuming the rule exists on your box as shown above. You need to run the next following command:

iptables-save > /etc/network/iptables.conf

IPTables rules are cleared everytime your server is restarted. The above command outputs all current rules into a file. We are now going to do one last thing. We are going to tell our NIC config file to load this IPTables rules file everytime it brings our NIC interface up. So modify your interfaces file…

vim /etc/network/interfaces

add the following line verbatim to the bottom of your interfaces file:

post-up iptables-restore < /etc/network/iptables.conf

Close and save your interfaces file.
and restart the whole box again for good measure.

shutdown now -r

ALL DONE! Finally, lets test… I am assuming your client computer in a totally different network from your OpenVPN server. If not this test won’t be of much help. On your client computer, make sure your VPN is disconnected and visit www.ipchicken.com. Note the public IP address that it shows you as coming from.

Now connect to your VPN connection on the client computer. Once you have successfully connected, refresh the IPchicken website page. The Public IP address should change. It should show the Public IP address that your OpenVPN server is sitting behind. This means that your internet traffic is successfully being routed through your OpenVPN server.

I hope this tutorial/guide has been a huge help to you! Feel free to post questions in the comments section!

11 comments on: OpenVPN – Microsoft Active Directory Authentication – Force All Traffic Through VPN Tunnel

  1. Shane
    Reply

    Just an FYI, one of the commands after the second to last reboot prevents any connection to the Linux server

    • nbeam
      Reply

      That’s interesting, do you know which command or configuration item is killing the connection? I am wondering if I fat-fingered something somewhere in the write-up. It has been a while since I worked on this. I know when I was testing that VPN connectivity still worked and that the final result was “no split-tunneling” i.e. proxy client machines had all traffic forced through the VPN tunnel. What I am not sure is if I somehow broke SSH connectivity but didn’t realize it because I was working on the machine directly (i.e. not remotely via SSH).

      If you can shed some light on this so I can fix the write-up that would be awesome. Hate to have anyone breaking things on there end 🙂

      Thanks for the heads up!

      • Shane

        Yeah so basically for some reason, doesn’t make sense to me, adding that entry into the iptables and setting the file to load upon restart locks out any connection in, the system i implemented this in is in azure so remote access is the only option, it’s most probably a requirement to add an accept for SSH?

        adding the entry without setting the file to load upon restart doesn’t cause any issues (as far as i can tell haven’t checked thoroughly enough)

  2. Anton Bach
    Reply

    great post, really love it!
    greets, Wilfried

  3. Joe
    Reply

    I did it but start openvpn is failed .
    openvpn-auth-ldap plugin is 2.03 and download using “yum instal openvpn_auth-ldap.x86_84” on Centos 6

  4. RAF
    Reply

    Thanks for this guide. I suggest copy and past attributes from AD directly into “/etc/openvpn/auth/auth-ldap.conf” . This was my issue. Good luck

  5. Adam
    Reply

    This saved me a ton of time. Thanks for taking the time to post it.

  6. RAF
    Reply

    Just wonder is there a way to secure client certificate from being compromised and used from another PC ?

  7. coolthecold
    Reply

    cp server.crt server.key ca.crt dh1024.pem ta.key /etc/openvpn/

    here should dh1024 should be changed to dh2048 i believe

  8. dataCore
    Reply

    Great article! Helped me a lot! Little supplement: Add the following to your server.config:
    push “dhcp-option DOMAIN fqdn.yourADDomain.com”
    Otherwise a had to use the fullname e.g. servername.fqdn.mydomain.ch to contact my internal infrastructur.

    • nbeam
      Reply

      Thanks! Appreciate the tip as well 🙂 – Sure it will help others. OpenVPN Community Edition is honestly a bit of a bear. I finally gave up and just moved to the paid version (which is relatively cheap vs. other similar solutions) which is like a completely different product from an administrative perspective. The thing I really needed was two-factor authentication and the community edition (at the time) was very hard to get setup with this.

Leave a Reply to coolthecold Cancel reply

Your email address will not be published. Required fields are marked *