[strongSwan] Strongswan routing

[strongswan]

We are in the process of qualifying strongSwan 5.2.0 and are questioning (1) if strongSwan is installing the correct routing flags and (2) if routing should be installed at all for site-to-site setups.

The following was observed with strongSwan 5.2.0 and FreeBSD 10.1:

+-------+                +------+                  +-----+
| Alice |--10.1.0.0/16---| Moon |--192.168.0.0/24--| Sun |--10.2.0.0/16---
|       |.10           .1|      |.1              .2|     |
+-------+                +------+                  +-----+

We have the following policy on box alice
conn host_sun
        left=10.1.0.10
        leftcert=aliceCert.pem
        leftid=alice at strongswan.org
        right=192.168.0.2
        rightid=@sun.strongswan.org
        rightsubnet=192.168.0.2/32
        auto=route

And we have the following policies on box sun
conn host_alice
        left=192.168.0.2
        right=10.1.0.10
        rightsubnet=10.1.0.10/32
        rightid=alice at strongswan.org
        auto=add

conn s2s_sun_moon
        left=192.168.0.2
        leftsubnet=10.2.0.0/16
        right=192.168.0.1
        rightsubnet=10.1.0.0/16
        rightid=@moon.strongswan.org
        auto=route

This setup allows all the devices in the subnet behind moon to communicate with the devices in the subnet behind sun with a site to site policy (10.2.0.0/16 <-> 10.1.0.0/16). The setup also allows alice (10.1.0.10) to communicate directly with sun with a host to host policy.

What we noticed is that in the charon configuration the option charon.install_routes=YES option is specified by default. When strongSwan is started on sun, it installs a policy in the routing table of sun as follows:

Destination        Gateway            Flags      Netif Expire
default            192.168.0.1        UGS         em0
10.1.0.0/16        192.168.0.1        US          em0

What we then noticed is that if Alice now tries to establish a IKE connection to sun alice receives no response from sun. On further investigation we noticed that sun is sending ARP requests requesting the MAC adddress for IP 10.1.0.10.

We have isolated the issue to the route that is installed by strongSwan in the routing table (10.1.0.0/16        192.168.0.1)
The flags used for this route is US which indicates usable and static.
Looking at the default route and the netstat man page the following flags are used on the routes.

G    RTF_GATEWAY      Destination requires forwarding by intermediary
S    RTF_STATIC       Manually added
U    RTF_UP           Route usable

With the route installed by strongSwan the G flag is missing, and since the subnet is not directly reachable it must be forwarded to the gateway. However with the absence of this flag the kernel tries to acquire the mac address for the IP.

Questions:
1. What is your assessment of the above situation, Is it something that needs to be fixed in strongswan?
2. For what use cases do routes need to be installed, considering the fact that the security policies in the kernel already "route" traffic destined for the peer's network to the peer's IPsec gateway? (In the case of site-to-site setups)
3. Strongswan 5.0.4 did not install any routes but 5.2.0 does. Is there a difference in default behaviour or implementation between these two versions that would make the latter install routes and the former not?

Regards
Riaan


Important Notice:

This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at:
http://www.nanoteq.com/AboutUs/EmailDisclaimer.aspx