Issue #2978: unable to install policy 0.0.0.0/0 === x.x.x.x/32 out for reqid 137711, the same policy for reqid 137080 exists - strongSwan

Issue #2978

unable to install policy 0.0.0.0/0 === x.x.x.x/32 out for reqid 137711, the same policy for reqid 137080 exists

Added by Sebastian Krebs over 6 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Tobias Brunner

Category:

kernel-interface

Affected version:

5.6.2

Resolution:

Fixed

Description

In order to monitor our VPN installation we are using different internal and external monitoring systems, which simulate VPN connects as shown in this picture.

The internal monitoring systems are running a job, which will try to connect every 5 minutes and check, if everything is working. In most cases, this works fine without any issue. But sometimes we do see the issue with the following logs.
The same problem does not seem to happen with the external monitoring systems, which take their way through the loadbalancers and are running a job every minute. But as we want the internal systems to be able to check each VPN Server instance, we are placing them in the same network as the loadbalancers and let them connect directly to the VPN servers. On the loadbalancer we are using IPVS with Source Hash algorithms to make the connection for IPSec work for the mobile devices and external monitoring systems.

Client log

initiating IKE_SA 172.30.2.82[31] to 172.30.2.82
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 172.30.2.47[500] to 172.30.2.82[500] (1608 bytes)
received packet: from 172.30.2.82[500] to 172.30.2.47[500] (60 bytes)
parsed IKE_SA_INIT response 0 [ N(COOKIE) ]
initiating IKE_SA 172.30.2.82[31] to 172.30.2.82
generating IKE_SA_INIT request 0 [ N(COOKIE) SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 172.30.2.47[500] to 172.30.2.82[500] (1640 bytes)
received packet: from 172.30.2.82[500] to 172.30.2.47[500] (745 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
remote host is behind NAT
received 1 cert requests for an unknown ca
establishing CHILD_SA 172.30.2.82{31}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (608 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
parsed IKE_AUTH response 1 [ EF(1/4) ]
received fragment #1 of 4, waiting for complete IKE message
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
parsed IKE_AUTH response 1 [ EF(2/4) ]
received fragment #2 of 4, waiting for complete IKE message
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
parsed IKE_AUTH response 1 [ EF(3/4) ]
received fragment #3 of 4, waiting for complete IKE message
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (452 bytes)
parsed IKE_AUTH response 1 [ EF(4/4) ]
received fragment #4 of 4, reassembling fragmented IKE message
parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
received end entity cert "some-id" 
received issuer cert "C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA" 
  using untrusted intermediate certificate "C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA" 
checking certificate status of "some-id" 
  ocsp response correctly signed by "C=DE, O=T-Systems International GmbH, OU=Trust Center Deutsche Telekom, CN=OCSP-Signer TeleSec ServerPass Class 2 CA" 
  ocsp response is valid: until Mar 20 07:11:01 2019
  using cached ocsp response
certificate status is good
  reached self-signed root ca with a path length of 0
  using trusted certificate "some-id" 
authentication of 'some-id' with RSA_EMSA_PKCS1_SHA2_256 successful
server requested EAP_IDENTITY (id 0x00), sending 'test-user-id'
generating IKE_AUTH request 2 [ EAP/RES/ID ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (96 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (80 bytes)
parsed IKE_AUTH response 2 [ EAP/REQ/PEAP ]
server requested EAP_PEAP authentication (id 0x01)
EAP_PEAP version is v0
generating IKE_AUTH request 3 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (256 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
parsed IKE_AUTH response 3 [ EAP/REQ/PEAP ]
negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
generating IKE_AUTH request 4 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
parsed IKE_AUTH response 4 [ EAP/REQ/PEAP ]
generating IKE_AUTH request 5 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
parsed IKE_AUTH response 5 [ EAP/REQ/PEAP ]
generating IKE_AUTH request 6 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (880 bytes)
parsed IKE_AUTH response 6 [ EAP/REQ/PEAP ]
received TLS server certificate 'some-id'
received TLS intermediate certificate 'C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA'
  using untrusted intermediate certificate "C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA" 
checking certificate status of "some-id" 
  ocsp response correctly signed by "C=DE, O=T-Systems International GmbH, OU=Trust Center Deutsche Telekom, CN=OCSP-Signer TeleSec ServerPass Class 2 CA" 
  ocsp response is valid: until Mar 20 07:11:01 2019
  using cached ocsp response
certificate status is good
  reached self-signed root ca with a path length of 0
  using trusted certificate "some-id" 
generating IKE_AUTH request 7 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (240 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)
parsed IKE_AUTH response 7 [ EAP/REQ/PEAP ]
generating IKE_AUTH request 8 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (128 bytes)
parsed IKE_AUTH response 8 [ EAP/REQ/PEAP ]
received tunneled EAP-PEAP AVP [EAP/REQ/ID]
server requested EAP_IDENTITY authentication (id 0x07)
sending tunneled EAP-PEAP AVP [EAP/RES/ID]
generating IKE_AUTH request 9 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)
parsed IKE_AUTH response 9 [ EAP/REQ/PEAP ]
received tunneled EAP-PEAP AVP [EAP/REQ/MSCHAPV2]
server requested EAP_MSCHAPV2 authentication (id 0x08)
sending tunneled EAP-PEAP AVP [EAP/RES/MSCHAPV2]
generating IKE_AUTH request 10 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (192 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (176 bytes)
parsed IKE_AUTH response 10 [ EAP/REQ/PEAP ]
received tunneled EAP-PEAP AVP [EAP/REQ/MSCHAPV2]
EAP-MS-CHAPv2 succeeded: '(null)'
sending tunneled EAP-PEAP AVP [EAP/RES/MSCHAPV2]
generating IKE_AUTH request 11 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (128 bytes)
parsed IKE_AUTH response 11 [ EAP/REQ/PEAP ]
received tunneled EAP-PEAP AVP [EAP/SUCC]
sending tunneled EAP-PEAP AVP [EAP/SUCC]
generating IKE_AUTH request 12 [ EAP/RES/PEAP ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (80 bytes)
parsed IKE_AUTH response 12 [ EAP/SUCC ]
EAP method EAP_PEAP succeeded, MSK established
authentication of 'some-client-id' (myself) with EAP
generating IKE_AUTH request 13 [ AUTH ]
sending packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (112 bytes)
received packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)
parsed IKE_AUTH response 13 [ AUTH CPRP(ADDR DNS DNS) N(TS_UNACCEPT) ]
authentication of 'some-id' with EAP successful
IKE_SA 172.30.2.82[31] established between 172.30.2.47[some-client-id]...172.30.2.82[some-id]
installing DNS server 8.8.8.8 via resolvconf
installing DNS server 8.8.4.4 via resolvconf
installing new virtual IP 172.18.153.42
received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
establishing connection '172.30.2.82' failed

Server Log
This log might contain some lines, which do not contain to the connection attempt, but come from the loadbalancer health checks, which is based on ike-scan and just sends a first package to see, if an IPSec system is answering.

2019-03-15 07:50:20 13[MGR] created IKE_SA (unnamed)[1585372]
2019-03-15 07:50:20 13[NET] received packet: from 172.30.2.47[500] to 172.30.2.82[500] (1640 bytes)
2019-03-15 07:50:20 13[CFG] looking for an ike config for 172.30.2.82...172.30.2.47
2019-03-15 07:50:20 13[CFG]   candidate: %any...%any, prio 28
2019-03-15 07:50:20 13[CFG]   candidate: %any...%any, prio 28
2019-03-15 07:50:20 13[CFG] found matching ike config: %any...%any with prio 28
2019-03-15 07:50:20 13[IKE] 172.30.2.47 is initiating an IKE_SA
2019-03-15 07:50:20 13[IKE] IKE_SA (unnamed)[1585372] state change: CREATED => CONNECTING
2019-03-15 07:50:20 13[CFG] selecting proposal:
2019-03-15 07:50:20 13[CFG]   proposal matches
2019-03-15 07:50:20 13[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/HMAC_SHA1_96/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_SHA1/MODP_4096/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/NTRU_128/NTRU_192/NTRU_256/MODP_3072/MODP_6144/MODP_8192/MODP_2048, IKE:AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/CHACHA20_POLY1305_256/CAMELLIA_CCM_16_128/CAMELLIA_CCM_16_192/CAMELLIA_CCM_16_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/CAMELLIA_CCM_8_128/CAMELLIA_CCM_8_192/CAMELLIA_CCM_8_256/CAMELLIA_CCM_12_128/CAMELLIA_CCM_12_192/CAMELLIA_CCM_12_256/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_SHA1/MODP_4096/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/NTRU_128/NTRU_192/NTRU_256/MODP_3072/MODP_6144/MODP_8192/MODP_2048
2019-03-15 07:50:20 13[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
2019-03-15 07:50:20 13[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
2019-03-15 07:50:20 13[CFG] received supported signature hash algorithms: sha256 sha384 sha512 identity
2019-03-15 07:50:20 13[IKE] faking NAT situation to enforce UDP encapsulation
2019-03-15 07:50:20 13[CFG] sending supported signature hash algorithms: sha256 sha384 sha512 identity
2019-03-15 07:50:20 13[IKE] sending cert request for "C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA" 
2019-03-15 07:50:20 13[NET] sending packet: from 172.30.2.82[500] to 172.30.2.47[500] (745 bytes)
2019-03-15 07:50:20 13[MGR] checkin IKE_SA (unnamed)[1585372]
2019-03-15 07:50:20 13[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 03[NET] sending packet: from 172.30.1.82[500] to 172.30.1.3[53414] (60 bytes)
2019-03-15 07:50:21 06[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 06[MGR] IKE_SA (unnamed)[1585372] successfully checked out
2019-03-15 07:50:21 06[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (608 bytes)
2019-03-15 07:50:21 06[CFG] looking for peer configs matching 172.30.2.82[some-id]...172.30.2.47[some-client-id]
2019-03-15 07:50:21 06[CFG]   candidate "clients-ikev2", match: 20/1/28 (me/other/ike)
2019-03-15 07:50:21 06[CFG] selected peer config 'clients-ikev2'
2019-03-15 07:50:21 06[IKE] initiating EAP_IDENTITY method (id 0x00)
2019-03-15 07:50:21 06[IKE] processing INTERNAL_IP4_ADDRESS attribute
2019-03-15 07:50:21 06[IKE] processing INTERNAL_IP4_DNS attribute
2019-03-15 07:50:21 03[NET] sending packet: from 172.30.4.82[500] to 172.30.4.3[34438] (60 bytes)
2019-03-15 07:50:21 14[MGR] checkout IKEv2 SA with SPIs 74ad6a817d5333c5_i 8f5b65360f083231_r
2019-03-15 07:50:21 14[MGR] IKE_SA checkout not successful
2019-03-15 07:50:21 06[IKE] authentication of 'some-id' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
2019-03-15 07:50:21 06[IKE] sending end entity cert "some-id" 
2019-03-15 07:50:21 06[IKE] sending issuer cert "C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen, postalCode=57250, L=Netphen, STREET=Untere Industriestr. 20, CN=TeleSec ServerPass Class 2 CA" 
2019-03-15 07:50:21 06[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
2019-03-15 07:50:21 06[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
2019-03-15 07:50:21 06[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1236 bytes)
2019-03-15 07:50:21 06[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (452 bytes)
2019-03-15 07:50:21 06[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 06[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 03[NET] sending packet: from 172.30.3.82[500] to 172.30.3.3[36193] (60 bytes)
2019-03-15 07:50:21 16[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 16[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 16[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (96 bytes)
2019-03-15 07:50:21 16[IKE] received EAP identity 'test-user-id'
2019-03-15 07:50:21 16[CFG] RADIUS server '10.0.5.248' is candidate: 210
2019-03-15 07:50:21 16[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 16[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 16[IKE] initiating EAP_PEAP method (id 0x01)
2019-03-15 07:50:21 16[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (80 bytes)
2019-03-15 07:50:21 16[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 16[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 07[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 07[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 07[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (256 bytes)
2019-03-15 07:50:21 07[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 07[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 07[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
2019-03-15 07:50:21 07[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 07[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 09[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 09[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 09[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
2019-03-15 07:50:21 09[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 09[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 09[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
2019-03-15 07:50:21 09[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 09[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 10[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 10[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 10[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
2019-03-15 07:50:21 10[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 10[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 10[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (1104 bytes)
2019-03-15 07:50:21 10[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 10[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 08[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 08[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 08[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
2019-03-15 07:50:21 08[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 08[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 08[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (880 bytes)
2019-03-15 07:50:21 08[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 08[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 15[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 15[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 15[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (240 bytes)
2019-03-15 07:50:21 15[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 15[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 15[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)
2019-03-15 07:50:21 15[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 15[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 11[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 11[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 11[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (80 bytes)
2019-03-15 07:50:21 11[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 11[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 11[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (128 bytes)
2019-03-15 07:50:21 11[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 11[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 05[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 05[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 05[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
2019-03-15 07:50:21 05[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 05[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 05[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)
2019-03-15 07:50:21 05[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 05[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 12[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 12[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 12[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (192 bytes)
2019-03-15 07:50:21 12[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 12[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 12[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (176 bytes)
2019-03-15 07:50:21 12[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 12[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 13[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 13[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 13[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
2019-03-15 07:50:21 13[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 13[CFG] received RADIUS Access-Challenge from server '10.0.5.248'
2019-03-15 07:50:21 13[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (128 bytes)
2019-03-15 07:50:21 13[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 13[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 14[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 14[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 14[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (128 bytes)
2019-03-15 07:50:21 14[CFG] sending RADIUS Access-Request to server '10.0.5.248'
2019-03-15 07:50:21 14[CFG] received RADIUS Access-Accept from server '10.0.5.248'
2019-03-15 07:50:21 14[IKE] RADIUS authentication of 'test-user-id' successful
2019-03-15 07:50:21 14[IKE] EAP method EAP_PEAP succeeded, MSK established
2019-03-15 07:50:21 14[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (80 bytes)
2019-03-15 07:50:21 14[MGR] checkin IKE_SA clients-ikev2[1585372]
2019-03-15 07:50:21 14[MGR] checkin of IKE_SA successful
2019-03-15 07:50:21 06[MGR] checkout IKEv2 SA by message with SPIs 19af986388dcf812_i d78a97199b7b97a5_r
2019-03-15 07:50:21 06[MGR] IKE_SA clients-ikev2[1585372] successfully checked out
2019-03-15 07:50:21 06[NET] received packet: from 172.30.2.47[4500] to 172.30.2.82[4500] (112 bytes)
2019-03-15 07:50:21 06[IKE] authentication of 'some-client-id' with EAP successful
2019-03-15 07:50:21 06[IKE] authentication of 'some-id' (myself) with EAP
2019-03-15 07:50:21 06[IKE] IKE_SA clients-ikev2[1585372] established between 172.30.2.82[some-id]...172.30.2.47[some-client-id]
2019-03-15 07:50:21 06[IKE] IKE_SA clients-ikev2[1585372] state change: CONNECTING => ESTABLISHED
2019-03-15 07:50:21 06[IKE] peer requested virtual IP %any
2019-03-15 07:50:21 06[CFG] reassigning existing offline lease by 'real-user-id' to 'test-user-id'
2019-03-15 07:50:21 06[IKE] assigning virtual IP 172.18.153.42 to peer 'test-user-id'
2019-03-15 07:50:21 06[IKE] building INTERNAL_IP4_DNS attribute
2019-03-15 07:50:21 06[IKE] building INTERNAL_IP4_DNS attribute
2019-03-15 07:50:21 06[CFG] looking for a child config for 0.0.0.0/0 === 0.0.0.0/0
2019-03-15 07:50:21 06[CFG] proposing traffic selectors for us:
2019-03-15 07:50:21 06[CFG]  0.0.0.0/0
2019-03-15 07:50:21 06[CFG] proposing traffic selectors for other:
2019-03-15 07:50:21 06[CFG]  172.18.153.42/32
2019-03-15 07:50:21 06[CFG]   candidate "clients-ikev2" with prio 5+1
2019-03-15 07:50:21 06[CFG] found matching child config "clients-ikev2" with prio 6
2019-03-15 07:50:21 06[CFG] selecting proposal:
2019-03-15 07:50:21 06[CFG]   proposal matches
2019-03-15 07:50:21 06[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ
2019-03-15 07:50:21 06[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_4096/NO_EXT_SEQ
2019-03-15 07:50:21 06[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
2019-03-15 07:50:21 06[CFG] selecting traffic selectors for us:
2019-03-15 07:50:21 06[CFG]  config: 0.0.0.0/0, received: 0.0.0.0/0 => match: 0.0.0.0/0
2019-03-15 07:50:21 06[CFG] selecting traffic selectors for other:
2019-03-15 07:50:21 06[CFG]  config: 172.18.153.42/32, received: 0.0.0.0/0 => match: 172.18.153.42/32
2019-03-15 07:50:21 06[CFG] unable to install policy 0.0.0.0/0 === 172.18.153.42/32 out for reqid 137711, the same policy for reqid 137080 exists
2019-03-15 07:50:21 06[IKE] unable to install IPsec policies (SPD) in kernel
2019-03-15 07:50:21 06[IKE] failed to establish CHILD_SA, keeping IKE_SA
2019-03-15 07:50:21 06[NET] sending packet: from 172.30.2.82[4500] to 172.30.2.47[4500] (160 bytes)

The setup we are using is based on IKEv2 and looks like the following
/etc/ipsec.conf Client configuration

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
       charondebug="ike 2, esp 2, chd 1, cfg 2, net 0, enc 1, knl 1" 

conn ikev2-base
  keyexchange=ikev2
  mobike=yes
  rekey=no
  auto=add
  rightsubnet=0.0.0.0/0
  rightfirewall=no
  rightsendcert=never
  rightauth=pubkey
  leftid="some-id" #real leftid was changed
  leftauth=eap
  leftsourceip=%config
  leftsendcert=never
  esp=aes256-sha256-modp4096
  ike=aes256-sha256-modp4096
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  rightcert=ipsec-cert-server.le.pem
  leftcert=ipsec-cert-client.2018.pem
  left=%any
  leftsourceip=%config
  xauth_identity=test-user-id

conn ikev2-prod
  also=ikev2-base
  eap_identity=test-user-id

conn bypass
  leftsubnet=10.0.0.0/8
  rightsubnet=10.0.0.0/8
  authby=never
  type=passthrough
  auto=route

# One connection for each IPSec Server (18 - 25)
conn "172.30.4.21" 
  also=ikev2-prod
  left=172.30.4.41
  right=172.30.4.21

/etc/ipsec.conf Server configuration

config setup
        strictcrlpolicy=no
        uniqueids = no

conn %default
        # not possible with asymmetric authentication
        reauth=no
        rekey=no
        dpdaction=clear
        dpddelay=35s
        dpdtimeout=200s
        forceencaps=yes
        fragmentation=yes
        auto=add
        esp=aes256-sha1
        ike=aes256-sha1-modp2048
        keyexchange=ikev1
        left=%any
        leftcert=ipsec-cert-server.le.pem
        leftid="CN=some-id" #real leftid was changed
        leftsendcert = always
        leftsubnet=0.0.0.0/0
        leftfirewall=yes
        right=%any
        rightsourceip=172.18.168.0/22

conn clients-ikev2
        keyexchange=ikev2
        reauth=no
        rekey=no
        mobike=yes
        rightauth=eap-radius
        eap_identity=%identity
        esp=aes256-sha256-modp4096!
        ike=aes256-sha256-modp4096!

conn clients-ikev2-ios
        also=clients-ikev2
        leftid="some-id" #real leftid was changed

### For Debug Messages
### Look in /var/log/charon.log
### Changes to the LogLevels are made in /etc/strongswan.conf
###     Restart strongswan after changes
### Logging Details in man 5 strongswan.conf

We already disables Reauthentication with reauth=no but it looks like the server tries to assign an offline lease of another "real-user-id" coming from a mobile device of a productive user to the "test-user-id" and afterwards gets some error installing the policy.
Any idea, how we can stop this from happening?

monitoring-systems.png (117 KB) monitoring-systems.png

Monitoring System Landscape

Sebastian Krebs, 15.03.2019 10:10

History

#1 Updated by Tobias Brunner over 6 years ago

Status changed from New to Feedback

Any idea, how we can stop this from happening?

I'd recommend updating to a newer release (at least 5.6.3) as this could be a duplicate of #2840 (see #2840-5).

#2 Updated by Sebastian Krebs over 6 years ago

Tobias Brunner wrote:

Any idea, how we can stop this from happening?

I'd recommend updating to a newer release (at least 5.6.3) as this could be a duplicate of #2840 (see #2840-5).

Ok. I guess this update has to happen on the server, correct? We are running Ubuntu 18.04 LTS. Is there any "easy" way to install 5.6.3 as a package there, besides compiling it on our own? Upgrading the OS to a non-LTS version is not really an option for the customer on the productive landscape. Or do you have any idea, if the fix will come into the 5.6.2 branch available in Ubuntu as well?

#3 Updated by Tobias Brunner over 6 years ago

I guess this update has to happen on the server, correct?

Yes.

We are running Ubuntu 18.04 LTS. Is there any "easy" way to install 5.6.3 as a package there, besides compiling it on our own?

Perhaps you can install the cosmic (18.10) packages (they are based on 5.6.3), or build your own.

Or do you have any idea, if the fix will come into the 5.6.2 branch available in Ubuntu as well?

You'd have to contact the maintainers of the Ubuntu packages (e.g. file a bug report via Launchpad).

#4 Updated by Sebastian Krebs over 6 years ago

Tobias Brunner wrote:

I guess this update has to happen on the server, correct?

Yes.

We are running Ubuntu 18.04 LTS. Is there any "easy" way to install 5.6.3 as a package there, besides compiling it on our own?

Perhaps you can install the cosmic (18.10) packages (they are based on 5.6.3), or build your own.

Ok, thanks for this hint. We have downloaded the 5.6.3 packages from Ubuntu 18.10 and installed into the 18.04 system in the test environment. We will now check, if this is stable enough to consider for production environment.

#5 Updated by Sebastian Krebs over 6 years ago

Tobias Brunner wrote:

Any idea, how we can stop this from happening?

I'd recommend updating to a newer release (at least 5.6.3) as this could be a duplicate of #2840 (see #2840-5).

We have upgraded our productive environment to 5.6.3 app. 36 hours ago and have not received this error again. It looks like the patch has fixed this issue. You can close this ticket from our side. Thanks again for your support Tobias!!!

#6 Updated by Tobias Brunner over 6 years ago

Category set to kernel-interface
Status changed from Feedback to Closed
Assignee set to Tobias Brunner
Resolution set to Fixed

Project

General

Profile

strongSwan

Issues

Issue #2978

unable to install policy 0.0.0.0/0 === x.x.x.x/32 out for reqid 137711, the same policy for reqid 137080 exists

History

#1 Updated by Tobias Brunner over 6 years ago

#2 Updated by Sebastian Krebs over 6 years ago

#3 Updated by Tobias Brunner over 6 years ago

#4 Updated by Sebastian Krebs over 6 years ago

#5 Updated by Sebastian Krebs over 6 years ago

#6 Updated by Tobias Brunner over 6 years ago