[strongSwan] Strongswan routing
strongswan at Nanoteq.com
Wed Nov 26 12:16:50 CET 2014
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
leftid=alice at strongswan.org
And we have the following policies on box sun
rightid=alice at strongswan.org
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.
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?
This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at:
More information about the Users