Home / ubuntu / Questions / 462533
Accepted
Just Lucky Really
Asked: 2014-05-08 12:21:40 +0800 CST

Route all traffic through OpenVPN

  • 772

Yep, this question has been asked a hundred times, and I have searched everywhere, to no avail.

The title says it all really.

I have an OpenVPN server (On ubuntu), and I can connect to it through my client (Windows 8) ...

The problem starts when I try to route ALL traffic through the VPN.

I have added the push flags in server.conf:

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

When I connect from the client, the client outputs:

Wed May 07 21:38:40 2014 SENT CONTROL [StretchVPN-CA]: 'PUSH_REQUEST' (status=1)
Wed May 07 21:38:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route-gateway <Remote Router IP>,ping 10,ping-restart 120,ifconfig 192.168.0.201 255.255.255.0'
Wed May 07 21:38:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route-related options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 07 21:38:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 07 21:38:41 2014 open_tun, tt->ipv6=0
Wed May 07 21:38:41 2014 TAP-WIN32 device [Local Area Connection 4] opened: \\.\Global\{1F145805-92FC-454E-8FD9-0A6017DD4AD1}.tap
Wed May 07 21:38:41 2014 TAP-Windows Driver Version 9.9
Wed May 07 21:38:41 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.201/255.255.255.0 on interface {1F145805-92FC-454E-8FD9-0A6017DD4AD1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Wed May 07 21:38:41 2014 Successful ARP Flush on interface [35] {1F145805-92FC-454E-8FD9-0A6017DD4AD1}
Wed May 07 21:38:46 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD <Remote Router IP> MASK 255.255.255.255 172.20.10.1
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 Initialization Sequence Completed

I have tried using the flags on the client side when opening the connection:

openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn" --redirect-gateway def1 --route-method exe

But still, when I go to whatsmyip.org, it still says my clients ip.

Has anyone had this problem and managed to solve it?

Many thanks

vpn

6 Answers

  1. Best Answer

    I have tested this using a OpenVPN server and setting up the redirect-gateway def1 option in the client and server config works fine.

    When I access whatismyip.org, I see my OpenVPN server's IP.

    Below is the client config I use:

    client
dev tun
proto udp
# THE IP OF THE REMOTE OPENVPN SERVER:
remote ip_address port
resolv-retry infinite
nobind
persist-key
persist-tun
# THE CSR FILE:
pkcs12 certificate.p12
ns-cert-type server
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
verb 3

    I have tested also with appending redirect-gateway def1 option to the openvpn command and achieved same result. The server config is:

    port 1194
proto udp
dev tun

dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
# ENSURE THE DOMAIN NAME/FILENAME IS CORRECT:
cert /etc/openvpn/easy-rsa/keys/cert.crt
key /etc/openvpn/easy-rsa/keys/cert.key

server 10.5.3.0  255.255.255.0
# YOUR LOCAL SERVER IP HERE:
client-config-dir ccd
route 10.5.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun

status log/openvpn-status.log 5
status-version 2
log-append log/openvpn.log
verb 3  # verbose mode
management localhost port /etc/openvpn/management-password

# ROUTE THE CLIENT'S INTERNET ACCESS THROUGH THIS SERVER:
push "redirect-gateway def1"
push "remote-gateway vpn_server_ip"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 60
    • 49

  2. Maybe you forgot to modify your NAT? Run those 3 commands as root

    Commands:

    iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

iptables -t nat -I POSTROUTING -o eth0 \
          -s 10.8.0.0/24 -j MASQUERADE

    Caption:

    • tun0: your virtual VPN networkcard
    • eth0: your normal networkcard
    • 10.8.0.0: your VPN network ip block
    • 30

  3. After a hard looking for the answer it seems I've solved this, maybe partially, but at least very simply:

    I use Xubuntu 14.04 and OpenVPN package from main source. In Settings > System > Network, I replaced preinstalled DNS-address 127.0.1.1 with Google's 8.8.8.8, and now I can see all traffic going through the VPN-server.

    In Wireshark's table such string as DNS is absent: all data goes like TCP through encrypted channel. I can see DHCP and DNS traffic when I look at tun0 (notebook's internal). When I explore wlan0 traffic (external between notebook and WiFi router) I only get grey TCP packages.

    I think it's happening because DNS-query isn't needed in characters-to-numbers decoding and it goes in common stream like a usual data package.

    I'll be glad to know your considerations, it will not be surprise if I'm completely wrong

    • 1

  4. I faced the same problem and found out when using the PiVPN setup script for Open VPN, the server config contains the line:

    push "redirect-gateway def1 bypass-dhcp"

    already. On the IOS client everything is routed through the tunnel automatically (that is what the log says).

    On the Tunnelblick client you need to add this line in the client.ovpn file:

    redirect-gateway def1 bypass-dhcp

    and it should work perfectly. At least it did on my Mac.

    • 1

  5. On server side find server.conf file and just add this line into it

    push "redirect-gateway autolocal"

    It will redirect all client side traffic trough tunnel

    • 1

  6. If your OpenVPN client is on Windows 10 (or similar) there is another issue to watch out for, the binding order of the NICs. The existing DNS server settings on the LAN or Wifi adapter may take priority over the DNS server settings for the tunnel interface, so even though everything is set up corectly from an OpenVPN point of view, Windows continues to use the original DNS server.

    You can fix this as described in this Microsoft forum post.

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/1cc5b647-6e51-482b-8998-ac5c3900938c/how-to-force-vpn-clients-to-use-the-dnsserver-from-their-vpn-adapter-not-the-dnsserver-from-their?forum=winserverNIS

    • -1