[strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Fri Mar 20 16:14:57 CET 2020


IKEv1 does not support several subnets per side.
You need to enumerate all desired combinations in seperate conns. Or just use swanctl, because ipsec is deprecated. Then the configuration is more obvious.

Am 20.03.20 um 16:11 schrieb Makarand Pradhan:
> Hi All,
> 
> The solution, I mentioned earlier is wrong. If I specify the routes explicitly, then the packets go through even with the tunnel down. 
> 
> If the tunnel is up, the packets are encrypted. That is good.
> 
> So, this issue is still unresolved. Pl do comment. Any advice would be highly appreciated.
> 
> Kind rgds,
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> 5895 Ambler Dr,
> Mississauga, Ontario
> L4W 5B7
> Main Line: +1-844-520-0588 Ext. 129
> Direct Line: +1-289-724-2296
> Cell: +1-226-501-5666
> Fax:+1-289-401-5206
> Email: makarandpradhan at is5com.com
> Website: www.iS5Com.com
> 
>  
> Confidentiality Notice: 
> This message is intended only for the named recipients. This message may contain information that is confidential and/or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.
> 
> -----Original Message-----
> From: Users <users-bounces at lists.strongswan.org> On Behalf Of Makarand Pradhan
> Sent: March 19, 2020 4:07 PM
> To: users at lists.strongswan.org
> Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
> 
> Hi All,
> 
> The wiki gave me a hint. The issue was route.  For v1 the remote protected network route has to be explicitly added:
> 
> For me:
> ip ro add 10.10.9.0/24 via 91.0.0.3 
> ip ro add 192.168.9.0/24 via 91.0.0.2
> 
> Thanks all for looking at the issue.
> 
> Kind rgds,
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> 5895 Ambler Dr,
> Mississauga, Ontario
> L4W 5B7
> Main Line: +1-844-520-0588 Ext. 129
> Direct Line: +1-289-724-2296
> Cell: +1-226-501-5666
> Fax:+1-289-401-5206
> Email: makarandpradhan at is5com.com
> Website: www.iS5Com.com
> 
>  
> Confidentiality Notice: 
> This message is intended only for the named recipients. This message may contain information that is confidential and/or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.
> 
> -----Original Message-----
> From: Users <users-bounces at lists.strongswan.org> On Behalf Of Makarand Pradhan
> Sent: March 19, 2020 2:28 PM
> To: users at lists.strongswan.org
> Subject: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
> 
> Hi All,
> 
> I'm having a unique issue. Tunnel is up but packets are not routed when version is ikev1. When I set the version to ikev2, then packets enter the tunnel as expected.
> 
> Config is as follows:
> 
> Running StrongSwan 5.8.2.
> 
> PC - Router1 - Router2 - Tunnel - Router3 - Router4 - PC
> 
> Ipsec.conf:
> conn m1
>         type=tunnel
>         authby=secret
>         auto=add
>         keyexchange=ikev1
>         ike=aes-sha-modp2048!
>         aggressive=no
>         ikelifetime=1500s
>         esp=aes-sha-modp2048!
>         lifetime=1500s
>         right=91.0.0.2
>         rightid=91.0.0.2
>         rightsubnet=192.168.9.0/24,192.168.51.0/24
>         left=91.0.0.3
>         leftid=91.0.0.3
>         leftsubnet=10.10.9.0/24,192.168.61.0/24
> 
> Tunnel is established:
> sh-4.3# ipsec statusall m1
> Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
>   uptime: 31 minutes, since May 21 23:18:31 2018
>   malloc: sbrk 2297856, mmap 0, used 270112, free 2027744
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
>   loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac drbg attr kernel-netlink resolve socket-default stroke vici updown xauth-generic counters Listening IP addresses:
>   10.10.5.11
>   192.168.61.2
>   192.168.62.2
>   91.0.0.3
>   92.0.0.3
> Connections:
>           m1:  91.0.0.3...91.0.0.2  IKEv1
>           m1:   local:  [91.0.0.3] uses pre-shared key authentication
>           m1:   remote: [91.0.0.2] uses pre-shared key authentication
>           m1:   child:  10.10.9.0/24 192.168.61.0/24 === 192.168.9.0/24 192.168.51.0/24 TUNNEL
> Security Associations (1 up, 0 connecting):
>           m1[6]: ESTABLISHED 13 minutes ago, 91.0.0.3[91.0.0.3]...91.0.0.2[91.0.0.2]
>           m1[6]: IKEv1 SPIs: fc7af259dcba362f_i b5a3f338c097adc2_r*, pre-shared key reauthentication in 45 seconds
>           m1[6]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
>           m1{5}:  REKEYED, TUNNEL, reqid 4, expires in 6 minutes
>           m1{5}:   10.10.9.0/24 === 192.168.9.0/24
>           m1{6}:  REKEYED, TUNNEL, reqid 4, expires in 13 minutes
>           m1{6}:   10.10.9.0/24 === 192.168.9.0/24
>           m1{7}:  INSTALLED, TUNNEL, reqid 4, ESP SPIs: ce0f32d4_i c769cd78_o
>           m1{7}:  AES_CBC_128/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 3 minutes
>           m1{7}:   10.10.9.0/24 === 192.168.9.0/24
> 
> I see packets coming into router2:
> 23:50:15.205527 IP 10.10.9.3 > 192.168.9.3: ICMP echo request, id 1153, seq 1516, length 64 But don't see them routed into the tunnel.
> 
> sh-4.3# ip xfrm policy
> src 10.10.9.0/24 dst 192.168.9.0/24
>         dir out priority 375423 ptype main
>         tmpl src 91.0.0.3 dst 91.0.0.2
>                 proto esp spi 0xc769cd78 reqid 4 mode tunnel src 192.168.9.0/24 dst 10.10.9.0/24
>         dir fwd priority 375423 ptype main
>         tmpl src 91.0.0.2 dst 91.0.0.3
>                 proto esp reqid 4 mode tunnel src 192.168.9.0/24 dst 10.10.9.0/24
>         dir in priority 375423 ptype main
>         tmpl src 91.0.0.2 dst 91.0.0.3
>                 proto esp reqid 4 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0
>         socket in priority 0 ptype main
> src 0.0.0.0/0 dst 0.0.0.0/0
>         socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0
>         socket in priority 0 ptype main
> src 0.0.0.0/0 dst 0.0.0.0/0
>         socket out priority 0 ptype main src ::/0 dst ::/0
>         socket in priority 0 ptype main
> src ::/0 dst ::/0
>         socket out priority 0 ptype main src ::/0 dst ::/0
>         socket in priority 0 ptype main
> src ::/0 dst ::/0
>         socket out priority 0 ptype main
> 
> From the wiki noticed a NAT command:
> iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
> 
> This is not making any difference.
> 
> Any pointers to resolve the issue would be highly appreciated.
> 
> 
> Kind rgds,
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> 5895 Ambler Dr,
> Mississauga, Ontario
> L4W 5B7
> Main Line: +1-844-520-0588 Ext. 129
> Direct Line: +1-289-724-2296
> Cell: +1-226-501-5666
> Fax:+1-289-401-5206
> Email: makarandpradhan at is5com.com
> Website: www.iS5Com.com
> 
>  
> Confidentiality Notice:
> This message is intended only for the named recipients. This message may contain information that is confidential and/or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.
> 

-------------- 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/20200320/6062a10f/attachment-0001.sig>


More information about the Users mailing list