Route by IP address over tun0 - 'ip rule add from a.b.c.d'

Would anyone be kind enough to give me some pointers to route packets
from a specific ip on my subnet via the tun0 OpenVPN interface, and
all other hosts out the default route of the main routing table
(192.168.1.1 on br0)?

i.e. 192.168.1.2-9 -> via br0, and 192.168.1.200 -> via tun0

I have created the tables:

mkdir /etc/iproute2
echo 201 table1 >> /etc/iproute2/rt_tables
ip rule add from 192.168.1.200/32 table table1

But i am really stuck from here. I tried adding default routes in the
table1 but all traffic stops at this point (i am pinging from the host
192.168.1.200 out onto the net, it works as soon as this command below
is entered it times out):

ip route add 10.19.0.5 dev tun0 scope link src 10.19.0.6 table table1
(not sure if this is needed - either way doesnt work with or without)
ip route add default via 10.19.0.5 dev tun0 table table1

I did try: ip route add default dev tun0 table table1. and again that
fails to work. I appreciate this isnt a guessing game hence moving to
post here in hope of some expert advice.

Routing table for the main table (table 1 contains the entries from
above commands):

root@OpenWrt:~# ip route list table table1
default via 10.19.0.5 dev tun0

root@OpenWrt:~# ip route list table main
10.20.30.40 via 192.168.1.1 dev br0
10.19.0.1 via 10.19.0.5 dev tun0
10.19.0.5 dev tun0 proto kernel scope link src 10.19.0.6
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.4
default via 192.168.1.1 dev br0

There is a point to point link to the OpenVPN server on 10.19.0.5 with
a local address of 10.19.0.6, but im not sure if this needs to be
added in the table1? I did try by adding ip route add 10.19.0.5 dev
tun0 scope link src 10.19.0.6 table table1, but again still the same
issue.

With OpenVPN setup to push the redirect-gateway option, all works well
with the routing table and the box acts as a router sending everything
through it (table shown below - this works fine apart from everyone is
routed through it). As mentioned, I would like the tables default
route below to only apply to the host 192.168.1.200. I am posting the
table below as this does work for all hosts:

root@OpenWrt:~# ip route list table main
10.20.30.40 via 192.168.1.1 dev br0
10.19.0.1 via 10.19.0.5 dev tun0
10.19.0.5 dev tun0 proto kernel scope link src 10.19.0.6
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.4
default via 10.19.0.5 dev tun0

Many thanks in advance

One point i forgot to mention is that I am masquerading on tun0 as i
will be routing a number of hosts through the router:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

I also run 'ip route flush cache' after i enter the routing commands
but to no avail.

Cheers

Hello,

(E-Mail Removed) a écrit :
> Would anyone be kind enough to give me some pointers to route packets
> from a specific ip on my subnet via the tun0 OpenVPN interface, and
> all other hosts out the default route of the main routing table
> (192.168.1.1 on br0)?
>
> i.e. 192.168.1.2-9 -> via br0, and 192.168.1.200 -> via tun0
>
> I have created the tables:
>
> mkdir /etc/iproute2
> echo 201 table1 >> /etc/iproute2/rt_tables
> ip rule add from 192.168.1.200/32 table table1
>
> But i am really stuck from here. I tried adding default routes in the
> table1 but all traffic stops at this point (i am pinging from the host
> 192.168.1.200 out onto the net, it works as soon as this command below
> is entered it times out):

All you can infer from this test is that the ping program receives no
replies with the advanced routing setup. This does not necessary mean
that the echo requests are not sent correctly. Maybe the problem is on
the reverse path. Have you traced the traffic at each virtual and
physical interface on each hop ?

> root@OpenWrt:~# ip route list table table1
> default via 10.19.0.5 dev tun0

Seems fine to me.

> With OpenVPN setup to push the redirect-gateway option, all works well
> with the routing table and the box acts as a router sending everything
> through it (table shown below - this works fine apart from everyone is
> routed through it).

So we can reasonably believe that the routing at the other end of the
VPN is ok. Check that the source validation by reversed path is disabled
for the VPN tun0 (/proc/sys/net/ipv4/conf/tun0/rp_filter=0 or
/proc/sys/net/ipv4/conf/all/rp_filter=0). This is often needed because
the validation check does not take the advanced routing rules into account.