I had a check, but OpenSWAN doesn't seem to do this (at least with netkey) - I don't see any additional routing tables. Given the time I've spent so far with OpenSWAN I'll give the script route a go, then investigate StrongSWAN later. From looking at the website it looks much better documented - I had to buy the OpenSWAN book before I could work out what was going on.
Iain On 11 November 2013 15:45, Apollon Oikonomopoulos <apol...@skroutz.gr>wrote: > Hi Iain, > > On 13:27 Mon 11 Nov , Iain wrote: > > Hi Eliezer, > > > > “ip addr” gives just the local addresses (it doesn’t include anything > OpenSWAN related) - e.g. > > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 scope host lo > > valid_lft forever preferred_lft forever > > inet6 ::1/128 scope host > > valid_lft forever preferred_lft forever > > 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN > > link/ether 46:36:d3:05:b9:9a brd ff:ff:ff:ff:ff:ff > > 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UP qlen 1000 > > … > > > > “ip route” gives just the default route, plus one per interface (again, > nothing OpenSWAN related): > > I don't know about OpenSWAN, but StrongSWAN places the VPN routes in a > different routing table (220 by default). You can guess this is > happening by having a look at the relevant rules (`ip rule list'). If > this is the case with OpenSWAN as well, you can just create an > additional kernel protocol in BIRD and learn the routes from that > special routing table. > > Apollon >