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 <apollon@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