2

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
2

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")

1
  • I tried the "pull" flag (also played with the "client" flag). However it seemed it didn't like the static setup, and wanted a proper CA based setup. However with that now in place it works. Cheers.
    – Coops
    Sep 23 '09 at 7:43
1

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
  • I swear I tried manually adding the route, but with no luck. I shall try again this evening.
    – Coops
    Sep 21 '09 at 9:39
1

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.
2
  • Thanks for the help. It seems when I switched from a static to CA setup it all worked fine.
    – Coops
    Sep 23 '09 at 7:44
  • I know this is a really old answer, but I've just come across this and it looks wrong to me. Doesn't 0.0.0.0/1 match all addresses from 0.0.0.0 to 127.255.255.255 and leave everything else to the default route? So half the internet goes over your VPN and half over your default route...
    – Tom
    Jan 30 '20 at 9:34

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.