Home / server / Questions / 67167
Accepted
Coops
Asked: 2009-09-21 11:52:46 +0800 CST

OpenVPN working - but how to route all traffic down it?

  • 772

I've setup a static one-to-one OpenVPN connection fine. However I can't seem to get the client to route all traffic via the VPN device. Here's my configs:

Client config:

remote 89.21.xx.xx
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

Server config:

dev tun
ifconfig 10.8.0.1 10.8.0.2
push "redirect-gateway def1"
secret static.key
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
verb 5

From all the research I've done the server config line push "redirect-gateway def1" should make the clients route all traffic via the VPN. However it doesn't have this effect. I can ping/ssh/http to the server on 10.8.0.1, and the routing table of the client looks like below, but normal traffic is taking the normally (unsecure) route:

root@t42:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.69.0    0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.69.1    0.0.0.0         UG    0      0        0 wlan0
linux

3 Answers

  1. Best Answer

    You need to have "pull" in your client config in order to be able to "push" settings from the server.

    Once you add that, it should work as you expect.

    (if you use the "client" directive, it basically expands to "pull" and "tls-client")

    • 2

  2. You can either run route add default gw 10.8.0.1 (either by hand or automatically when the tunnel comes up); that'll add the route. Alternately, I've got push "route 0.0.0.0 0.0.0.0" in the OpenVPN config that does a default route for me, and that works, too.

    • 1

  3. The def1 argument alters the behaviour of redirect-gateway slightly. It is akin to:

    route add 0.0.0.0/1 gw <vpn_endpoint>

    This ensures that the VPN route takes preference over but doesn't remove the existing default route.

    As for debugging the issue I would suggest:

    1. Take a look at jamesb's very good point.
    2. Increase the client verbosity. It should indicate whether the directive is coming down from the server and whether there was a problem running the route command.
    3. Try placing the directive in the client's configuration to test whether it works without push.
    4. Try dropping the def1 argument and have it replace the default route to see whether it makes any difference to the behaviour.
    • 1