54

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

3
  • Did you try push "route 0.0.0.0 0.0.0.0" or similiar to push routes? Don't forget the route back in the VPN!
    – lub
    May 14, 2014 at 14:39
  • Yeah this is done autmatically when the push "redirect-gateway def1" is used ... It adds 0.0.0.0 mask 127.0.0.0 and 127.0.0.0 mask 127.0.0.0 (overtaking the default route without deleting the one already there) May 14, 2014 at 15:05
  • I am concerned if you are running the client as "Run As Administrator" in windows! This problem can happen if you run the OVPN Windows Client without administrator run.
    – Kousha
    Oct 5, 2014 at 9:25

6 Answers 6

50
+100

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
3
  • Tried that today ... Still no luck. I notice you're using a TUN adapter rather than a TAP adapter ... I'll give that a go instead and report back :D May 16, 2014 at 14:27
  • 1
    Okie, using a TUN adapter seems to be working ... Although I'm getting a little troubled by the routes I need to assign ... I'm using 192.168.1.0/24 for the VPN network, and 192.168.0.0/24 is my server LAN. So in my server config, i've added route 192.168.1.0 255.255.255.0 and push "route 192.168.0.0 255.255.255.0" but my client isn't getting access to any other subnets apart from it's 192.168.1.0/24 net ... I'll poke around a little more May 16, 2014 at 17:55
  • option "remote-gateway" not recognized or missng extra parameters :/ Apr 15, 2020 at 9:35
32

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
6
  • 2
    This NAT modification step is very crucial. I just couldn't get this working without executing above 3 commands. Jun 15, 2015 at 8:13
  • 7
    note that these commands need to be run on the openvpn server, not the client.
    – Kem Mason
    Mar 17, 2016 at 22:52
  • 2
    I found that only modifying the nat table was also working on my server.
    – Ginhing
    Jul 14, 2018 at 9:38
  • 1
    Do we need to persist the iptables rules in case the openVPN server is rebooted?
    – DWils
    Nov 15, 2018 at 22:09
  • @DWils Yes, you need to put them in some startup script. Check this Q&A: askubuntu.com/questions/270693/…
    – Arne
    Jun 4, 2019 at 10:17
1

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

2
  • I forgot: this method has one indisputable advantage - it works even if a VPN-server doesn't support DNS-rerouting.
    – xrobot
    Jul 11, 2014 at 21:33
  • By the way, we could do one trick: if we will send from time to time false visible innocent DNS-queries, indirectly it could be confirmation of our loyalty to the Big Brother.
    – xrobot
    Jul 11, 2014 at 21:33
1

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
  • This worked for me. Thanks. Jul 31, 2020 at 10:11
1

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

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
  • not an answer to the question
    – pim
    Mar 4, 2018 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .