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

Deepika Agarwal deepi7.agarwal at gmail.com
Fri Apr 13 09:38:06 CEST 2012


Hi Tobias,

I tried the second option of setting a static virtual ip to the client
and same subnet as the rightsourceip on server.

Client:

conn android
    left=%any
    leftid="abc"
    leftsourceip=10.3.0.1/32
    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.3.0.0/24
    rightauth=eap-mschapv2
    rightsendcert=never
    eap_identity=%any
    auto=add

But still client is not able to pick the virtual ip address of
10.3.0.1 for installing the routes.

ipsec statusall on client:

Listening IP addresses:
  192.168.0.100
Connections:
     android:  %any...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:  dynamic === 192.168.5.0/24 TUNNEL
Routed Connections:
     android{1}:  ROUTED, TUNNEL
     android{1}:   192.168.0.100/32 === 192.168.5.0/24
Security Associations (1 up, 0 connecting):
     android[2]: ESTABLISHED 4 seconds ago,
192.168.0.100[abc]...192.168.1.154[192.168.1.154]
     android[2]: IKE SPIs: bf44a3ca69840a0a_i* af70f0ddb6d8e14a_r, EAP
reauthentication in 46 minutes
     android[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

As you can see , the installed policy is for 192.168.0.100/32 ===
192.168.5.0/24. Am I missing something here?

Thanks
Deepika

On Thu, Apr 12, 2012 at 3:18 PM, Tobias Brunner <tobias at strongswan.org> wrote:
> Hi Deepika,
>
>> 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 problem is that the client does generally not know the virtual IP
> address assigned by the gateway.  So if you wanted to actually use the
> virtual IP address inside of the IPsec tunnel you'd have to install that
> (unknown) address on your system and install a trap policy that matches
> packets sent from this (unknown) address.  Additionally, a source route
> is most likely required to force the use of this (still unknown) IP
> address otherwise the packets will be addressed with the native IP
> address of the client and the trap policy will not be matched.  Due to
> this auto=route does not work with virtual IPs in general.
>
>> 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).
>
> Ok, see below for a possible workaround.
>
>> 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
>>     ...
>>     leftsubnet=192.168.0.0/24
>>     ...
>>
>> server:
>> conn android
>>     ...
>>     rightsourceip=10.0.3.0/24
>>     rightsubnet=192.168.0.0/24
>>     ...
>
> With this config you simply force the client to the following traffic
> selector
>
>>      android{1}:   192.168.0.0/24 === 192.168.5.0/24
>
> so the virtual IP (probably 10.0.3.1) does not fit into this and is not
> assigned.
>
>> 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.
>
> Yes that's the typical RW setup where left|rightsubnet is automatically
> derived from the assigned virtual IP address.
>
>> Please suggest if there is any workaround to fetch the virtual ip in
>> the case of "auto=route" option.
>
> There is but you have to assign fixed virtual IP addresses to each
> client (based on their leftid) and the clients have to know the IP
> beforehand.  To do that you can either add individual conn sections for
> each client with their rightid and rightsource=x.x.x.x/32 set or you use
> the attr-sql plugin which allows you to add fixed leases in the database
> (see [1], for an example see [2]).  Then you can configure the clients
> with leftsubnet=x.x.x.x/32, leftsourceip=%config and auto=route.  You
> should also be able to use leftsourceip=x.x.x.x/32 on the clients and
> the server should accept that proposal (when configured with e.g.
> rightsourceip=x.x.x.0/24) if the requested IP address is free, but it
> will break again if it is not.
>
> Regards,
> Tobias
>
> [1] http://wiki.strongswan.org/projects/strongswan/wiki/Attrsql
> [2] http://strongswan.org/uml/testresults/sql/ip-pool-db-restart/index.html



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




More information about the Users mailing list