2

I have an OpenVPN client running on a DD-WRT router. The global set-up (server + client) is configured so all traffic from machines connected to the router goes through the VPN tunnel, and it works perfectly.

However, I'd like to override this default behaviour for one particular machine. Let's say my local network is defined as 192.168.10.0/24. The router is located at 192.168.10.254. The machine I want to route outside the VPN tunnel is located at 192.168.10.135.

Following this Serverfault answer, or this OpenVPN thread, I added the directive 

route 192.168.10.135 255.255.255.255 net_gateway

to the OpenVPN client config file.

However, even if I have the confirmation that this new rule has been successfully added by looking at the routing table of the router, this doesn't work. Not only the machine .135 now cannot connect to the internet, but it's not even able to connect to the LAN anymore (eg, a simple ping 192.168.10.254 fails).

Am I missing something in the VPN client configuration? Or somewhere else?

Thank you for your help.

EDIT - as requested in the comment, here are what I got from the router's shell.

root@router $ ip -4 addr
1: lo: <LOOPBACK,MULTICAST,UP,10000> mtu 65536 qdisc noqueue 
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
   inet 47.X.X.250/24 brd 47.X.X.255 scope global eth1
   valid_lft forever preferred_lft forever
6: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue 
   inet 169.X.X.1/16 brd 169.X.X.255 scope global br0:0
   valid_lft forever preferred_lft forever
   inet 192.168.10.254/24 brd 192.168.10.255 scope global br0
   valid_lft forever preferred_lft forever
11: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
   inet 10.8.0.6 peer 10.8.0.5/32 scope global tun1
   valid_lft forever preferred_lft forever

Note: 47.X.X.250 is my public ISP address. 167.X.X.. is the address of the VPN server in the cloud.

root@router $ ip route get 192.168.10.135
192.168.10.135 via 47.X.X.1 dev eth1  src 47.X.X.250 
    cache

root@router $ ip route
0.0.0.0/1 via 10.8.0.5 dev tun1 
default via 47.X.X.1 dev eth1 
10.8.0.1 via 10.8.0.5 dev tun1 
10.8.0.5 dev tun1  proto kernel  scope link  src 10.8.0.6 
47.X.X.0/24 dev eth1  proto kernel  scope link  src 47.X.X.250 
127.0.0.0/8 dev lo  scope link 
128.0.0.0/1 via 10.8.0.5 dev tun1 
167.X.X.107 via 47.X.X.1 dev eth1 
169.X.X.0/16 dev br0  proto kernel  scope link  src 169.X.X.1 
192.168.10.0/24 dev br0  proto kernel  scope link  src 192.168.10.254 
192.168.10.135 via 47.X.X.1 dev eth1

root@router $ ip rule
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default
edthrn
  • 121
  • 4
  • Since it's not working as expected, you should add (with edit, in the question) various routing informations from the router once the tunnel is up, like `ip -4 addr; ip route; ip rule; iptables-save -c`; and an additionnal `ip route get 192.168.10.135` (obfuscate public ips if needed) – A.B May 14 '18 at 06:44
  • i'm not sure the cases you linked are for this kind of use. they are for the client (your router) to access some Ips outside (ie not be routed via) the VPN. not the "clients of the client" to not be routed via the VPN. I hope you get the difference. YOur solution probably requires policy routing: depending on the source (eg: from 192.168.11.135), use a different route. normally route depends only on destination – A.B May 14 '18 at 14:28
  • similar question to yours (but even more complex because the policy routing would happen directly with the router ): https://serverfault.com/questions/107633/policy-routing-with-openvpn . a question more similar to yours without even an answer: https://superuser.com/questions/1299204/bypass-openvpn-tunnel-for-specific-devices-ips-on-tomato-router-setup . – A.B May 14 '18 at 14:38
  • you should try and adapt this: [OpenVPN source based routing](https://beenje.github.io/blog/posts/openvpn-source-based-routing/#source-based-routing) – A.B May 14 '18 at 14:41
  • Thank you for your inputs. I'm gonna do some testing tonight and keep this post updated – edthrn May 14 '18 at 15:49

0 Answers0