[Swan] libreswan subnet to subnet (on top of Openstack Neutron)

Paul Wouters paul at nohats.ca
Fri Sep 23 00:03:40 UTC 2016

On Wed, 21 Sep 2016, Charlie Brown (charlibr) wrote:

> Subject: [Swan] libreswan subnet to subnet (on top of Openstack Neutron)
> * Libreswan 3.15 ipsec (libreswan-3.15-5.el7_1.x86_64)
> * Openstack Icehouse
> * RHEL 7.1 boxes used as routers
> Followed this document (with modifications) https://libreswan.org/wiki/Subnet_to_subnet_VPN_with_PSK
> I am attempting to create libreswan ipsec tunnels between tenants in an Openstack Icehouse cloud.  I
> have created a shared subnet ( that the RHEL boxes attach to in a multi-homed fashion. 
> Each box has two interfaces. net.ipv4.ip_forward is enabled (1) on each box.
>     Router in tenant A                           Router in tenant B
>     ------------------------                     ------------------------
>     eth0      eth1           <=================> eth1           eth0
>     ------------------------                     ------------------------

> Running this config on each end has the tunnel coming up without any errors.  When the tunnel comes up,
> libreswan adds a new route with a higher priority than the initial static route:
> dev eth1  scope link  src
> via dev eth1  proto static  metric 100

It does that because you set leftsourceip= and rightsourceip=.

The kernel normally picks the "nearest IP" as source IP, so if on tenant
A you normally type "ping", it would pick the nearest IP as
source, which is Your packet with source
and destination would not be covered by your tunnel that
only covers to <=>, and the packet would not
get encrypted (and hopefully a firewall would drop it). When setting
leftsourceip/rightsourceip, a route is added so that the kernel knows
it should pick the internal IP instead of the nearest IP Things then get properly encrypted for the gateways as
well as the subnets.

> I can ping the remote router's eth0 interface IP address but not any hosts in the remote subnet.  This
> is true from either direction. 

That's usually the result of either forwarding permissions (sysctl or in
iptables) or rp_filter or accidental NAT'ing of packets destined for IPsec.

>     traceroute to (, 64 hops max, 52 byte packets

You cannot really use traceroutes for the hops related to the tunnel.

You can run "ipsec verify" to runs some tests including rp_filter.

You can also add some firewall rules to ensure you are not accidentally
NAT'ing pcakets meant for IPsec. See:



More information about the Swan mailing list