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

Deepika Agarwal deepi7.agarwal at gmail.com
Thu Apr 12 09:29:52 CEST 2012

Hi Tobias,

Thanks for the inputs.
I was wondering if
>auto=route with
> leftsourceip=%config is currently not supported
then how will the client gets the virtual ip address in case of an
automatic tunnel establishment as per the established traffic
selectors (auto=route)
The reason I mentioned "leftsubnet=" in the client
side configs is to establish the TS i.e whenever there is any traffic
from to => start creating an IPSec

My primary goal is to start the IPSec tunnel automatically whenever
there is any traffic from the RW client to the subnet behing the GW

Following configs seems to be working, but the virtual ip from the
pool is not assigned to the client.


conn android


conn android

IPsec statusall on client:

     android:   local:  [abc] uses EAP_MSCHAPV2 authentication with
EAP identity 'deepika'
     android:   remote: [] uses public key authentication
     android:   child: === TUNNEL
Routed Connections:
     android{1}:  ROUTED, TUNNEL
     android{1}: ===
Security Associations (1 up, 0 connecting):
     android[2]: ESTABLISHED 15 seconds ago,[abc]...[]
     android[2]: IKE SPIs: ba674815cebbe46c_i* e80840062f4d297c_r, EAP
reauthentication in 47 minutes
     android[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
     android{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c3aaec40_i cd84a71b_o
     android{1}:  AES_CBC_128/HMAC_SHA1_96, 924 bytes_i (5s ago), 924
bytes_o (5s ago), rekeying in 2 minutes
     android{1}: ===

The packets are sent in ESP b/w client and server, but the tunnel ip
address used is inspite of
So, the tunnel seems to be established but not in the right way.

However, if I do auto=add on the client side and remove leftsubnet(on
the client side) and rightsubnet(on the server side), virtual ip
address is successfully installed and used.

Please suggest if there is any workaround to fetch the virtual ip in
the case of "auto=route" option.


On Wed, Apr 11, 2012 at 11:13 PM, Tobias Brunner <tobias at strongswan.org> wrote:
> Hi Deepika,
>> conn android
>>     ...
>>     leftsourceip=%config
>>     leftsubnet=
>>     ...
>>     auto=route
>> ipsec.conf on server:
>>  conn android
>>     ...
>>     rightsourceip=
>>     ...
> 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= on the gateway.  With this option
> the gateway creates a virtual IP pool which is actually,
> but it uses as base, so the first IP it assigns to a
> client requesting a virtual IP is  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}: ===
> Security Associations (1 up, 0 connecting):
>        ...
>        android{1}: ===
> 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
> 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 are actually sent into the established tunnel.
>  The gateway, of course, discards any packets not coming from
> 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
>  The problem is, though, that auto=route already caused the
> installation of such a route with as source, instead.  The
> latter route now prevents the installation of the proper one.  So, if
> you simply ping the selected source address is
> instead of 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
> 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/

If you think you can or if you think you can't, you are right.
-Henry Ford

More information about the Users mailing list