Re: [strongSwan] Multiple SAs after rekey with traffic.

[Makarand Pradhan]

GM Rajiv,

Appreciate your suggestions. Will test for 24 hours and get back.

With regards,
Makarand.

From: Rajiv Kulkarni 
Sent: May 25, 2022 3:35 PM
To: Makarand Pradhan 
Cc: Users@lists.strongswan.org
Subject: Re: [strongSwan] Multiple SAs after rekey with traffic.

Hi

1. why have you changed/set the "rekeyfuzz=0%" - i suggest that you should NOT 
change any of the "default/pre-defined" settings that are used in the 
Expry-Rekeying formulae such as "rekeyfuzz" which i believe is 100% as default 
value.

2. so except for "margintime" (which is correctly set to 1m in your case becos 
you have reduces lifetimes for both ChildSA and also the IKE-SAs), dont change 
any of the default settings...especially in the "../strongswan.d/charon.conf" 
filekeep them as is...

3. Since you are using IKEv2.please use the option "reauth=no"strongly 
suggested for all IKEv2 based tunnels



regards
Rajiv






On Wed, May 18, 2022 at 6:53 PM Makarand Pradhan 
mailto:makarandprad...@is5com.com>> wrote:
GM All,

A quick update on the issue.

I upgraded to 5.9.6 and things have improved a lot. The issue has not been 
resolved completely but charon is now not hogging the CPU as much.

After a 24 hour traffic run, I still see multiple IKE and IPSec SAs created. 
All the same, not as many as I was noticing in 5.9.5.

I started with 50 SAs. Now after 24 hours, I have 146.

Routed Connections:
 policy2{6}:  ROUTED, TUNNEL, reqid 2
 policy2{6}:   10.10.102.0/24<http://10.10.102.0/24> === 
192.168.102.0/24<http://192.168.102.0/24>
Security Associations (146 up, 0 connecting):

Traffic is flowing, but CPU usage is way up.

Would highly appreciate if anyone can suggest if I have missed a config in 
charon.conf. Have tried but am not seeing any improvement.

Hoping to hear comments/suggestions on the issue.

Thanks and Regards,
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: makarandprad...@is5com.com<mailto:makarandprad...@is5com.com>
Website: www.iS5Com.com<http://www.iS5Com.com>

-Original Message-----
From: Users 
mailto:users-boun...@lists.strongswan.org>> 
On Behalf Of Makarand Pradhan
Sent: May 16, 2022 11:37 AM
To: Users@lists.strongswan.org<mailto:Users@lists.strongswan.org>
Subject: [strongSwan] Multiple SAs after rekey with traffic.

Good morning All,

I am facing an issue where the number of SAs keep on going up and then charon 
starts hogging the CPU. Will highly appreciate if anyone comment if I have 
misconfigured some parameter or if this is a known issue? Details below:

We are running Strongswan 5.9.5 on ppc64, Linux kernel 4.1.35.

It is noted that after a rekey timeout, a new SA is 
created(ESTABLISHED/INSTALLED). This happens only with traffic. Over a period 
of time, the number of SAs keep on increasing and then charon hogs the CPU.

Please find below the ipsec.conf that is being used and a log of my session 
showing the increasing number of SAs.

ipsec.conf

sh-4.3# cat /usr/local/etc/ipsec.conf
config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

#IS5#
conn policy1
type=tunnel
authby=secret
auto=route
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=40m
esp=aes256-sha256-modp2048!
lifetime=20m
right=172.16.100.101
rightid=172.16.100.101
rightsubnet=10.10.101.0/24<http://10.10.101.0/24>
left=172.16.100.1
leftid=172.16.100.1
leftsubnet=192.168.101.0/24<http://192.168.101.0/24>
dpddelay=60s
mobike=no
dpdaction=clear
margintime=1m
rekeyfuzz=0%
leftcert=


e.g. Tunnel is set up:

sh-4.3# date
Mon May 16 09:15:33 UTC 2022
sh-4.3# ipsec status policy1
Routed Connections:
 policy1{1}:  ROUTED, TUNNEL, reqid 1
 policy1{1}:   192.168.101.0/24<http://192.168.101.0/24> === 
10.10.101.0/24<http://10.10.101.0/24>
Security Associations (1 up, 0 connecting):
 policy1[1]: ESTABLISHED 22 seconds ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4ee192d_i c18d1d43_o
 policy1{2}:   192.168.101.0/24<http://192.168.101.0/24> === 
10.10.101.0/24<http://10.10.101.0/24>

After some time:


sh-4.3# ipsec statusall policy1
Status of IKE charon daemon (weakSwan 5.9.5, Linux 4.1.35-rt41, ppc64):
  uptime: 77 minutes, since May 16 09:15:14 2022
  malloc: sbrk 2400256, mmap 0, used 354336, free 2045920
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 6
  loaded plugins: charon aes des blowfish rc2 sha2 sha1 md5 mgf1 random 

Re: [strongSwan] Multiple SAs after rekey with traffic.

[Makarand Pradhan]

GM All,

A quick update on the issue.

I upgraded to 5.9.6 and things have improved a lot. The issue has not been 
resolved completely but charon is now not hogging the CPU as much.

After a 24 hour traffic run, I still see multiple IKE and IPSec SAs created. 
All the same, not as many as I was noticing in 5.9.5.

I started with 50 SAs. Now after 24 hours, I have 146.

Routed Connections:
 policy2{6}:  ROUTED, TUNNEL, reqid 2
 policy2{6}:   10.10.102.0/24 === 192.168.102.0/24
Security Associations (146 up, 0 connecting):

Traffic is flowing, but CPU usage is way up.

Would highly appreciate if anyone can suggest if I have missed a config in 
charon.conf. Have tried but am not seeing any improvement.

Hoping to hear comments/suggestions on the issue.

Thanks and Regards,
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: makarandprad...@is5com.com
Website: www.iS5Com.com

-Original Message-
From: Users  On Behalf Of Makarand Pradhan
Sent: May 16, 2022 11:37 AM
To: Users@lists.strongswan.org
Subject: [strongSwan] Multiple SAs after rekey with traffic.

Good morning All,

I am facing an issue where the number of SAs keep on going up and then charon 
starts hogging the CPU. Will highly appreciate if anyone comment if I have 
misconfigured some parameter or if this is a known issue? Details below:

We are running Strongswan 5.9.5 on ppc64, Linux kernel 4.1.35.

It is noted that after a rekey timeout, a new SA is 
created(ESTABLISHED/INSTALLED). This happens only with traffic. Over a period 
of time, the number of SAs keep on increasing and then charon hogs the CPU.

Please find below the ipsec.conf that is being used and a log of my session 
showing the increasing number of SAs.

ipsec.conf

sh-4.3# cat /usr/local/etc/ipsec.conf
config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

#IS5#
conn policy1
type=tunnel
authby=secret
auto=route
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=40m
esp=aes256-sha256-modp2048!
lifetime=20m
right=172.16.100.101
rightid=172.16.100.101
rightsubnet=10.10.101.0/24
left=172.16.100.1
leftid=172.16.100.1
leftsubnet=192.168.101.0/24
dpddelay=60s
mobike=no
dpdaction=clear
margintime=1m
rekeyfuzz=0%
leftcert=


e.g. Tunnel is set up:

sh-4.3# date
Mon May 16 09:15:33 UTC 2022
sh-4.3# ipsec status policy1
Routed Connections:
 policy1{1}:  ROUTED, TUNNEL, reqid 1
 policy1{1}:   192.168.101.0/24 === 10.10.101.0/24
Security Associations (1 up, 0 connecting):
 policy1[1]: ESTABLISHED 22 seconds ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4ee192d_i c18d1d43_o
 policy1{2}:   192.168.101.0/24 === 10.10.101.0/24

After some time:


sh-4.3# ipsec statusall policy1
Status of IKE charon daemon (weakSwan 5.9.5, Linux 4.1.35-rt41, ppc64):
  uptime: 77 minutes, since May 16 09:15:14 2022
  malloc: sbrk 2400256, mmap 0, used 354336, free 2045920
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 6
  loaded plugins: charon aes des blowfish 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 farp stroke vici updown xauth-generic counters Listening IP 
addresses:
  10.10.5.1
  192.168.101.11
  192.168.10.1
  192.168.50.2
  172.16.100.1
Connections:
 policy1:  172.16.100.1...172.16.100.101  IKEv2, dpddelay=60s
 policy1:   local:  [172.16.100.1] uses pre-shared key authentication
 policy1:   remote: [172.16.100.101] uses pre-shared key authentication
 policy1:   child:  192.168.101.0/24 === 10.10.101.0/24 TUNNEL, 
dpdaction=clear
Routed Connections:
 policy1{1}:  ROUTED, TUNNEL, reqid 1
 policy1{1}:   192.168.101.0/24 === 10.10.101.0/24
Security Associations (2 up, 0 connecting):
 policy1[2]: ESTABLISHED 38 minutes ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1[2]: IKEv2 SPIs: 518b7019c5d03118_i* 74fe5d2949eaed95_r, pre-shared 
key reauthentication in 17 seconds
 policy1[2]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
 policy1{13}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c9bab39c_i ca96f84a_o
 policy1{13}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 0 
bytes_o, rekeying in 18 minutes
 policy1{13}:   192.168.101.0/24 === 10.10.101.0/24
 policy1[3]: ESTABLISHED 38 minutes ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1[3]: IKEv2 SPIs

[strongSwan] Multiple SAs after rekey with traffic.

[Makarand Pradhan]

Good morning All,

I am facing an issue where the number of SAs keep on going up and then charon 
starts hogging the CPU. Will highly appreciate if anyone comment if I have 
misconfigured some parameter or if this is a known issue? Details below:

We are running Strongswan 5.9.5 on ppc64, Linux kernel 4.1.35.

It is noted that after a rekey timeout, a new SA is 
created(ESTABLISHED/INSTALLED). This happens only with traffic. Over a period 
of time, the number of SAs keep on increasing and then charon hogs the CPU.

Please find below the ipsec.conf that is being used and a log of my session 
showing the increasing number of SAs.

ipsec.conf

sh-4.3# cat /usr/local/etc/ipsec.conf
config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

#IS5#
conn policy1
type=tunnel
authby=secret
auto=route
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=40m
esp=aes256-sha256-modp2048!
lifetime=20m
right=172.16.100.101
rightid=172.16.100.101
rightsubnet=10.10.101.0/24
left=172.16.100.1
leftid=172.16.100.1
leftsubnet=192.168.101.0/24
dpddelay=60s
mobike=no
dpdaction=clear
margintime=1m
rekeyfuzz=0%
leftcert=


e.g. Tunnel is set up:

sh-4.3# date
Mon May 16 09:15:33 UTC 2022
sh-4.3# ipsec status policy1
Routed Connections:
 policy1{1}:  ROUTED, TUNNEL, reqid 1
 policy1{1}:   192.168.101.0/24 === 10.10.101.0/24
Security Associations (1 up, 0 connecting):
 policy1[1]: ESTABLISHED 22 seconds ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4ee192d_i c18d1d43_o
 policy1{2}:   192.168.101.0/24 === 10.10.101.0/24

After some time:


sh-4.3# ipsec statusall policy1
Status of IKE charon daemon (weakSwan 5.9.5, Linux 4.1.35-rt41, ppc64):
  uptime: 77 minutes, since May 16 09:15:14 2022
  malloc: sbrk 2400256, mmap 0, used 354336, free 2045920
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 6
  loaded plugins: charon aes des blowfish 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 farp stroke vici updown xauth-generic counters
Listening IP addresses:
  10.10.5.1
  192.168.101.11
  192.168.10.1
  192.168.50.2
  172.16.100.1
Connections:
 policy1:  172.16.100.1...172.16.100.101  IKEv2, dpddelay=60s
 policy1:   local:  [172.16.100.1] uses pre-shared key authentication
 policy1:   remote: [172.16.100.101] uses pre-shared key authentication
 policy1:   child:  192.168.101.0/24 === 10.10.101.0/24 TUNNEL, 
dpdaction=clear
Routed Connections:
 policy1{1}:  ROUTED, TUNNEL, reqid 1
 policy1{1}:   192.168.101.0/24 === 10.10.101.0/24
Security Associations (2 up, 0 connecting):
 policy1[2]: ESTABLISHED 38 minutes ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1[2]: IKEv2 SPIs: 518b7019c5d03118_i* 74fe5d2949eaed95_r, pre-shared 
key reauthentication in 17 seconds
 policy1[2]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
 policy1{13}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c9bab39c_i ca96f84a_o
 policy1{13}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 0 
bytes_o, rekeying in 18 minutes
 policy1{13}:   192.168.101.0/24 === 10.10.101.0/24
 policy1[3]: ESTABLISHED 38 minutes ago, 
172.16.100.1[172.16.100.1]...172.16.100.101[172.16.100.101]
 policy1[3]: IKEv2 SPIs: 005c2ec500a6a55d_i c00aead9fa60759a_r*, pre-shared 
key reauthentication in 17 seconds
 policy1[3]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
 policy1{12}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5fabaf0_i c5dad3ed_o
 policy1{12}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 0 
bytes_o, rekeying in 18 minutes
 policy1{12}:   192.168.101.0/24 === 10.10.101.0/24

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: makarandprad...@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

[strongSwan] GRE Strongswan Question

[Makarand Pradhan]

Hello Everyone,

This email is regarding GRE over IPSec. I'm observing some interesting 
behaviour which I am not able to understand. Would highly appreciate your views.

Issue:
GRE over IPSec works in tunnel mode when I use raspberry Pis as end devices.
Pi on LAN<--> R1 Router running strongswan <-Internet--> R2 Router running 
strongswan <--> Pi on LAN

When I try to use Spirent ports instead of Pis, only transport mode works. 
Tunnel mode does not push GRE packets into IPSec tunnel.

Question:
Can anyone give a hint as to why tunnel mode would work when the end points are 
Pis?
Or Why Spirent traffic only supports transport?

The relevant configuration is given below

Linux strongSwan U5.8.2/K4.1.35-rt41

R1:
Ipsec.conf
right=172.16.100.101
rightid=172.16.100.101
rightsubnet=172.16.100.101/32[gre]
left=172.16.100.1
leftid=172.16.100.1
leftsubnet=172.16.100.1/32[gre]

ip a s tunnel1
19: tunnel1@NONE:  mtu 1476 qdisc noqueue state 
UNKNOWN group default
link/gre 172.16.100.1 peer 172.16.100.101
inet 10.10.1.1/24 scope global tunnel1
   valid_lft forever preferred_lft forever

R2:
Ipsec.conf
right=172.16.100.1
rightid=172.16.100.1
rightsubnet=172.16.100.1/32[gre]
left=172.16.100.101
leftid=172.16.100.101
leftsubnet=172.16.100.101/32[gre]

ip a s tunnel1
19: tunnel1@NONE:  mtu 1476 qdisc noqueue state 
UNKNOWN group default
link/gre 172.16.100.101 peer 172.16.100.1
inet 10.10.1.2/24 scope global tunnel1
   valid_lft forever preferred_lft forever


Thanks.

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: makarandprad...@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.

Re: [strongSwan] Subnet selector question

[Makarand Pradhan]

A quick update.

I installed the farp plugin and now the arp is getting resolved. But still 
packets are not being pushed into the tunnel when I specify the icmp filter.

Pl find below the logs:
sh-4.3# ipsec statusall m1
Status of IKE charon daemon (weakSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
  uptime: 11 minutes, since Jan 29 06:17:58 2021
  malloc: sbrk 2297856, mmap 0, used 307440, free 1990416
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 4
  loaded plugins: charon aes des blowfish 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 farp stroke vici updown xauth-generic counters
Listening IP addresses:
  192.168.61.2
  192.168.62.2
  172.16.31.2
  172.16.32.2
  10.10.9.1
Connections:
  m1:  172.16.31.2...172.16.31.1  IKEv2, dpddelay=60s
  m1:   local:  [172.16.31.2] uses pre-shared key authentication
  m1:   remote: [172.16.31.1] uses pre-shared key authentication
  m1:   child:  10.10.9.0/24[icmp] 192.168.61.0/24 === 
192.168.9.0/24[icmp] 192.168.51.0/24 TUNNEL, dpdaction=clear
Routed Connections:
  m1{1}:  ROUTED, TUNNEL, reqid 1
  m1{1}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 11 minutes ago, 
172.16.31.2[172.16.31.2]...172.16.31.1[172.16.31.1]
  m1[1]: IKEv2 SPIs: 766231c8253bf352_i* 6be8de67ab04169d_r, pre-shared 
key reauthentication in 46 minutes
  m1[1]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  m1{3}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb85fce1_i c83b5361_o
  m1{3}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying 
in 107 minutes
  m1{3}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24

06:30:48.324650 IP 10.10.9.32 > 192.168.9.31: ICMP echo request, id 4637, seq 
318, length 64
06:30:49.364648 IP 10.10.9.32 > 192.168.9.31: ICMP echo request, id 4637, seq 
319, length 64
06:30:50.404673 IP 10.10.9.32 > 192.168.9.31: ICMP echo request, id 4637, seq 
320, length 64
06:30:51.444627 IP 10.10.9.32 > 192.168.9.31: ICMP echo request, id 4637, seq 
321, length 64

No ESP for src 10.10.9.32 to 192.168.9.31 ICMP.

Ip xfrm seems to be ok:

src 10.10.9.0/24 dst 192.168.9.0/24 proto icmp
dir out priority 375167 ptype main
tmpl src 172.16.31.2 dst 172.16.31.1
proto esp spi 0xc83b5361 reqid 1 mode tunnel


Scenario 2: Permit ssh traffic on port 22.
Ipsec.conf:
rightsubnet=192.168.9.0/24[/22],192.168.51.0/24
leftsubnet=10.10.9.0/24,192.168.61.0/24

Also, I see the same problem. ARP is resolved but packets are not pushed into 
the tunnel.

06:39:21.636521 ARP, Request who-has 192.168.9.31 (Broadcast) tell 
192.168.61.1, length 46
06:39:21.637023 ARP, Reply 192.168.9.31 is-at e8:e8:75:90:3f:80 (oui Unknown), 
length 28
06:39:21.639116 IP 10.10.9.32.50550 > 192.168.9.31.ssh: Flags [S], seq 
3400545033, win 64240, options [mss 1460,sackOK,TS val 2883004940 ecr 
0,nop,wscale 7], length 0
06:39:34.712713 LLDP, length 121: iS5com
06:39:34.908298 IP 172.16.31.1.isakmp > 172.16.31.2.isakmp: isakmp: parent_sa 
inf2

Was wondering if the filtering functionality is broken?

I'm running 5.8.2. Will upgrading to 5.9.1 fix this?

Any opinions would be appreciated.

Thanks.
Makarand.

-Original Message-
From: Users  On Behalf Of Makarand Pradhan
Sent: January 28, 2021 12:33 PM
To: users@lists.strongswan.org
Subject: [strongSwan] Subnet selector question

GM Everyone,

Am trying to selectively push icmp traffic into the tunnel. Am missing 
something, would appreciate any pointers.

Scenario:
(PC1 10.10.9.31/24) <---> 10.10.9.1 Router 172.16.31.1 <-Tunnel-> 172.16.31.2 
Router 192.168.9.1 <---> (192.168.9.31 PC 2)

Ipsec.conf: I'm permitting only icmp in []
rightsubnet=192.168.9.0/24[icmp],192.168.51.0/24
leftsubnet=10.10.9.0/24[icmp],192.168.61.0/24

Issue: Ping fails.

Tunnel status:
sh-4.3# ipsec status
Routed Connections:
  m1{1}:  ROUTED, TUNNEL, reqid 1
  m1{1}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 3 seconds ago, 
172.16.31.2[172.16.31.2]...172.16.31.1[172.16.31.1]
  m1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7b29cc2_i ca9ed38c_o
  m1{2}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24

I notice that the ARP request is not answered.

When I do not specify icmp, everything works. I think strongswan responds to 
the ARP. Don't see it with icmp filter.

Thanks for looking.

Kind rgds,
Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
5895 Ambler Dr,
Missis

[strongSwan] Subnet selector question

[Makarand Pradhan]

GM Everyone,

Am trying to selectively push icmp traffic into the tunnel. Am missing 
something, would appreciate any pointers.

Scenario:
(PC1 10.10.9.31/24) <---> 10.10.9.1 Router 172.16.31.1 <-Tunnel-> 172.16.31.2 
Router 192.168.9.1 <---> (192.168.9.31 PC 2)

Ipsec.conf: I'm permitting only icmp in []
rightsubnet=192.168.9.0/24[icmp],192.168.51.0/24
leftsubnet=10.10.9.0/24[icmp],192.168.61.0/24

Issue: Ping fails.

Tunnel status:
sh-4.3# ipsec status
Routed Connections:
  m1{1}:  ROUTED, TUNNEL, reqid 1
  m1{1}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 3 seconds ago, 
172.16.31.2[172.16.31.2]...172.16.31.1[172.16.31.1]
  m1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7b29cc2_i ca9ed38c_o
  m1{2}:   10.10.9.0/24[icmp] 192.168.61.0/24 === 192.168.9.0/24[icmp] 
192.168.51.0/24

I notice that the ARP request is not answered.

When I do not specify icmp, everything works. I think strongswan responds to 
the ARP. Don't see it with icmp filter.

Thanks for looking.

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: makarandprad...@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.

Re: [strongSwan] Windows VPN client issue with Strongswan

[Makarand Pradhan]

Thanks Tobias for responding.

There is no firewall.

Windows has not yet sent an IKE_AUTH.
Windows sends an IKE_SA_INIT.
Strongswan sends a CA CERT REQ. I think it's going to windows. The CA cert is 
installed on windows Trusted folder.
On windows I see a msg saying "Ask your admin to config certificates properly."

I think, I'm messing up with certificates somehow. I've created a CA and signed 
the certificates using this CA on the Strongswan server. 
The CA cert and the Win Cert with it's private key is installed on windows.
The CA cert and Server cert is installed in ipsec.d/cacert, ipsec.d/cert and 
the server private key is installed in ipsec.d/private

Will recheck and get back.

Thanks again.
Makarand.


-Original Message-
From: Tobias Brunner  
Sent: October 12, 2020 10:59 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] Windows VPN client issue with Strongswan

Hi Makarand,

> 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) 
> N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ] 06[NET] 
> sending packet: from 10.10.5.1[500] to 10.10.5.7[500] (353 bytes) 
> 15[JOB] deleting half open IKE_SA with 10.10.5.7 after timeout

This could indicate an IP fragmentation issue (IKE_AUTH too large with 
certificate and certificate requests, fragments dropped).  But since both peers 
support IKEv2 fragmentation (FRAG_SUP) that seems unlikely.

While there is no NAT between the hosts, with MOBIKE there will still be a 
switch to UDP port 4500, so make sure no firewall blocks that port.

What error is the client reporting exactly?  Does it actually send an IKE_AUTH 
request?

> I was expecting a windows cert request. Instead I see a CA Cert req.

The request is for certificates issued by that CA.

Regards,
Tobias

[strongSwan] Windows VPN client issue with Strongswan

[Makarand Pradhan]

Hello All,

I am having trouble while connecting a Windows VPN client to Strongswan using 
Machine certificates. I am following the wiki:
https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients
Would appreciate any pointers to resolve the issue.

Issue: Windows client is not connecting 

As per wiki, have created CA and signed the Strongswan server and Windows 
client req.
The certificates and private keys are kept at proper locations as specified.
update-ca-certificates is done to update the trusted certificates on the linux 
machine running strongswan server.

On the windows side, both CA certificate and windows client certificate is 
imported. Both the certificate shows "This certificateis ok"

When the client initiates connection, I see strongswan sending a cert request 
for the CA certificate.
The CA, server and client are as follows:
CA:  "C=CA, ST=ON, L=Miss, O=iS5, OU=SW, CN=ca@10.10.5.1, E=c...@is5com.com"
Strongswan server: "C=CA, ST=ON, L=Miss, O=iS5, OU=SW, CN=server@10.10.5.1, 
E=ser...@is5com.com"
Win client: "C=CA, ST=ON, L=Miss, O=iS5, OU=SW, CN=win@10.10.5.7, 
E=s...@is5com.com"

swanctl --log
06[NET] received packet: from 10.10.5.7[500] to 10.10.5.1[500] (624 bytes)
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) 
N(NATD_D_IP) V V V V ]
06[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
06[IKE] received MS-Negotiation Discovery Capable vendor ID
06[IKE] received Vid-Initial-Contact vendor ID
06[ENC] received unknown vendor ID: 
01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
06[IKE] 10.10.5.7 is initiating an IKE_SA
06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
06[IKE] sending cert request for "C=CA, ST=ON, L=Miss, O=iS5, OU=SW, 
CN=10.10.5.1, E=c...@is5com.com"
06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
06[NET] sending packet: from 10.10.5.1[500] to 10.10.5.7[500] (353 bytes)
15[JOB] deleting half open IKE_SA with 10.10.5.7 after timeout

I was expecting a windows cert request. Instead I see a CA Cert req. Am I 
missing anything?

Thanks.
Makarand.

Re: [strongSwan] aesxcbc did not work for ph2 but worked for ph1

[Makarand Pradhan]

Thanks Tobias for your response.

I recompiled the kernel with:

+CONFIG_CRYPTO_XCBC=y

And it worked for me.

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: makarandprad...@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: Tobias Brunner  
Sent: September 4, 2020 4:27 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] aesxcbc did not work for ph2 but worked for ph1

Hi Makarand,

> It works when I use it with IKE but throws a netlink error while trying to 
> use with ESP. 

Obviously, your kernel does not support the algorithm.

Regards,
Tobias

[strongSwan] aesxcbc did not work for ph2 but worked for ph1

[Makarand Pradhan]

Good morning All,

I am trying to use aesxcbc for integrity. It works when I use it with IKE but 
throws a netlink error while trying to use with ESP. 

Strongswan is compiled with --enable-xcbc.

Would highly appreciate any suggestions to resolve the problem. Tx.

Logs below:

My ipsec.conf is given below:

ike=aes256-aesxcbc-modp1536!
esp=aes256-aesxcbc-modp2048!

AESXBC is listed in Integrity algos:
root@t1024rdb:~# swanctl --list-algs
encryption:
  AES_CBC[aes]
  AES_ECB[aes]
  3DES_CBC[des]
  DES_CBC[des]
  DES_ECB[des]
  BLOWFISH_CBC[blowfish]
  RC2_CBC[rc2]
integrity:
  AES_XCBC_96[xcbc]
  AES_CMAC_96[cmac]
  HMAC_SHA1_96[hmac]
  HMAC_SHA1_128[hmac]
  HMAC_SHA1_160[hmac]
  HMAC_MD5_96[hmac]
  HMAC_MD5_128[hmac]
  HMAC_SHA2_256_128[hmac]
  HMAC_SHA2_256_256[hmac]
  HMAC_SHA2_384_192[hmac]
  HMAC_SHA2_384_384[hmac]
  HMAC_SHA2_512_256[hmac]
  HMAC_SHA2_512_512[hmac]
aead:
hasher:
  HASH_SHA1[sha1]
  HASH_SHA2_224[sha2]
  HASH_SHA2_256[sha2]
  HASH_SHA2_384[sha2]
  HASH_SHA2_512[sha2]
  HASH_MD5[md5]
  HASH_IDENTITY[curve25519]

SA Established:
root@t1024rdb:~# ipsec statusall m1
Status of IKE charon daemon (weakSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
  uptime: 9 seconds, since Nov 05 21:27:35 2018
  malloc: sbrk 2027520, mmap 0, used 288528, free 1738992
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 6
  loaded plugins: charon aes des blowfish 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.1
  192.168.51.2
  192.168.52.2
  172.16.31.1
  172.16.32.1
Connections:
  m1:  172.16.31.1...172.16.31.2  IKEv2, dpddelay=60s
  m1:   local:  [172.16.31.1] uses pre-shared key authentication
  m1:   remote: [172.16.31.2] uses pre-shared key authentication
  m1:   child:  192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 
192.168.61.0/24 TUNNEL, dpdaction=clear
Routed Connections:
  m1{1}:  ROUTED, TUNNEL, reqid 1
  m1{1}:   192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 
192.168.61.0/24
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 7 seconds ago, 
172.16.31.1[172.16.31.1]...172.16.31.2[172.16.31.2]
  m1[1]: IKEv2 SPIs: eca1d32c9e634128_i* b1157e6f487ea502_r, pre-shared 
key reauthentication in 39 minutes
  m1[1]: IKE proposal: AES_CBC_256/AES_XCBC_96/PRF_AES128_XCBC/MODP_1536
root@t1024rdb:~#


CHILD-SA fails:

11[IKE] 172.16.31.1 is initiating an IKE_SA
11[CFG] selected proposal: IKE:AES_CBC_256/AES_XCBC_96/PRF_AES128_XCBC/MODP_1536
11[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
11[NET] sending packet: from 172.16.31.2[500] to 172.16.31.1[500] (408 bytes)
13[NET] received packet: from 172.16.31.1[500] to 172.16.31.2[500] (268 bytes)
13[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
13[CFG] looking for peer configs matching 
172.16.31.2[172.16.31.2]...172.16.31.1[172.16.31.1]
13[CFG] selected peer config 'm1'
13[IKE] authentication of '172.16.31.1' with pre-shared key successful
13[IKE] authentication of '172.16.31.2' (myself) with pre-shared key
13[IKE] IKE_SA m1[1] established between 
172.16.31.2[172.16.31.2]...172.16.31.1[172.16.31.1]
13[IKE] scheduling reauthentication in 2921s
13[IKE] maximum IKE_SA lifetime 3461s
13[CFG] selected proposal: ESP:AES_CBC_256/AES_XCBC_96/NO_EXT_SEQ
13[KNL] received netlink error: Function not implemented (38)
13[KNL] unable to add SAD entry with SPI cadbb51e (FAILED)
13[KNL] received netlink error: Function not implemented (38)
13[KNL] unable to add SAD entry with SPI c05ee772 (FAILED)
13[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel
13[IKE] failed to establish CHILD_SA, keeping IKE_SA



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: makarandprad...@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.

[strongSwan] Restricting protocol and port numbers question

[Makarand Pradhan]

Hello All,

I am trying to restrict traffic entering the tunnel using:

left|rightsubnet = [[]][,...]

To test this feature I am trying to restrict ICMP traffic.

ipsec.conf:
rightsubnet=192.168.9.0/24[icmp],192.168.51.0/24[icmp]
left=172.16.31.2
leftid=172.16.31.2
leftsubnet=10.10.9.0/24[icmp],192.168.61.0/24[icmp]

The tunnels come up and look ok:
  m1{3}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c988747b_i c0147d49_o
  m1{3}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying 
in 96 minutes
  m1{3}:   10.10.9.0/24[icmp] 192.168.61.0/24[icmp] === 
192.168.9.0/24[icmp] 192.168.51.0/24[icmp]

All the same, the packets are not pushed into the tunnel:

ping 192.168.9.3 -I 10.10.9.4
PING 192.168.9.3 (192.168.9.3) from 10.10.9.4 : 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable

The ip xfrm policy seems to be correct:
src 192.168.9.0/24 dst 10.10.9.0/24 proto icmp 
dir fwd priority 375167 ptype main 
tmpl src 172.16.31.1 dst 172.16.31.2
proto esp reqid 1 mode tunnel

Would highly appreciate if anyone can point the error in my configuration?

Thanks.

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: makarandprad...@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.

Re: [strongSwan] Blowfish not working for IKE, but works for CHILD_SA (Linux strongSwan U5.8.2/K4.1.35-rt41)

[Makarand Pradhan]

Thanks Tobias.

I configured with --enable-blowfish and it worked for me. I can now see 
BLOWFISH_CBC in encryptions and ike can use blowfish.

sh-4.3# swanctl --list-algs
encryption:
  AES_CBC[aes]
  AES_ECB[aes]
  3DES_CBC[des]
  DES_CBC[des]
  DES_ECB[des]
  BLOWFISH_CBC[blowfish]

Tunnel status: 
...
  m1[18]: IKEv2 SPIs: 1b652ce7683f67fa_i 269af6263b48d37e_r*, 
pre-shared key reauthentication in 45 minutes
  m1[18]: IKE proposal: 
BLOWFISH_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536

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: makarandprad...@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: Tobias Brunner  
Sent: August 26, 2020 4:04 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] Blowfish not working for IKE, but works for CHILD_SA 
(Linux strongSwan U5.8.2/K4.1.35-rt41)

Hi Makarand,

> Log:
> root@t1024rdb:~# swanctl --list-algs

As you can see in this list, there is no plugin that provides the BLOWFISH_CBC 
algorithm.  There are three plugins that can provide it, blowfish (obviously), 
gcrypt and openssl.  The latter two only if the underlying library was built 
with that algorithm.  So make sure you enable/build the plugins/library you 
need if you want to use that algorithm.

Regards,
Tobias

Re: [strongSwan] Multiple CHILD_SA's after reauth timer expires

[Makarand Pradhan]

Thanks Tobias for your quick response.

Am trying the make-before-break approach and so far the results are good. Will 
run traffic for some more time to confirm the resolution.

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: makarandprad...@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: Tobias Brunner  
Sent: August 18, 2020 11:47 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] Multiple CHILD_SA's after reauth timer expires

Hi Makarand,

> Any opinions on how to avoid the multiple CHILD_SAs after reauth?

Don't use reauth (use rekeying) or use make-before-break reauth, see [1] for 
details (where this issue with trap policies is also mentioned).

Regards,
Tobias

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey#IKE

[strongSwan] Multiple CHILD_SA's after reauth timer expires

[Makarand Pradhan]

Good morning All,

We are noticing that every time after the reauth timer expires a new CHILD_SA 
gets created. 

Ipsec.conf: auto is set to route on both sides.

config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

#IS5#
conn m1
type=tunnel
authby=secret
auto=route
keyexchange=ikev2

sh-4.3# ipsec statusall m1
Status of IKE charon daemon (weakSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
  uptime: 26 minutes, since Aug 18 14:53:17 2020
  malloc: sbrk 2617344, mmap 0, used 1037312, free 1580032
  worker threads: 10 of 16 idle, 5/0/1/0 working, job queue: 0/0/0/0, 
scheduled: 2861
  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:
...
  172.16.100.50
Connections:
  m1:  172.16.100.1...172.17.100.101  IKEv2, dpddelay=60s
  m1:   local:  [172.16.100.1] uses pre-shared key authentication
  m1:   remote: [172.17.100.101] uses pre-shared key authentication
  m1:   child:  192.168.101.0/24 192.168.51.0/24 === 10.10.101.0/24 
10.10.51.0/24 TUNNEL, dpdaction=clear
Routed Connections:
  m1{1021}:  ROUTED, TUNNEL, reqid 7
  m1{1021}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
Security Associations (2 up, 0 connecting):
  m1[3046]: ESTABLISHED 0 seconds ago, 
172.16.100.1[172.16.100.1]...172.17.100.101[172.17.100.101]
  m1[3046]: IKEv2 SPIs: 88541fd5830f9b6a_i a695a57e6c7d70b3_r*, 
pre-shared key reauthentication in 6 minutes
  m1[3046]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  m1{3678}:  INSTALLED, TUNNEL, reqid 7, ESP SPIs: ca44d297_i c5962749_o
  m1{3678}:  AES_CBC_256/HMAC_SHA2_256_128, 55120 bytes_i (40 pkts, 0s 
ago), 59254 bytes_o, rekeying in 6 minutes
  m1{3678}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
  m1{3679}:  INSTALLED, TUNNEL, reqid 7, ESP SPIs: c7ca3287_i c2bd2f7e_o
  m1{3679}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 0 
bytes_o, rekeying in 3 minutes
  m1{3679}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
  m1[2639]: ESTABLISHED 2 minutes ago, 
172.16.100.1[172.16.100.1]...172.17.100.101[172.17.100.101]
  m1[2639]: IKEv2 SPIs: acfb6b3d37647cfc_i* 544d8b2e2fce4b97_r, 
pre-shared key reauthentication in 4 minutes
  m1[2639]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  m1{2937}:  INSTALLED, TUNNEL, reqid 7, ESP SPIs: c3396939_i cd534d4a_o
  m1{2937}:  AES_CBC_256/HMAC_SHA2_256_128, 48230 bytes_i (35 pkts, 0s 
ago), 50986 bytes_o, rekeying in 56 seconds
  m1{2937}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
  m1{2938}:  INSTALLED, TUNNEL, reqid 7, ESP SPIs: ce25bc80_i c27e0121_o
  m1{2938}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 11024 bytes_i (8 
pkts, 0s ago), 4134 bytes_o (3 pkts, 0s ago), rekeying in 5 minutes
  m1{2938}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
  m1{3413}:  INSTALLED, TUNNEL, reqid 7, ESP SPIs: ca8c62f6_i c044513d_o
  m1{3413}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 2899312 bytes_i 
(2104 pkts, 0s ago), 4142268 bytes_o (3006 pkts, 0s ago), rekeying in 95 seconds
  m1{3413}:   192.168.51.0/24 192.168.101.0/24 === 10.10.51.0/24 
10.10.101.0/24
sh-4.3#

This issue is not seen when there is no traffic. When there is no traffic, I 
continue to see only one instance of ESTABLISHED and only one instance of 
INSTALLED(CHILD_SA).

Any opinions on how to avoid the multiple CHILD_SAs after reauth?

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: makarandprad...@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.

[strongSwan] Question regarding Drop dead packets

[Makarand Pradhan]

Good morning all,

We are running Strongswan 5.8.2.

Our dpddelay is set at 60 seconds and we have noticed that even though we are 
sending traffic, both ends are sending/receiving ISAKMP (Drop-dead) packets 
every 60 seconds.

The wiki also mentions that R_U_THERE's would go out only in the absence of 
traffic.

"dpddelay = 30s | 

defines the period time interval with which R_U_THERE messages/INFORMATIONAL 
exchanges are sent to the peer.
These are only sent if no other traffic is received."

Can anyone comment if this is the expected behaviour?

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: makarandprad...@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.

Re: [strongSwan] DPD question

[Makarand Pradhan]

Thanks Thomas.

Will use 5. That makes sense.

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: makarandprad...@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: Thomas Egerer  
Sent: August 4, 2020 1:54 PM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] DPD question

On 8/4/20 7:27 PM, Makarand Pradhan wrote:
> Thanks for your response.
>
> I have verified that retransmit_tries = 1 Works for DPD.
It's not advisable to use retransmit_tries = 1 since this causes the SA to be 
torn down after the loss of two packets.

> root@t1024rdb:/usr/local/etc/strongswan.d# swanctl --log 14[IKE] 
> sending DPD request 14[ENC] generating INFORMATIONAL request 2 [ ] 
> 14[NET] sending packet: from 172.16.31.1[500] to 172.16.21.2[500] (76 
> bytes) 07[IKE] retransmit 1 of request with message ID 2 07[NET] 
> sending packet: from 172.16.31.1[500] to 172.16.21.2[500] (76 bytes) 
> 13[IKE] sending DPD request 13[ENC] generating INFORMATIONAL request 2 
> [ ] 13[NET] sending packet: from 172.16.31.100[500] to 
> 172.16.21.100[500] (76 bytes) 08[IKE] giving up after 1 retransmits 
> 11[IKE] retransmit 1 of request with message ID 2 11[NET] sending 
> packet: from 172.16.31.100[500] to 172.16.21.100[500] (76 bytes) 
> 06[IKE] giving up after 1 retransmits
>
> 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: makarandprad...@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: Thomas Egerer 
> Sent: August 4, 2020 12:10 PM
> To: Makarand Pradhan ; 
> users@lists.strongswan.org
> Subject: Re: [strongSwan] DPD question
>
> Hi Makarand,
>
> the retransmit_tries option is exactly what you're looking for. It 
> defaults to five (see [1]). Essentialy charon's task manager tries to 
> retransmit each packet at most five times (if not configured
> otherwise) regardless of the message type. There's no extra option for 
> R-U-There messages or DPD requests.
>
> Thomas
>
> [1] 
> https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf
>
> On 8/4/20 5:33 PM, Makarand Pradhan wrote:
>> Good morning All,
>>
>> Is there a way to configure the number of DPD retries before giving up? We 
>> would like to configure 5 R-U-There failures before taking the connection 
>> down. The retransmit_tries in charon.conf, controls the IKE retransmits. 
>> Don't think it's affecting DPD behaviour.
>>
>> Thanks for looking at my qery.
>>
>> 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: makarandprad...@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.
>>
>

Re: [strongSwan] DPD question

[Makarand Pradhan]

Thanks for your response.

I have verified that retransmit_tries = 1 Works for DPD.

root@t1024rdb:/usr/local/etc/strongswan.d# swanctl --log
14[IKE] sending DPD request
14[ENC] generating INFORMATIONAL request 2 [ ]
14[NET] sending packet: from 172.16.31.1[500] to 172.16.21.2[500] (76 bytes)
07[IKE] retransmit 1 of request with message ID 2
07[NET] sending packet: from 172.16.31.1[500] to 172.16.21.2[500] (76 bytes)
13[IKE] sending DPD request
13[ENC] generating INFORMATIONAL request 2 [ ]
13[NET] sending packet: from 172.16.31.100[500] to 172.16.21.100[500] (76 bytes)
08[IKE] giving up after 1 retransmits
11[IKE] retransmit 1 of request with message ID 2
11[NET] sending packet: from 172.16.31.100[500] to 172.16.21.100[500] (76 bytes)
06[IKE] giving up after 1 retransmits

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: makarandprad...@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: Thomas Egerer  
Sent: August 4, 2020 12:10 PM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] DPD question

Hi Makarand,

the retransmit_tries option is exactly what you're looking for. It defaults to 
five (see [1]). Essentialy charon's task manager tries to retransmit each 
packet at most five times (if not configured
otherwise) regardless of the message type. There's no extra option for 
R-U-There messages or DPD requests.

Thomas

[1] https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf

On 8/4/20 5:33 PM, Makarand Pradhan wrote:
> Good morning All,
>
> Is there a way to configure the number of DPD retries before giving up? We 
> would like to configure 5 R-U-There failures before taking the connection 
> down. The retransmit_tries in charon.conf, controls the IKE retransmits. 
> Don't think it's affecting DPD behaviour.
>
> Thanks for looking at my qery.
>
> 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: makarandprad...@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.
>

[strongSwan] DPD question

[Makarand Pradhan]

Good morning All,

Is there a way to configure the number of DPD retries before giving up? We 
would like to configure 5 R-U-There failures before taking the connection down. 
The retransmit_tries in charon.conf, controls the IKE retransmits. Don't think 
it's affecting DPD behaviour.

Thanks for looking at my qery.

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: makarandprad...@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.

[strongSwan] Multiple SAs on Link up. Race condition.

[Makarand Pradhan]

Hello All,

I'm running strongswan 5.8.2.

I'm noticing multiple SAs and Child SAs set up, when both sides try to initiate 
a connection on link up. Is there a way to avoid multiple SAs  being setup on 
link up?

My configuration is as follows:

Ipsec.conf:
config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

#IS5#
conn m2
type=tunnel
authby=secret
auto=start
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=1h
esp=aes256-sha256-modp2048!
lifetime=2h
right=172.16.32.2
rightid=172.16.32.2
rightsubnet=10.10.10.0/24,192.168.62.0/24
left=172.16.32.1
leftid=172.16.32.1   
leftsubnet=192.168.10.0/24,192.168.52.0/24
mobike=no 

root@t1024rdb:~# ipsec status
Security Associations (3 up, 0 connecting):
  m2[7]: ESTABLISHED 6 minutes ago, 
172.16.32.1[172.16.32.1]...172.16.32.2[172.16.32.2]
  m2{8}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: c7cbf891_i c6e85d39_o
  m2{8}:   192.168.10.0/24 192.168.52.0/24 === 10.10.10.0/24 
192.168.62.0/24
  m2[6]: ESTABLISHED 6 minutes ago, 
172.16.32.1[172.16.32.1]...172.16.32.2[172.16.32.2]
  m2{7}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: c5538838_i c69ab573_o
  m2{7}:   192.168.10.0/24 192.168.52.0/24 === 10.10.10.0/24 
192.168.62.0/24

root@t1024rdb:~# swanctl -l
m2: #7, ESTABLISHED, IKEv2, a5fc0a9cb8a9bfea_i a931c7d404349242_r*
  local  '172.16.32.1' @ 172.16.32.1[500]
  remote '172.16.32.2' @ 172.16.32.2[500]
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  established 362s ago, reauth in 2527s
  m2: #8, reqid 6, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
installed 362s ago, rekeying in 5759s, expires in 6838s
in  c7cbf891,  0 bytes, 0 packets
out c6e85d39,  0 bytes, 0 packets
local  192.168.10.0/24 192.168.52.0/24
remote 10.10.10.0/24 192.168.62.0/24
m2: #6, ESTABLISHED, IKEv2, 2a17575859ea9c0f_i* 9409bec89f7dcff2_r
  local  '172.16.32.1' @ 172.16.32.1[500]
  remote '172.16.32.2' @ 172.16.32.2[500]
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  established 362s ago, reauth in 2101s
  m2: #7, reqid 6, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
installed 362s ago, rekeying in 5847s, expires in 6838s
in  c5538838,  0 bytes, 0 packets
out c69ab573,  0 bytes, 0 packets
local  192.168.10.0/24 192.168.52.0/24
remote 10.10.10.0/24 192.168.62.0/24

Thanks.

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: makarandprad...@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.

[strongSwan] Tunnel and Transport mode mismatch

[Makarand Pradhan]

Hello All,

When one side is set to transport and the other set to Tunnel, the child SA is 
built in Tunnel mode.

Question: Is this the expected behaviour? I was expecting that the SA would be 
Established but the Child SA would not be installed.


Ipsec.conf: 
conn m1
    type=transport
    authby=secret

and the other side set to tunnel:

conn m1
    type=tunnel
    authby=secret


root@t1024rdb:/mnt/shared/b# ipsec status
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 3 seconds ago, 
172.16.31.1[172.16.31.1]...172.16.31.2[172.16.31.2]
  m1{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c22f3cbb_i cfc827a2_o
  m1{1}:   172.16.31.0/24 === 172.16.31.0/24

When both are transport, the child SA is built as transport:

root@t1024rdb:/mnt/shared/b# ipsec status
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 2 seconds ago, 
172.16.31.1[172.16.31.1]...172.16.31.2[172.16.31.2]
  m1{1}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cdd622d2_i cfe1297d_o
  m1{1}:   172.16.31.1/32 === 172.16.31.2/32

Thanks for looking at my post.

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: mailto:makarandprad...@is5com.com
Website: http://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.

[strongSwan] Strongswan Cisco Interop Question (One way traffic)

[Makarand Pradhan]

Good evening all,

I am testing Strongswan <-> Cisco interop on our device. The issue seems to be 
on Cisco side. All the same, would like to ask the question here as someone may 
have faced a similar issue.

Any inputs would be highly appreciated.

Issue: Tunnel is established and child SA is installed. Strongswan is pushing 
packets nicely into the tunnel. The Cisco router al the same is not pushing the 
interesting traffic into tunnel.

Some data points:
Tunnel is up:
root@t1024rdb:/usr/local/etc# ipsec status m1
Security Associations (1 up, 0 connecting):
  m1[1]: ESTABLISHED 3 seconds ago, 
172.16.31.1[172.16.31.1]...172.16.21.1[172.16.21.1]
  m1{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c31e9466_i ca4d6288_o
  m1{1}:   192.168.9.0/24 === 10.10.9.0/24

On CISCO side:
If I use SRC ping, traffic is pushed in tunnel:
Switch#ping  192.168.9.1 source 10.10.9.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.9.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.9.1
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/10 ms
Switch#

Problem: A device on the CISCO side 10.10.9 network cannot reach 192.168.9 
(Strongswan side) nwk. It's GW is Cisco. So when Cisco gets the icmp req:

10.10.10.9.3 -> 192.168.9.3

It arps using for the IP instead of pushing into tunnel.

Have seen a lot of posts with this problem but none of the solution is working 
for me.

If anyone out here has faced this issue, your feedback would be very much 
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: makarandprad...@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.

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

[Makarand Pradhan]

Good morning All,

Following up on the issue. We need to manually add the route for ikev1. 

Would very much appreciate any pointers. Am kind of stuck on ikev1.

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: makarandprad...@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: Makarand Pradhan 
Sent: March 20, 2020 1:50 PM
To: Noel Kuntze ; 
users@lists.strongswan.org
Subject: RE: [strongSwan] ikeV1 tunnel established but packets are not routed. 
V2 works.

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: makarandprad...@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 
Sent: March 20, 2020 1:21 PM
To: Makarand Pradhan ; users@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@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: makarandprad...@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 

Re: [strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group

[Makarand Pradhan]

Tx Tobias.

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: makarandprad...@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: Tobias Brunner  
Sent: April 2, 2020 11:55 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] ikev2: Tunnel established inspite of different phase 
2 DH group

Hi Makarand,

> Is there a way I can force a CHILD_SA delete when the Proposal mismatch 
> occurs?

No, but plugins can listen for alerts of type ALERT_PROPOSAL_MISMATCH_CHILD, 
which is also possible via error-notify plugin [1].

Regards,
Tobias

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ErrorNotifyPlugin

Re: [strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group

[Makarand Pradhan]

Hi Tobias,

As mentioned on the Wiki, I am trying to rekey using swanctl. The connections 
continues to stay up even after I perform a rekey.

Is there a way I can force a CHILD_SA delete when the Proposal mismatch occurs?

Log:
Initiate rekey:
root@t1024rdb:/usr/local/etc# !swan
swanctl -R -P -i m1 -c m1
rekey reply {
  success = yes
  matches = 1
}

The tunnel status ESTABLISHED/INSTALLED:
root@t1024rdb:/usr/local/etc# ipsec statusall m1
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
  uptime: 14 minutes, since Apr 02 11:40:38 2020
  malloc: sbrk 2297856, mmap 0, used 408224, free 1889632
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 63
  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.1
  192.168.51.2
  192.168.52.2
  91.0.0.2
Connections:
  m1:  91.0.0.2...91.0.0.3  IKEv2
  m1:   local:  [m1_91.0.0.2] uses pre-shared key authentication
  m1:   remote: [m1_91.0.0.3] uses pre-shared key authentication
  m1:   child:  192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 
192.168.61.0/24 TUNNEL
Security Associations (2 up, 0 connecting):
  m1[13]: ESTABLISHED 25 seconds ago, 
91.0.0.2[m1_91.0.0.2]...91.0.0.3[m1_91.0.0.3]
  m1[13]: IKEv2 SPIs: bb0b3c94b4a1087e_i* 60383db9c4be318c_r, 
pre-shared key reauthentication in 13 minutes
  m1[13]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
  m1{2038}:  INSTALLED, TUNNEL, reqid 13, ESP SPIs: c4a03d41_i 
ce69b3f6_o
  m1{2038}:  AES_CBC_256/HMAC_SHA2_256_128, 2016 bytes_i (24 pkts, 0s 
ago), 2016 bytes_o (24 pkts, 0s ago), rekeying active
  m1{2038}:   192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 
192.168.61.0/24

I do see that the rekey fails due to Proposal mismatch in the DH group:

Swanctl --log:

10[IKE] establishing CHILD_SA m1{2666} reqid 9
10[ENC] generating CREATE_CHILD_SA request 121 [ N(REKEY_SA) SA No KE TSi TSr ]
10[NET] sending packet: from 91.0.0.2[500] to 91.0.0.3[500] (368 bytes)
11[NET] received packet: from 91.0.0.3[500] to 91.0.0.2[500] (96 bytes)
11[ENC] parsed CREATE_CHILD_SA response 121 [ N(NO_PROP) ]
11[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
11[IKE] failed to establish CHILD_SA, keeping IKE_SA
11[IKE] CHILD_SA rekeying failed, trying again in 12 seconds
14[NET] received packet: from 91.0.0.3[500] to 91.0.0.2[500] (528 bytes)
14[ENC] parsed CREATE_CHILD_SA request 48 [ N(REKEY_SA) SA No KE TSi TSr ]
14[CFG] received proposals: 
ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
14[CFG] configured proposals: 
ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_768/NO_EXT_SEQ
14[IKE] no acceptable proposal found
14[IKE] failed to establish CHILD_SA, keeping IKE_SA


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: makarandprad...@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  On Behalf Of Makarand Pradhan
Sent: April 2, 2020 8:53 AM
To: Tobias Brunner ; users@lists.strongswan.org
Subject: Re: [strongSwan] ikev2: Tunnel established inspite of different phase 
2 DH group

Good morning Tobias,

Appreciate your confirmation.

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: makarandprad...@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

Re: [strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group

[Makarand Pradhan]

Good morning Tobias,

Appreciate your confirmation.

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: makarandprad...@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: Tobias Brunner  
Sent: April 2, 2020 4:46 AM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] ikev2: Tunnel established inspite of different phase 
2 DH group

Hi Makarand,

> Is the system behaving correctly? i.e. the DH group is used only during reneg 
> after expiry of lifetime?

Yes, see [1].

Regards,
Tobias

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey#IKEv2

[strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group

[Makarand Pradhan]

  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 12
  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.1
  192.168.51.2
  192.168.52.2
  91.0.0.2
Connections:
  m1:  91.0.0.2...91.0.0.3  IKEv2
  m1:   local:  [m1_91.0.0.2] uses pre-shared key authentication
  m1:   remote: [m1_91.0.0.3] uses pre-shared key authentication
  m1:   child:  192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 
192.168.61.0/24 TUNNEL
Security Associations (2 up, 0 connecting):
  m1[2]: ESTABLISHED 19 seconds ago, 
91.0.0.2[m1_91.0.0.2]...91.0.0.3[m1_91.0.0.3]
  m1[2]: IKEv2 SPIs: accd0f528860aa9e_i* e11f4d8d8bb4c717_r, pre-shared 
key reauthentication in 24 minutes
  m1[2]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536


Would highly appreciate your inputs. 

Is the system behaving correctly? i.e. the DH group is used only during reneg 
after expiry of lifetime?

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: makarandprad...@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.

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

[Makarand Pradhan]

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: makarandprad...@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  
Sent: March 20, 2020 1:21 PM
To: Makarand Pradhan ; users@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@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: makarandprad...@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 
> Sent: March 20, 2020 11:23 AM
> To: Makarand Pradhan ; 
> users@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
>>   

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

[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: makarandprad...@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  
Sent: March 20, 2020 11:23 AM
To: Makarand Pradhan ; users@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: makarandprad...@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 
> Sent: March 20, 2020 11:15 AM
> To: Makarand Pradhan ; 
> users@lists.strongswan.org
> Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not 
> routed. V2 works.
> 
> IKEv1 does not 

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

[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: makarandprad...@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  
Sent: March 20, 2020 11:15 AM
To: Makarand Pradhan ; users@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: makarandprad...@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  On Behalf Of Makarand 
> Pradhan
> Sent: March 19, 2020 4:07 PM
> To: users@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: makarandprad...@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

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

[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: makarandprad...@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  On Behalf Of Makarand Pradhan
Sent: March 19, 2020 4:07 PM
To: users@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: makarandprad...@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  On Behalf Of Makarand Pradhan
Sent: March 19, 2020 2:28 PM
To: users@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

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

[Makarand Pradhan]

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: makarandprad...@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  On Behalf Of Makarand Pradhan
Sent: March 19, 2020 2:28 PM
To: users@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 :

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

[Makarand Pradhan]

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: makarandprad...@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.

Re: [strongSwan] Wrong DH group and hash in IKE phase 1 proposal

[Makarand Pradhan]

Hi All,

A quick update to my last query.

Make clean and a reboot seems to have fixed the issue. I haven’t modified any 
strongswan code so it should not have mattered. Anyways. Now I can see the IKE 
PH1 complete.

*Dec 13 17:14:29.259: ISAKMP:(1008):Input = IKE_MESG_INTERNAL, 
IKE_PHASE1_COMPLETE
*Dec 13 17:14:29.259: ISAKMP:(1008):Old State = IKE_P1_COMPLETE  New State = 
IKE_P1_COMPLETE

Thanks.

Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: makarandprad...@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  On Behalf Of Makarand Pradhan
Sent: December 12, 2019 2:31 PM
To: users@lists.strongswan.org
Subject: [strongSwan] Wrong DH group and hash in IKE phase 1 proposal

Hello Everyone,

I'm trying to set up a tunnel between Strongswan and Cisco 2811. I'm following 
instructions per:

https://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Phase 1 parameters are configured in ipsec.conf as:
keyexchange=ikev1
ike=aes128-md5-modp1536  

When I try starting up the tunnel, the IKE proposal sent out contains:

Per log on Cisco router:
*Dec 12 21:32:39.438: ISAKMP:  encryption AES-CBC
*Dec 12 21:32:39.438: ISAKMP:  keylength of 128
*Dec 12 21:32:39.438: ISAKMP:  hash SHA256
*Dec 12 21:32:39.438: ISAKMP:  unknown DH group 31
*Dec 12 21:32:39.438: ISAKMP:  auth pre-share
*Dec 12 21:32:39.438: ISAKMP:  life type in seconds
*Dec 12 21:32:39.438: ISAKMP:  life duration (basic) of 1520

I've captured the packet in wireshark and the packet indicates the wrong DH 
group and wrong hash. I've attached the captured pcap file.

My ipsec.conf file is as follows:

config setup 
charondebug=ike 4
 
#IS5#
conn m1  
type=tunnel  
authby=secret
auto=add 
keyexchange=ikev1
ike=aes128-md5-modp1536  
esp=aes128-sha1  
ikelifetime=1520 
right=80.0.0.3   
rightid=80.0.0.3 
rightsubnet=10.10.3.0/24 
left=80.0.0.2
leftid=80.0.0.2  
leftsubnet=192.168.0.0/16   

 I've tried changing to 3DES and SHA512 and different DH groups in ipsec.conf. 
All the same, I always see AES-SHA256-DHGRP31 going out.

Any opinions or suggestions to correct my ipsec.conf would be highly 
appreciated.

With rgds,
Makarand.

Re: [strongSwan] Tunnel going down after 40+ hours

[Makarand Pradhan]

Good morning Noel,

We have tried to reproduce the issue but the tunnel has stayed up for 5 days in 
a row. The only difference in this experiment were:

1. auto=start as you had suggested and
2. traffic was toned down to 900M instead of 1G.

As we are passing our requirements we are not pursuing the previously seen 
issue anymore.

Thanks for your help and suggestions.

With rgds,

Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: makarandprad...@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  
Sent: October 15, 2019 1:14 PM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] Tunnel going down after 40+ hours

Hello Makarand,

To actually figure out what's going on we need logs of when this all happens.

Provide the output of iptables-save to check if there really are no firewall 
rules.

Use auto=route instead of auto=start.

Kind regards

Noel

Am 15.10.19 um 15:44 schrieb Makarand Pradhan:
> Hi Noel,
> 
> Thanks for your note.
> 
> Our configuration is very simple. The ipsec.conf file is pated below:
> 
> config setup
> charondebug=@all@
> cachecrls=yes
> uniqueids=yes
> strictcrlpolicy=no
> 
> # Add connections here.
> conn rdb_to_rdb
> type=tunnel
> authby=secret
> auto=start
> keyexchange=ike
> esp=3des-md5
> right=80.0.0.2
> rightsubnet=192.168.2.1/24
> left=80.0.0.1
> leftsubnet=192.168.1.1/24
> 
> Also, we have not configured any firewall rules. The tunnel was up nearly 40 
> hours before closing.
> 
> So the only option seems to be some temporary network connectivity loss. 
> Though this is difficult as the machines are sitting right next to each other 
> and nothing else was happening over the weekend.
> 
> We will re run and monitor connectivity again.
> 
> Thanks.
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> #1-1815 Meyerside Drive
> Mississauga, Ontario
> L5T 1G3
> 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: makarandprad...@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 
> Sent: October 11, 2019 5:40 PM
> To: Makarand Pradhan ; 
> users@lists.strongswan.org
> Subject: Re: [strongSwan] Tunnel going down after 40+ hours
> 
> Hello Makarand,
> 
> 1) The other peer does not respond to any requests for rekeying so naturally 
> any expired tunnels don't magically persist.
> 2) The other peer doesn't respond to IKE messages so it's either dead 
> or the network made it unreachable ... or your firewall rules don't 
> allow the necessary messages to pass through (PEBKAC)
> 3) Please provide the configuration. And your cipher suites are suboptimal.
> 
> Kind regards
> 
> Noel
> 
> Am 11.10.19 um 21:39 schrieb Makarand Pradhan:
>> Hello everyone,
>>
>> We are running Strongswan 5.8 on Linux:
>> Linux t1024rdb 4.1.35-rt41 #1 SMP PREEMPT Wed Sep 4 14:39:22 EDT 2019
>> ppc64 GNU/Linux
>>
>> The tunnel is set up and works great for nearly 41 hours and then it is 
>> destroyed. We have experienced the same failure 2 consecutive times. So we 
>> increased the log level and dumped NET, ENC, IKE, CFG and KNL log levels.
>>
>> We notice that when we fail we

Re: [strongSwan] Tunnel going down after 40+ hours

[Makarand Pradhan]

Hi Noel,

Thanks for your note.

Our configuration is very simple. The ipsec.conf file is pated below:

config setup
charondebug=@all@
cachecrls=yes
uniqueids=yes
strictcrlpolicy=no

# Add connections here.
conn rdb_to_rdb
type=tunnel
authby=secret
auto=start
keyexchange=ike
esp=3des-md5
right=80.0.0.2
rightsubnet=192.168.2.1/24
left=80.0.0.1
leftsubnet=192.168.1.1/24

Also, we have not configured any firewall rules. The tunnel was up nearly 40 
hours before closing.

So the only option seems to be some temporary network connectivity loss. Though 
this is difficult as the machines are sitting right next to each other and 
nothing else was happening over the weekend.

We will re run and monitor connectivity again.

Thanks.
Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: makarandprad...@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  
Sent: October 11, 2019 5:40 PM
To: Makarand Pradhan ; users@lists.strongswan.org
Subject: Re: [strongSwan] Tunnel going down after 40+ hours

Hello Makarand,

1) The other peer does not respond to any requests for rekeying so naturally 
any expired tunnels don't magically persist.
2) The other peer doesn't respond to IKE messages so it's either dead or the 
network made it unreachable ... or your firewall rules don't allow the 
necessary messages to pass through (PEBKAC)
3) Please provide the configuration. And your cipher suites are suboptimal.

Kind regards

Noel

Am 11.10.19 um 21:39 schrieb Makarand Pradhan:
> Hello everyone,
> 
> We are running Strongswan 5.8 on Linux:
> Linux t1024rdb 4.1.35-rt41 #1 SMP PREEMPT Wed Sep 4 14:39:22 EDT 2019 
> ppc64 GNU/Linux
> 
> The tunnel is set up and works great for nearly 41 hours and then it is 
> destroyed. We have experienced the same failure 2 consecutive times. So we 
> increased the log level and dumped NET, ENC, IKE, CFG and KNL log levels.
> 
> We notice that when we fail we get an XFRM_MSG_EXPIRE. After that we do not 
> receive a response from the other side and then we give up after 5 attempts. 
> In previous XFRM_MSG_EXPIRE instances we notice that replies were received 
> from the other side.
> 
> The IP connectivity between both the machines is up. Also the next time we 
> "ipsec start" the tunnels are set up correctly and start working again.
> 
> We were wondering if someone can comment/speculate on possible reasons for 
> the failure? 
> 
> Any way we can instruct charon to retry after giving up?
> 
> Your thoughts/suggestions would be highly appreciated.
> 
> Logs below:
> 
> 
> ct  6 05:33:59 t1024rdb charon: 16[NET] received packet: from 
> 80.0.0.1[500] to 80.0.0.2[500] (392 bytes) Oct  6 05:33:59 t1024rdb 
> charon: 16[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) 
> N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] Oct  6 05:33:59 
> t1024rdb charon: 16[IKE] 80.0.0.1 is initiating an IKE_SA Oct  6 
> 05:33:59 t1024rdb charon: 16[CFG] selected proposal: 
> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_AES128_XCBC/CURVE_25519
> Oct  6 05:33:59 t1024rdb charon: 16[ENC] generating IKE_SA_INIT 
> response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) 
> N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ] Oct  6 05:33:59 t1024rdb 
> charon: 16[NET] sending packet: from 80.0.0.2[500] to 80.0.0.1[500] 
> (248 bytes) Oct  6 05:34:00 t1024rdb charon: 09[NET] received packet: 
> from 80.0.0.1[4500] to 80.0.0.2[4500] (368 bytes) Oct  6 05:34:00 
> t1024rdb charon: 09[ENC] parsed IKE_AUTH request 1 [ IDi 
> N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) 
> N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) 
> N(MSG_ID_SYN_SUP) ] Oct  6 05:34:00 t1024rdb charon: 09[CFG] looking 
> for peer configs matching 80.0.0.2[80.0.0.2]...80.0.0.1[80.0.0.1]
> Oct  6 05:34:00 t1024rdb charon: 09[CFG] selected peer config 'pi_to_pi'
> Oct  6 05:34:00 t1024rdb charon: 09[IKE] authentication of '80.0.0.1' 
> with pre-shared key successful Oct  6 05:34:00 t1024r

[strongSwan] Tunnel going down after 40+ hours

[Makarand Pradhan]

from 80.0.0.2[4500] to 
80.0.0.1[4500]
Oct  7 22:56:22 t1024rdb charon: 08[IKE] retransmit 4 of request with message 
ID 2
Oct  7 22:56:22 t1024rdb charon: 08[NET] sending packet: from 80.0.0.2[4500] to 
80.0.0.1[4500] (288 bytes)
Oct  7 22:56:22 t1024rdb charon: 03[NET] sending packet: from 80.0.0.2[4500] to 
80.0.0.1[4500]
Oct  7 22:57:04 t1024rdb charon: 11[IKE] retransmit 5 of request with message 
ID 2
Oct  7 22:57:04 t1024rdb charon: 11[NET] sending packet: from 80.0.0.2[4500] to 
80.0.0.1[4500] (288 bytes)
Oct  7 22:57:04 t1024rdb charon: 03[NET] sending packet: from 80.0.0.2[4500] to 
80.0.0.1[4500]
Oct  7 22:57:35 t1024rdb charon: 16[KNL] received a XFRM_MSG_EXPIRE
Oct  7 22:57:35 t1024rdb charon: 16[KNL] creating rekey job for CHILD_SA 
ESP/0xce9c4468/80.0.0.1
Oct  7 22:57:35 t1024rdb charon: 16[IKE] queueing CHILD_REKEY task
Oct  7 22:57:35 t1024rdb charon: 16[IKE] delaying task initiation, 
CREATE_CHILD_SA exchange in progress
Oct  7 22:58:20 t1024rdb charon: 10[KNL] received a XFRM_MSG_EXPIRE
Oct  7 22:58:20 t1024rdb charon: 10[KNL] creating delete job for CHILD_SA 
ESP/0xc9169901/80.0.0.2
Oct  7 22:58:20 t1024rdb charon: 10[JOB] CHILD_SA ESP/0xc9169901/80.0.0.2 not 
found for delete
Oct  7 22:58:20 t1024rdb charon: 13[IKE] giving up after 5 retransmits
Oct  7 22:58:20 t1024rdb charon: 13[IKE] IKE_SA pi_to_pi[30] state change: 
ESTABLISHED => DESTROYING
Oct  7 22:58:20 t1024rdb charon: 13[CHD] CHILD_SA pi_to_pi{119} state change: 
CREATED => DESTROYING
Oct  7 22:58:20 t1024rdb charon: 13[KNL] deleting SAD entry with SPI c9169901
Oct  7 22:58:20 t1024rdb charon: 13[CHD] CHILD_SA pi_to_pi{118} state change: 
REKEYING => DESTROYING
Oct  7 22:58:20 t1024rdb charon: 13[KNL] deleting policy 192.168.2.0/24 === 
192.168.1.0/24 out
Oct  7 22:58:20 t1024rdb charon: 13[KNL] getting iface index for fm1-mac1.0555
Oct  7 22:58:20 t1024rdb charon: 13[KNL] deleting policy 192.168.1.0/24 === 
192.168.2.0/24 in
Oct  7 22:58:20 t1024rdb charon: 13[KNL] deleting policy 192.168.1.0/24 === 
192.168.2.0/24 fwd
Oct  7 22:58:20 t1024rdb charon: 13[KNL] deleting policy 192.168.55.0/24 === 
192.168.1.0/24 out


Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: makarandprad...@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.

[strongSwan] Strongswan, Netns and routing configuration question

[Makarand Pradhan]

Hello All,

I am running strongswan in a netns. My ipsec tunnel is established. I can ping 
the 2 sides. All the same, I cannot ping any other devices on the subnet. Would 
highly appreciate any help. 

The setup is described below in detail:

PC 10.10.24.1/24 <-LAN-> 10.10.24.3/24(eth0 Pi 80.0.0.3/24 (eth1)<- strongswan 
ipsec tunnel -> 80.0.0.2/24 (net1_veth0.80) 10.10.23.2(net1_veth0.23) 
<-LAN->10.10.23.4

I am now trying to ping 10.10.23.4 from 10.10.24.1.

On 10.10.24.1, the routing table has 10.10.24.3 is via gate way 10.10.24.3

10.10.23.0/24 via 10.10.24.3 dev eth1 

I see the ESP packets come into net1_veth0.80.

13:49:28.620355 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP 
(50), length 156)
80.0.0.3 > 80.0.0.2: ESP(spi=0xcd75daf6,seq=0x12), length 136
0x:  e8e8 7590 02c1 b827 eb59 2766 0800 4500
0x0010:  009c  4000 4032 9a2b 5000 0003 5000
0x0020:  0002 cd75 daf6  0012 d8c5 4673 6d25
0x0030:  19fc 6857 c12b e6a9 ed44 b901 c3b3 db96
0x0040:  e9b2 acea 65a2 3fd9 b670 ee41 7886 843b
0x0050:  0d1a 46ce 3b05 a639 d639 b27a 726d b10d
0x0060:  4972 002f d922 fbfd 6832 45e8 0adb 73f4
0x0070:  37f9 fd8e 66e3 6daa 453c a70b 7b44 4ee6
0x0080:  ac96 597a f20f 0948 307d af63 7146 acab
0x0090:  40e5 17f0 2b1e b165 e579 1021 40ae 4837
0x00a0:  fa8b 7827 2464 1f2d 449f

The decrypted packet is seen on net1_veth0.80:

13:49:28.620490 IP (tos 0x0, ttl 63, id 2164, offset 0, flags [DF], proto ICMP 
(1), length 84)
10.10.24.1 > 10.10.23.4: ICMP echo request, id 375, seq 18, length 64
0x:  e8e8 7590 02c1 b827 eb59 2766 0800 4500
0x0010:  0054 0874 4000 3f01 f01c 0a0a 1801 0a0a
0x0020:  1704 0800 1e0e 0177 0012 a46b d45c 
0x0030:   95cd 0b00   1011 1213 1415
0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
0x0060:  3637

The packet does not come out on the net1_veth0.23 interface.

The routing table in the network name space is as follows:
sh-4.3# ip netns exec net1 ip ro
10.10.23.0/24 dev net1_veth0.23  proto kernel  scope link  src 10.10.23.2
80.0.0.0/24 dev net1_veth0.80  proto kernel  scope link  src 80.0.0.2

ip_forward is set:

sh-4.3# cat /proc/sys/net/ipv4/ip_forward
1

Also forwarding is set on all the veth interfaces, e.g.:

sh-4.3# cat /proc/sys/net/ipv4/conf/veth0/forwarding
1

sh-4.3# cat /proc/sys/net/ipv4/conf/veth0.80/forwarding
1

I am probably missing something in my routing config. This is probably more of 
a routing question.

Thanks for taking the time to read the question.

With Rgds,
Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: makarandprad...@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.

[strongSwan] Tunnel established but cannot ping. Request help.

[Makarand Pradhan]

Hello Everyone,

This is the first time I'm trying to use StrongSwan.

I'm trying to use strongswan to create an IPSec tunnel. The tunnel status says 
up but I cannot ping over the tunnel. Would appreciate any pointers to get it 
working.

Please find below a detailed view of the issue.

Setup:

(Left subnet)
172.16.18.88 80.0.0.1 <-Router-> 30.0.0.1 10.1.1.1
wlan0    eth0    eth0 eth1   
Raspberry pi   Raspberry pi
StrongSwan running here. StrongSwan running here.

Left config:
config setup
   charondebug=@all@
   cachecrls=yes
   uniqueids=yes
   strictcrlpolicy=no
   # uniqueids = no

conn pi_to_pi
   type=tunnel
   authby=secret
   auto=start
   keyexchange=ike
   esp=3des-md5
   left=%defaultroute
   leftid=80.0.0.1
   leftsubnet=172.16.18.88/24
   right=30.0.0.1
   rightsubnet=10.1.1.0/24

root@raspberrypi:~# ipsec status
Security Associations (1 up, 0 connecting):
    pi_to_pi[1]: ESTABLISHED 10 minutes ago, 
80.0.0.1[80.0.0.1]...30.0.0.1[30.0.0.1]
    pi_to_pi{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb15009b_i cc28abb3_o
    pi_to_pi{1}:   172.16.18.0/24 === 10.1.1.0/24

root@raspberrypi:~# ip xfrm policy | more
src 10.1.1.0/24 dst 172.16.18.0/24 
   dir fwd priority 187712 
   tmpl src 30.0.0.1 dst 80.0.0.1
  proto esp reqid 1 mode tunnel
src 10.1.1.0/24 dst 172.16.18.0/24 
   dir in priority 187712 
   tmpl src 30.0.0.1 dst 80.0.0.1
  proto esp reqid 1 mode tunnel
src 172.16.18.0/24 dst 10.1.1.0/24 
   dir out priority 187712 
   tmpl src 80.0.0.1 dst 30.0.0.1
  proto esp reqid 1 mode tunnel

root@raspberrypi:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination 

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 

Ping fails
root@raspberrypi:~# ping 10.1.1.1 -I 172.16.18.88
PING 10.1.1.1 (10.1.1.1) from 172.16.18.88 : 56(84) bytes of data.


TCP dump shows that the pkt is not going out over the tunnel but is just sent 
to the next hop:

21:06:46.079466 IP (tos 0x0, ttl 64, id 9795, offset 0, flags [DF], proto ICMP 
(1), length 84)
    80.0.0.1 > 10.1.1.1: ICMP echo request, id 1694, seq 30, length 64
   0x:  e8e8 7590 02c1 b827 eb85 9967 0800 4500  
..u'...g..E.
   0x0010:  0054 2643 4000 4001 b963 5000 0001 0a01  
mailto:.T@.@..cP.
   0x0020:  0101 0800 844a 069e 001e d663 a65c 0436  
.J.c.\.6
   0x0030:  0100 0809 0a0b 0c0d 0e0f 1011 1213 1415  

   0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425  
...!"#$%
   0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435  
&'()*+,-./012345
   0x0060:  3637 67

Any pointers to get the tunnel working would be highly appreciated.

With Rgds,
Makarand.

Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
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: mailto:makarandprad...@is5com.com
Website: http://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.