[strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group
Makarand Pradhan
MakarandPradhan at is5com.com
Wed Apr 1 20:00:08 CEST 2020
Good afternoon,
I am using StrongSwan 5.8.2. It is noticed that the tunnel comes up and starts allowing traffic even though the DH group is different for esp in ipsec.conf:
Device 1: ipsec.conf
conn m1
type=tunnel
authby=secret
auto=add
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=3s
esp=aes256-sha256-modp1536!
lifetime=15s
right=91.0.0.3
rightid=m1_91.0.0.3
rightsubnet=10.10.9.0/24,192.168.61.0/24
left=91.0.0.2
leftid=m1_91.0.0.2
leftsubnet=192.168.9.0/24,192.168.51.0/24
On device 2 ipsec.conf:
conn m1
type=tunnel
authby=secret
auto=add
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=3s
esp=aes256-sha256-modp2048!
lifetime=15s
right=91.0.0.2
rightid=m1_91.0.0.2
rightsubnet=192.168.9.0/24,192.168.51.0/24
left=91.0.0.3
leftid=m1_91.0.0.3
leftsubnet=10.10.9.0/24,192.168.61.0/24
After the expiry of the lifetime, the CHILD_SA goes down due to proposal mismatch, but till then traffic continues to flow.
As per my understanding in the quick mode negotiation for phase 2, the CHILD_SA should not get built as the proposal should get rejected.
Log:
root at t1024rdb:/usr/local/etc# ipsec up m1
initiating IKE_SA m1[2] to 91.0.0.3
generating 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) ]
sending packet: from 91.0.0.2[500] to 91.0.0.3[500] (400 bytes)
received packet: from 91.0.0.3[500] to 91.0.0.2[500] (408 bytes)
parsed 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) ]
selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
authentication of 'm1_91.0.0.2' (myself) with pre-shared key
establishing CHILD_SA m1{5}
generating 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(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 91.0.0.2[4500] to 91.0.0.3[4500] (400 bytes)
received packet: from 91.0.0.3[4500] to 91.0.0.2[4500] (352 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
authentication of 'm1_91.0.0.3' with pre-shared key successful
IKE_SA m1[2] established between 91.0.0.2[m1_91.0.0.2]...91.0.0.3[m1_91.0.0.3]
scheduling reauthentication in -624s
maximum IKE_SA lifetime -84s
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
CHILD_SA m1{5} established with SPIs c8bed58d_i c3d2c2e5_o and TS 192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 192.168.61.0/24
connection 'm1' established successfully
root at t1024rdb:/usr/local/etc# ipsec statusall m1
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
uptime: 9 seconds, since Apr 01 14:05:34 2020
malloc: sbrk 2297856, mmap 0, used 314912, free 1982944
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 7 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
m1{5}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: c8bed58d_i c3d2c2e5_o
m1{5}: AES_CBC_256/HMAC_SHA2_256_128, 420 bytes_i (5 pkts, 1s ago), 420 bytes_o (5 pkts, 1s ago), rekeying active
m1{5}: 192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 192.168.61.0/24
root at t1024rdb:/usr/local/etc# ipsec statusall m1
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
uptime: 21 seconds, since Apr 01 14:05:34 2020
malloc: sbrk 2297856, mmap 0, used 295952, free 2001904
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: makarandpradhan at is5com.com
Website: www.iS5Com.com
Confidentiality Notice:
This message is intended only for the named recipients. This message may contain information that is confidential and/or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.
More information about the Users
mailing list