[strongSwan] Issues observed with Server leases in road warrior configuration

[Kaur, Sumit (NSN - IN/Bangalore)]

Hi,

When configuring road warrior as below in  strongswan version 4.3.6, we observe an odd behavior w.r.t the Server leases.


Server :-

conn r1~v1
         left=40.0.0.1
        right=%any
        leftsubnet=40.0.0.1/32
        rightsourceip=99.0.0.0/30
        authby=secret
        leftid=40.0.0.1
        rightid=%any


Client :-

conn r1~v1
        left=25.0.0.2
        right=40.0.0.1
        leftsourceip=%config
        rightsubnet=40.0.0.1/32
        authby=secret
        leftid=25.0.0.2
        rightid=%any



The Server assigns all IPs from its pool to connecting client r1~v1, if r1~v1 connects to it several times, but maintains only the latest virtual ip address entry in the lease. The client has multiple xfrm policies corresponding to all virtual IPs assigned.

# ipsec leases
Leases in pool 'r1~v1', usage: 1/3, 1 online
         99.0.0.1   online   '(vr*)25.0.0.2'

# ipsec leases
Leases in pool 'r1~v1', usage: 1/3, 1 online
         99.0.0.2   online   '(vr*)25.0.0.2'



Deleting r1~v1 connection from client, disables the lease from the server, but the client does not delete all virtual IPs and has the respective xfrm policies still in kernel.

# ipsec leases
Leases in pool 'r1~v1', usage: 1/3, 0 online
         99.0.0.2   offline   '(vr*)25.0.0.2'


Client side :

# ip xfrm policy
40.0.0.1/32[0] 99.0.0.2/32[0]
        upspec 1 dev (none) uid 0
        in  allow index 0x00001208 priority 1678 share any flags 0x00000000
        tmpl-1:
          40.0.0.1 25.0.0.2
                esp spi 0(0x00000000) reqid 4 tunnel
                level required share any algo-mask:E=32, A=32, C=32
        fpid 0x000000a4
        policy type main
99.0.0.2/32[0] 40.0.0.1/32[0]
        upspec 1 dev (none) uid 0
        out allow index 0x00001201 priority 1678 share any flags 0x00000000
        tmpl-1:
          25.0.0.2 40.0.0.1
                esp spi 0(0x00000000) reqid 4 tunnel
                level required share any algo-mask:E=32, A=32, C=32
        fpid 0x000000a3
        policy type main


It is possible in this scenario, that server gives 99.0.0.2 virtual ip address to a new connection(it assumes 99.0.0.2 is offline), but 99.0.0.2 is still present on a previous connection.


The above behavior seems to be incorrect. Ideally, at first place itself, server should not assign different virtual IPs to the same client even if the client tries to connect to it several times.

Can someone provide inputs on this.

Thanks
Sumit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150204/d50ad782/attachment.html>