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: [email protected]
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 <[email protected]> 
Sent: March 20, 2020 1:21 PM
To: Makarand Pradhan <[email protected]>; [email protected]
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@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: [email protected]
> 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 <[email protected]>
> Sent: March 20, 2020 11:23 AM
> To: Makarand Pradhan <[email protected]>; 
> [email protected]
> 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: [email protected]
>> 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 <[email protected]>
>> Sent: March 20, 2020 11:15 AM
>> To: Makarand Pradhan <[email protected]>; 
>> [email protected]
>> 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: [email protected]
>>> 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 <[email protected]> On Behalf Of 
>>> Makarand Pradhan
>>> Sent: March 19, 2020 4:07 PM
>>> To: [email protected]
>>> 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: [email protected]
>>> 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 <[email protected]> On Behalf Of 
>>> Makarand Pradhan
>>> Sent: March 19, 2020 2:28 PM
>>> To: [email protected]
>>> 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: [email protected]
>>> 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.
>>>
>>
> 

Attachment: charon_debug.log
Description: charon_debug.log

Attachment: ip_a
Description: ip_a

Attachment: ip_route
Description: ip_route

Attachment: ipsec.conf
Description: ipsec.conf

Attachment: ipsec_statusall
Description: ipsec_statusall

Attachment: ipsec_up
Description: ipsec_up

Attachment: iptables-save
Description: iptables-save

Reply via email to