[strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
Makarand Pradhan
MakarandPradhan at is5com.com
Fri Mar 20 18:50:04 CET 2020
Tx for the clarification. All information per the wiki is attached.
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: Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting>
Sent: March 20, 2020 1:21 PM
To: Makarand Pradhan <MakarandPradhan at is5com.com>; users at lists.strongswan.org
Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
Please send all the data I asked for.
And especially the output of `ipsec statusall`.
strongSwan installs all required routes by default.
Am 20.03.20 um 18:17 schrieb Makarand Pradhan:
> One quick question before I send all the logs. Maybe the tunnel is working as expected. Can you pl go through the set up below to confirm that, there is indeed an issue here:
>
> Scenario:
> PC1 - Router1 - Router2 - Tunnel - Router3 - Router4 - PC2
> PC1 IP: 10.10.9.3, Network: 10.10.9.0/24
> PC2 IP: 192.168.9.3, Network: 192.168.9.0/24
> Tunnel: Raptor2(91.0.0.3) to (91.0.0.2)Raptor3 Tunnel is established:
>>> m1[6]: ESTABLISHED 13 minutes ago, 91.0.0.3[91.0.0.3]...91.0.0.2[91.0.0.2]
>>> m1{7}: 10.10.9.0/24 === 192.168.9.0/24
> Routing table on Router 2:
> root at t1024rdb:~# ip ro
> 91.0.0.0/8 dev fm1-mac1.0555 proto kernel scope link src 91.0.0.3
> 192.168.9.0/24 via 91.0.0.2 dev fm1-mac1.0555
>
> With this the packets are encrypted as they pass the tunnel:
> 22:41:05.941919 IP 10.10.9.3 > 192.168.9.3: ICMP echo request, id
> 1278, seq 3, length 64
> 22:41:05.942123 IP 91.0.0.3 > 91.0.0.2: ESP(spi=0xc1442109,seq=0x3),
> length 132
> 22:41:05.943440 IP 91.0.0.2 > 91.0.0.3: ESP(spi=0xc468b8a2,seq=0x3),
> length 132
> 22:41:05.943612 IP 192.168.9.3 > 10.10.9.3: ICMP echo reply, id 1278,
> seq 3, length 64
>
> Question:
> Do I need to have the route "192.168.9.0/24 via 91.0.0.2" when I am running v1?
> With this route, the packets get encrypted.
>
> If this is the desired behaviour then we do not have an issue.
>
> Would appreciate if someone can confirm if v1 needs the route addition. V2 does work without the explicit route addition.
>
> 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: Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting>
> Sent: March 20, 2020 11:23 AM
> To: Makarand Pradhan <MakarandPradhan at is5com.com>;
> users at lists.strongswan.org
> Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
>
> Please provide all information as shown on the HelpRequests[1] page. Then we can go onwards with finding the source of the problem.
>
> Kind regards
>
> Noel
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests
>
> Am 20.03.20 um 16:20 schrieb Makarand Pradhan:
>> Thanks for your response Noel. I cannot go to swanctl so have to continue ipsec.conf for now.
>>
>> I changed the config to single subnet:
>>
>> conn m1
>> type=tunnel
>> authby=secret
>> auto=ignore
>> keyexchange=ikev1
>> ike=aes128-sha-modp1536!
>> aggressive=no
>> ikelifetime=1500s
>> esp=aes128-sha-modp1536!
>> lifetime=1500s
>> right=91.0.0.3
>> rightid=91.0.0.3
>> rightsubnet=10.10.9.0/24
>> left=91.0.0.2
>> leftid=91.0.0.2
>> leftsubnet=192.168.9.0/24
>> leftfirewall=yes
>>
>> Only one subnet. Still the same. Tunnel is up traffic does not go thru unless I add the route. Do I need any iptables configuration to get it to work?
>>
>> 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: Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting>
>> Sent: March 20, 2020 11:15 AM
>> To: Makarand Pradhan <MakarandPradhan at is5com.com>;
>> users at lists.strongswan.org
>> Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.
>>
>> 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: charon_debug.log
Type: application/octet-stream
Size: 16672 bytes
Desc: charon_debug.log
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip_a
Type: application/octet-stream
Size: 1975 bytes
Desc: ip_a
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip_route
Type: application/octet-stream
Size: 2445 bytes
Desc: ip_route
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec.conf
Type: application/octet-stream
Size: 384 bytes
Desc: ipsec.conf
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec_statusall
Type: application/octet-stream
Size: 1454 bytes
Desc: ipsec_statusall
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0011.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec_up
Type: application/octet-stream
Size: 1789 bytes
Desc: ipsec_up
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iptables-save
Type: application/octet-stream
Size: 921 bytes
Desc: iptables-save
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200320/4dae8023/attachment-0013.obj>
More information about the Users
mailing list