39

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

  • 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 '14 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) – Just Lucky Really May 14 '14 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 '14 at 9:25
34
+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 the 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
  • 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 – Just Lucky Really May 16 '14 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 – Just Lucky Really May 16 '14 at 17:55
19

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
  • 1
    This NAT modification step is very crucial. I just couldn't get this working without executing above 3 commands. – Nitesh Kumar Anand Jun 15 '15 at 8:13
  • 6
    note that these commands need to be run on the openvpn server, not the client. – Kem Mason Mar 17 '16 at 22:52
  • 1
    I found that only modifying the nat table was also working on my server. – Ginhing Jul 14 '18 at 9:38
  • 1
    Do we need to persist the iptables rules in case the openVPN server is rebooted? – DWils Nov 15 '18 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 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

  • I forgot: this method has one indisputable advantage - it works even if a VPN-server doesn't support DNS-rerouting. – xrobot Jul 11 '14 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 '14 at 21:33
1

Add the following directive to the server configuration file:

push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

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

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra client-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

0

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

  • not an answer to the question – pim Mar 4 '18 at 19:07
0

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 the line:

redirect-gateway def1 bypass-dhcp

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.