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

[Deepika Agarwal]

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=192.168.0.100/24" in the client
side configs is to establish the TS i.e whenever there is any traffic
from 192.168.0.100/24 to 192.168.5.2/32 => start creating an IPSec
tunnel.

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
(i.e 192.168.5.0/24).

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

client:

conn android
    left=%defaultroute
    leftid="abc"
    leftsourceip=%config
    leftsubnet=192.168.0.0/24
    leftfirewall=yes
    leftauth=eap-mschapv2
    eap_identity=deepika
    right=192.168.1.154
    rightid=192.168.1.154
    rightsubnet=192.168.5.0/24
    rightauth=pubkey
    auto=route


server:

conn android
    left=192.168.1.154
    leftid=192.168.1.154
    leftsubnet=192.168.5.0/24
    leftcert=moonCert.pem
    leftauth=pubkey
    leftfirewall=yes
    lefthostaccess=yes
    right=%any
    rightsourceip=10.0.3.0/24
    rightsubnet=192.168.0.0/24
    rightauth=eap-mschapv2
    rightsendcert=never
    eap_identity=%any
    auto=add

IPsec statusall on client:

Connections:
     android:  192.168.0.100...192.168.1.154
     android:   local:  [abc] uses EAP_MSCHAPV2 authentication with
EAP identity 'deepika'
     android:   remote: [192.168.1.154] uses public key authentication
     android:   child:  192.168.0.0/24 === 192.168.5.0/24 TUNNEL
Routed Connections:
     android{1}:  ROUTED, TUNNEL
     android{1}:   192.168.0.0/24 === 192.168.5.0/24
Security Associations (1 up, 0 connecting):
     android[2]: ESTABLISHED 15 seconds ago,
192.168.0.100[abc]...192.168.1.154[192.168.1.154]
     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}:   192.168.0.0/24 === 192.168.5.0/24

The packets are sent in ESP b/w client and server, but the tunnel ip
address used is 192.168.0.100 inspite of 10.0.3.1.
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.

Thanks
Deepika




On Wed, Apr 11, 2012 at 11:13 PM, Tobias Brunner <tobias at strongswan.org> wrote:
> 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/



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