[strongSwan] ip xfrm policy result of transport mode

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Thu Dec 21 22:31:28 CET 2017


There's nothing wrong.
I'm sure if you check the output of `ipsec statusall`/`swanctl -l` when you see those XFRM policies, you will see that the initiator (e.g. iPhone) negotiated a TS where its local port is set to 1024, whereas strongSwan doesn't.

On 20.12.2017 11:32, Nimo wrote:
> Hello,
>
> I'm using transport mode with strongSwan 5.3.5. It works fine , but result of 'ip xfrm policy' may be somehing wrong.
>
> 1) I configure strongSwan-1 and stronSwan-2 as below. Then I execute 'ip xfrm policy', the result was "[strongSwan's result]" in below.
> 2) I launched iPhone's L2TP to strongSwan-1. Then the 'ip xfrm policy' showed "[iPhone result]"
>
> Difference between above two is number of sport/dport.
> Could you please tell me strongSwan-2 configuration to match iPhone's result ?
>
>
> strongSwan-1
> ----------------------------------------------
> [ipsec.conf]
> conn L2TP
>         left=1.1.1.254
>         authby=secret
>         auto=add
>         keyingtries=3
>         keyexchange=ikev1
>         rekey=yes
>         ike=3des-sha1-modp1024,aes128-sha1,aes256-sha1
>         dpddelay=10
>         dpdtimeout=90
>         dpdaction=clear
>         ikelifetime=8h
>         keylife=1h
>         type=transport
>         leftprotoport=17/1701
>         right=%any
>         rightprotoport=17/%any
>
> [ipsec.secrets]
> 1.1.1.254 %any : PSK "password"
>
> strongSwan-2
> ----------------------------------------------
> [ipsec.conf]
> conn client
>         authby          = secret
>         keyexchange     = ikev1
>         rekey           = no
>         keyingtries     = 3
>         type            = transport
>         right           = 1.1.1.254
>         left            = %defaultroute
>         auto            = start
>         leftprotoport   = 17/%any
>         rightprotoport  = 17/1701
>
>
> [ipsec.secrets]
> 1.1.1.254 : PSK "password"
>
>
> ----------------------------------------------
> [strongSwan's result]
> # ip xfrm policy
> src 1.1.1.254/32 <http://1.1.1.254/32> dst 172.16.14.100/32 <http://172.16.14.100/32> proto udp sport 1701
>         dir in priority 2816 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 1 mode transport
> src 172.16.14.100/32 <http://172.16.14.100/32> dst 1.1.1.254/32 <http://1.1.1.254/32> proto udp dport 1701
>         dir out priority 2816 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 1 mode transport
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
>    .....
>
>
> ----------------------------------------------
> [iPhone result]
> [TEST-L2TP] ~ # ip xfrm policy | less
> src 1.1.1.1/32 <http://1.1.1.1/32> dst 1.1.1.254/32 <http://1.1.1.254/32> proto udp sport 1024 dport 1701
>         dir in priority 2816 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 1 mode transport
> src 1.1.1.254/32 <http://1.1.1.254/32> dst 1.1.1.1/32 <http://1.1.1.1/32> proto udp sport 1701 dport 1024
>         dir out priority 2816 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 1 mode transport
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
>   ....
>
> thank you,
> ---
> takumi kadode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171221/46a5d9d8/attachment.sig>


More information about the Users mailing list