[strongSwan] IPSec SA's not coming up when the device is behind a NAT

[Tobias Brunner]

Hi Deepika,

> conn android
>     ...
>     leftsourceip=%config
>     leftsubnet=192.168.0.100/24
>     ...
>     auto=route
> 
> ipsec.conf on server:
> 
>  conn android
>     ...
>     rightsourceip=192.168.0.100/24
>     ...

This config is problematic on several levels.  First auto=route with
leftsourceip=%config is currently not supported.  The client does
generally not know the virtual IP assigned by the remote host so it
can't install a proper policy that matches such traffic (also the
virtual IP is most likely not yet assigned to any local interfaces).
You then do specify leftsubnet but that makes no sense in combination
with leftsourceip=%config as the traffic selector is naturally just the
assigned (unknown) virtual IP address (you also use /24, which is not
correct for a single IP address).  Another problem is then that you
specify rightsourceip=192.168.0.100/24 on the gateway.  With this option
the gateway creates a virtual IP pool which is actually 192.168.0.0/24,
but it uses 192.168.0.100 as base, so the first IP it assigns to a
client requesting a virtual IP is 192.168.0.101.  The latter is what
gets negotiated and installed in the IPsec policies.  Checking with
ipsec statusall on the client should show something like this:

Routed Connections:
        moon{1}:  ROUTED, TUNNEL
        moon{1}:   192.168.0.0/24 === 192.168.5.2/32
Security Associations (1 up, 0 connecting):
        ...
        android{1}:   192.168.0.101/32 === 192.168.5.2/32

You see the wide trap policy (due to your /24 leftsubnet) under "Routed
Connections" and the narrow policy installed with the established SA.

The reason why you are actually able to send encrypted packets from
192.168.0.100 is basically that the trap policy and the actual IPsec
policy share the same reqid ({1}, you can see that with ip xfrm policy
too).  That is, after the SA is established packets sent from any
address in 192.168.0.0/24 are actually sent into the established tunnel.
 The gateway, of course, discards any packets not coming from
192.168.0.101 as they do not match its inbound IPsec policy.  Now,
charon tries to install a source route when the SA is established which
should force the virtual IP address as source for any packets sent to
192.168.5.2.  The problem is, though, that auto=route already caused the
installation of such a route with 192.168.0.100 as source, instead.  The
latter route now prevents the installation of the proper one.  So, if
you simply ping 192.168.5.2 the selected source address is 192.168.0.100
instead of 192.168.0.101 which does not match the proper policy but does
match the trap policy (thus causing the packet to be tunneled anyway) on
the gateway the packet is then dropped as the source does not match the
installed policy.  By the way, using ping -I 192.168.0.101 192.168.5.2
should work fine.

The question is, what were actually trying to do.  For simple
roadwarrior connections you might want to have a look at the rw- or nat-
examples in our test suite [1].

Regards,
Tobias

[1] http://www.strongswan.org/uml/testresults/ikev2/