Project

General

Profile

Issue #3536

When Create multiple tunnels restart ipsec service will establish fail.

Added by ray chao about 2 months ago. Updated 18 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.9.0
Resolution:

Description

When Create multiple IPSec tunnels with the following config between two DUT will establish success.
Then Modify config like Hash, Encryption algorithm, dpd... on any tunnel and restart ipsec service.

Restart device will connect successfully first, but when modify some config value and restart ipsec will establish fail.

#####################################

/etc/ipsec.secrets 
10.10.10.11 10.10.10.10 : PSK "111111" 
10.10.10.11 10.10.10.10 : PSK "111111" 
10.10.10.11 10.10.10.10 : PSK "111111" 
10.10.10.11 10.10.10.10 : PSK "111111" 

config setup
conn test
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.127.0/24
 rightsubnet=192.168.128.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp768
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test2
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.126.0/24
 rightsubnet=192.168.129.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test3
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.125.0/24
 rightsubnet=192.168.130.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test4
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.124.0/24
 rightsubnet=192.168.131.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn any_wan0
 left=10.10.10.11
 leftsourceip=10.10.10.11
 right=%any

###################################################

/etc/ipsec.secrets 
10.10.10.10 10.10.10.11 : PSK "111111" 
10.10.10.10 10.10.10.11 : PSK "111111" 
10.10.10.10 10.10.10.11 : PSK "111111" 
10.10.10.10 10.10.10.11 : PSK "111111" 

config setup
conn test
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.128.0/24
 rightsubnet=192.168.127.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp768
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test2
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.129.0/24
 rightsubnet=192.168.126.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test3
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.130.0/24
 rightsubnet=192.168.125.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test4
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.131.0/24
 rightsubnet=192.168.124.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=9m
 rekeyfuzz=100%
 keyingtries=%forever
 keyexchange=ikev1
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp1024
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn any_wan0
 left=10.10.10.10
 leftsourceip=10.10.10.10
 right=%any
###################################################

I got the ipsec status in attach file,and use statusall command

ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.1, Linux 4.14.76-15.0.0, aarch64):
  uptime: 17 minutes, since Aug 06 19:04:45 2020
  malloc: sbrk 2560000, mmap 0, used 601984, free 1958016
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
  loaded plugins: charon pkcs11 aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem af-alg fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown xauth-generic led counters
Listening IP addresses:
  10.10.10.10
Connections:
        test:  10.10.10.10...10.10.10.11  IKEv1, dpddelay=30s
        test:   local:  [10.10.10.10] uses pre-shared key authentication
        test:   remote: [10.10.10.11] uses pre-shared key authentication
        test:   child:  192.168.128.0/24 === 192.168.127.0/24 TUNNEL, dpdaction=restart
       test2:  10.10.10.10...10.10.10.11  IKEv1, dpddelay=30s
       test2:   local:  [10.10.10.10] uses pre-shared key authentication
       test2:   remote: [10.10.10.11] uses pre-shared key authentication
       test2:   child:  192.168.129.0/24 === 192.168.126.0/24 TUNNEL, dpdaction=restart
       test3:   child:  192.168.130.0/24 === 192.168.125.0/24 TUNNEL, dpdaction=restart
       test4:   child:  192.168.131.0/24 === 192.168.124.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
        test[3]: ESTABLISHED 14 minutes ago, 10.10.10.10[10.10.10.10]...10.10.10.11[10.10.10.11]
        test[3]: IKEv1 SPIs: d8258d6b36c0c593_i d18ae02e2e2d8617_r*, pre-shared key reauthentication in 34 minutes
        test[3]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_768
        test{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8023e73_i c7902fc7_o
        test{1}:  3DES_CBC/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
        test{1}:   192.168.128.0/24 === 192.168.127.0/24

Restart device will connect successfully first, but when modify some config value and restart ipsec will establish fail.
I can't recognize where the fail is!! Why test1 to test4 cann't successfully established.

192.168.127.254charon.log (386 KB) 192.168.127.254charon.log ray chao, 06.08.2020 13:21
192.168.128.254charon.log (350 KB) 192.168.128.254charon.log ray chao, 06.08.2020 13:21

History

#1 Updated by ray chao about 1 month ago

There have some message
no matching CHILD_SA config found for 192.168.124.0/24 === 192.168.131.0/24
no matching CHILD_SA config found for 192.168.125.0/24 === 192.168.130.0/24
no matching CHILD_SA config found for 192.168.126.0/24 === 192.168.129.0/24

Is there config setting error or other reasons cause the error?

#2 Updated by Tobias Brunner about 1 month ago

  • Status changed from New to Feedback

Is there config setting error or other reasons cause the error?

Most likely a config error (the most obvious one is that you use IKEv1).

#3 Updated by ray chao about 1 month ago

Excluding the difference in ike version,I can't found the other configure error,
When i use IKEV2 the issue still happen,So is there anything else I can check and analysis this multi-tunnel issue.

#4 Updated by Tobias Brunner about 1 month ago

When i use IKEV2 the issue still happen,So is there anything else I can check and analysis this multi-tunnel issue.

With IKEv2 you don't have to use separate CHILD_SAs for multiple subnets (unless you really only want to allow traffic between selected subnets). Anyway, read the logs and think hard about what you are actually doing and whether it makes sense.

#5 Updated by ray chao about 1 month ago

Yes,I have this situation requirement to create multi-tunnel,

I found the initiator have the error message:

received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA

and responder have the error message:

parsed CREATE_CHILD_SA response 2 [ N(TS_UNACCEPT) ]
received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA

What could cause this abnormal situation?

#6 Updated by Tobias Brunner 28 days ago

I found the initiator have the error message:
[...]

and responder have the error message:
[...]

You receive TS_UNACCEPTABLE on both ends? More important is where and why these notifies are sent (try log level 2 for cfg to see details about the traffic selector negotiation).

#7 Updated by ray chao 25 days ago

I found the responder will generating TS_UNACCEPT notify to initiator,the follow log is a part of strongswan.log
Other tunnel are the same,when want to establish 192.168.129.0/24 === 192.168.126.0/24
log show:

proposing traffic selectors for us:
Aug 27 16:25:22 15[CFG] <test|1>  192.168.128.0/24
Aug 27 16:25:22 15[CFG] <test|1> proposing traffic selectors for other:
Aug 27 16:25:22 15[CFG] <test|1>  192.168.127.0/24
Aug 27 16:25:22 15[IKE] <test|1> traffic selectors 192.168.129.0/24 === 192.168.126.0/24 unacceptable

The all strongswan log:

...
Aug 27 16:25:22 15[ENC] <test|1> parsed CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]
Aug 27 16:25:22 15[LIB] <test|1> size of DH secret exponent: 2045 bits
Aug 27 16:25:22 15[CFG] <test|1> looking for a child config for 192.168.129.0/24 === 192.168.126.0/24
Aug 27 16:25:22 15[CFG] <test|1> proposing traffic selectors for us:
Aug 27 16:25:22 15[CFG] <test|1>  192.168.128.0/24
Aug 27 16:25:22 15[CFG] <test|1> proposing traffic selectors for other:
Aug 27 16:25:22 15[CFG] <test|1>  192.168.127.0/24
Aug 27 16:25:22 15[IKE] <test|1> traffic selectors 192.168.129.0/24 === 192.168.126.0/24 unacceptable
Aug 27 16:25:22 15[ENC] <test|1> added payload of type NOTIFY to message
Aug 27 16:25:22 15[IKE] <test|1> failed to establish CHILD_SA, keeping IKE_SA
Aug 27 16:25:22 15[ENC] <test|1> order payloads in message
Aug 27 16:25:22 15[ENC] <test|1> added payload of type NOTIFY to message
Aug 27 16:25:22 15[ENC] <test|1> generating CREATE_CHILD_SA response 2 [ N(TS_UNACCEPT) ]
Aug 27 16:25:22 15[ENC] <test|1> insert payload NOTIFY into encrypted payload
...

#8 Updated by Tobias Brunner 25 days ago

I guess the wrong config is selected. Why did you configure modp768 for test? (The other configs use modp1024. Note that both DH groups should not be used anymore because they are too weak.) Did you consider using the also keyword?

#9 Updated by ray chao 23 days ago

Yes,i also use modp2048 and "also" keyword but still have the same result.

config setup
conn test
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.127.0/24
 rightsubnet=192.168.128.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
conn test2
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.126.0/24
 rightsubnet=192.168.129.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test3
conn test3
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.125.0/24
 rightsubnet=192.168.130.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test4
conn test4
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.124.0/24
 rightsubnet=192.168.131.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test
conn any_wan0
 left=10.10.10.11
 leftsourceip=10.10.10.11
 right=%any

#10 Updated by Tobias Brunner 21 days ago

Yes,i also use modp2048 and "also" keyword but still have the same result.

You did that incorrectly. The whole point of using also is to avoid redundancies and potential errors when manually duplicating settings.

#11 Updated by ray chao 21 days ago

Tobias Brunner wrote:

Yes,i also use modp2048 and "also" keyword but still have the same result.

You did that incorrectly. The whole point of using also is to avoid redundancies and potential errors when manually duplicating settings.

OK,when i seprate up tunnel (ipsec up test;ipsec up test2;ipsec up test3;ipsec up test4;) can establish success.After some times there is only one connection left.
log

Aug 31 18:19:23 09[ENC] <test2|2> starting parsing a ENCRYPTED payload                          
Aug 31 18:19:23 09[ENC] <test2|2> parsing ENCRYPTED payload, 40 bytes left                      
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 0 U_INT_8                                      Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 1 U_INT_8                                      Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 2 PAYLOAD_LENGTH                               Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 3 CHUNK_DATA                                   Aug 31 18:19:23 09[ENC] <test2|2> parsing ENCRYPTED payload finished                            
Aug 31 18:19:23 09[ENC] <test2|2> verifying payload of type ENCRYPTED                           
Aug 31 18:19:23 09[ENC] <test2|2> ENCRYPTED payload verified, adding to payload list            
Aug 31 18:19:23 09[ENC] <test2|2> ENCRYPTED payload found, stop parsing                         
Aug 31 18:19:23 09[ENC] <test2|2> process payload of type ENCRYPTED                             
Aug 31 18:19:23 09[ENC] <test2|2> found an encrypted payload                                    
Aug 31 18:19:23 09[ENC] <test2|2> parsing DELETE payload, 8 bytes left                          
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 0 U_INT_8                                      
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 1 FLAG                                         
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 2 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 3 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 4 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 5 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 6 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 7 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 8 RESERVED_BIT                                 
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 9 PAYLOAD_LENGTH                               
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 10 U_INT_8                                     
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 11 U_INT_8                                     
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 12 U_INT_16                                    
Aug 31 18:19:23 09[ENC] <test2|2>   parsing rule 13 CHUNK_DATA                                  
Aug 31 18:19:23 09[ENC] <test2|2> parsing DELETE payload finished                               
Aug 31 18:19:23 09[ENC] <test2|2> parsed content of encrypted payload                           
Aug 31 18:19:23 09[ENC] <test2|2> insert decrypted payload of type DELETE at end of list        
Aug 31 18:19:23 09[ENC] <test2|2> verifying message structure                                   
Aug 31 18:19:23 09[ENC] <test2|2> found payload of type DELETE                                  
Aug 31 18:19:23 09[ENC] <test2|2> parsed INFORMATIONAL request 0 [ D ]                          
Aug 31 18:19:23 09[IKE] <test2|2> received DELETE for IKE_SA test2[2]                           
Aug 31 18:19:23 09[IKE] <test2|2> deleting IKE_SA test2[2] between 10.10.10.10[10.10.10.10]...10
Aug 31 18:19:23 09[IKE] <test2|2> IKE_SA test2[2] state change: ESTABLISHED => DELETING         
Aug 31 18:19:23 09[IKE] <test2|2> IKE_SA deleted                                                
Aug 31 18:19:23 09[ENC] <test2|2> order payloads in message                                     
Aug 31 18:19:23 09[ENC] <test2|2> generating INFORMATIONAL response 0 [ ]                       
Aug 31 18:19:23 09[ENC] <test2|2> generating payload of type HEADER      

Aug 31 18:19:23 12[ENC] <test|2> verifying payload of type ENCRYPTED                            
Aug 31 18:19:23 12[ENC] <test|2> ENCRYPTED payload verified, adding to payload list             
Aug 31 18:19:23 12[ENC] <test|2> ENCRYPTED payload found, stop parsing                          
Aug 31 18:19:23 12[ENC] <test|2> process payload of type ENCRYPTED                              
Aug 31 18:19:23 12[ENC] <test|2> found an encrypted payload                                     
Aug 31 18:19:23 12[ENC] <test|2> parsed content of encrypted payload                            
Aug 31 18:19:23 12[ENC] <test|2> verifying message structure                                    
Aug 31 18:19:23 12[ENC] <test|2> parsed INFORMATIONAL response 0 [ ]                            
Aug 31 18:19:23 12[IKE] <test|2> IKE_SA deleted                                                 
Aug 31 18:19:23 12[MGR] <test|2> checkin and destroy IKE_SA test[2]                             
Aug 31 18:19:23 12[IKE] <test|2> IKE_SA test[2] state change: DELETING => DESTROYING            
Aug 31 18:19:23 12[CHD] <test|2> CHILD_SA test4{7} state change: INSTALLED => DESTROYING        
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.124.0/24 === 192.168.131.0/24 out      
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.131.0/24 === 192.168.124.0/24 in       
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.131.0/24 === 192.168.124.0/24 fwd      
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI c8931d79                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI c8931d79                            
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI c5644cf7                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI c5644cf7                            
Aug 31 18:19:23 12[CHD] <test|2> CHILD_SA test3{6} state change: INSTALLED => DESTROYING        
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.125.0/24 === 192.168.130.0/24 out      
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.130.0/24 === 192.168.125.0/24 in       
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.130.0/24 === 192.168.125.0/24 fwd      
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI c83bf86f                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI c83bf86f                            
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI c1b74719                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI c1b74719                            
Aug 31 18:19:23 12[CHD] <test|2> CHILD_SA test2{5} state change: INSTALLED => DESTROYING        
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.127.0/24 === 192.168.128.0/24 out      
Aug 31 18:19:23 12[KNL] <test|2> getting iface index for WAN                                    
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.128.0/24 === 192.168.127.0/24 in       
Aug 31 18:19:23 12[KNL] <test|2> deleting policy 192.168.128.0/24 === 192.168.127.0/24 fwd      
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI cafb9f07                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI cafb9f07                            
Aug 31 18:19:23 12[KNL] <test|2> deleting SAD entry with SPI c07b113f                           
Aug 31 18:19:23 12[KNL] <test|2> deleted SAD entry with SPI c07b113f                            
Aug 31 18:19:23 12[MGR] checkin and destroy of IKE_SA successful                                
Aug 31 18:19:23 06[JOB] watched FD 15 ready to read                                             
Aug 31 18:19:23 06[JOB] watcher going to poll() 4 fds                                           
Aug 31 18:19:23 06[JOB] watcher got notification, rebuilding                                    
Aug 31 18:19:23 06[JOB] watcher going to poll() 5 fds                                           
Aug 31 18:19:27 01[JOB] got event, queuing job for execution                                    
Aug 31 18:19:27 01[JOB] next event in 8s 763ms, waiting                                         
Aug 31 18:19:27 10[MGR] checkout IKEv2 SA with SPIs 0d747190de4783df_i 2a1b1d3466386d9b_r       
Aug 31 18:19:27 10[MGR] IKE_SA checkout not successful                                          
Aug 31 18:19:27 06[JOB] watched FD 16 ready to read                                             
Aug 31 18:19:27 06[JOB] watcher going to poll() 4 fds                                   

I study more issue related "received TS_UNACCEPTABLE notify, no CHILD_SA built" and watch the strongswan log, but still no clue on this issue analysis.

#12 Updated by Tobias Brunner 21 days ago

After some times there is only one connection left.
log

The log just shows the delete of an IKE_SA, nothing wrong with that. Maybe read the log on the remote end to see why it was sent.

I study more issue related "received TS_UNACCEPTABLE notify, no CHILD_SA built" and watch the strongswan log, but still no clue on this issue analysis.

You need to read the log on the end that sends the notify, not the one that logs the message above after it received the notify.

#13 Updated by ray chao 19 days ago

Yes,I have read the log on the responder,and found the log only show
"traffic selectors 192.168.128.0/24 === 192.168.127.0/24 unacceptable".

Could this connection be TS block or disconnect from the log display?

06[CFG] <test|1> looking for a child config for 192.168.128.0/24 === 192.168.127.0/24
06[CFG] <test|1> proposing traffic selectors for us:
06[CFG] <test|1> 192.168.129.0/24
06[CFG] <test|1> proposing traffic selectors for other:
06[CFG] <test|1> 192.168.126.0/24
06[IKE] <test|1> traffic selectors 192.168.128.0/24 === 192.168.127.0/24 unacceptable
06[ENC] <test|1> added payload of type NOTIFY to message
06[IKE] <test|1> failed to establish CHILD_SA, keeping IKE_SA

Maybe i want to trace the source code to find out why this message is printed?
It's seems not Select a matching CHILD config as responder,but i don't why.
child_create.c:

    if (this->config == NULL)
    {
        this->config = select_child_cfg(this);
    }
    if (this->config == NULL)
    {
        DBG1(DBG_IKE, "traffic selectors %#R === %#R unacceptable",
             this->tsr, this->tsi);
        charon->bus->alert(charon->bus, ALERT_TS_MISMATCH, this->tsi, this->tsr);
        message->add_notify(message, FALSE, TS_UNACCEPTABLE, chunk_empty);
        handle_child_sa_failure(this, message);
        return SUCCESS;
    }

Responder insert [ N(TS_UNACCEPT) ] payload NOTIFY into encrypted payload log:

Sep  2 15:35:28 06[ENC] <test|1> verifying message structure
Sep  2 15:35:28 06[ENC] <test|1> found payload of type SECURITY_ASSOCIATION
Sep  2 15:35:28 06[ENC] <test|1> found payload of type NONCE
Sep  2 15:35:28 06[ENC] <test|1> found payload of type KEY_EXCHANGE
Sep  2 15:35:28 06[ENC] <test|1> found payload of type TS_INITIATOR
Sep  2 15:35:28 06[ENC] <test|1> found payload of type TS_RESPONDER
Sep  2 15:35:28 06[ENC] <test|1> parsed CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]
Sep  2 15:35:28 06[LIB] <test|1> size of DH secret exponent: 2047 bits
Sep  2 15:35:28 06[CFG] <test|1> looking for a child config for 192.168.128.0/24 === 192.168.127.0/24
Sep  2 15:35:28 06[CFG] <test|1> proposing traffic selectors for us:
Sep  2 15:35:28 06[CFG] <test|1>  192.168.129.0/24
Sep  2 15:35:28 06[CFG] <test|1> proposing traffic selectors for other:
Sep  2 15:35:28 06[CFG] <test|1>  192.168.126.0/24
Sep  2 15:35:28 06[IKE] <test|1> traffic selectors 192.168.128.0/24 === 192.168.127.0/24 unacceptable
Sep  2 15:35:28 06[ENC] <test|1> added payload of type NOTIFY to message
Sep  2 15:35:28 06[IKE] <test|1> failed to establish CHILD_SA, keeping IKE_SA
Sep  2 15:35:28 06[ENC] <test|1> order payloads in message
Sep  2 15:35:28 06[ENC] <test|1> added payload of type NOTIFY to message
Sep  2 15:35:28 06[ENC] <test|1> generating CREATE_CHILD_SA response 2 [ N(TS_UNACCEPT) ]
Sep  2 15:35:28 06[ENC] <test|1> insert payload NOTIFY into encrypted payload

#14 Updated by Tobias Brunner 18 days ago

Did you adapt the responder config accordingly? If the selected peer config has no matching child config, this obviously won't work.

#15 Updated by ray chao 18 days ago

Sorry,I'm not sure what you mean. Do you mean the every connection config need match at responder and initiator?
The responder and initiator config as listed below.The connection config are one-to-one mapping and is there have any setting incorrect?

initiator config:

config setup
conn test
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.126.0/24
 rightsubnet=192.168.129.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=hold
conn test2
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.127.0/24
 rightsubnet=192.168.128.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=hold
 also=test3
conn test3
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.125.0/24
 rightsubnet=192.168.130.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test4
conn test4
 aggressive=no
 authby=secret
 left=10.10.10.11
 right=10.10.10.10
 leftsubnet=192.168.124.0/24
 rightsubnet=192.168.131.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=start
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test
conn any_wan0
 left=10.10.10.11
 leftsourceip=10.10.10.11
 right=%any

responder config

config setup
conn test
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.129.0/24
 rightsubnet=192.168.126.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=3m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=hold
conn test2
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.128.0/24
 rightsubnet=192.168.127.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=hold
conn test3
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.130.0/24
 rightsubnet=192.168.125.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test4
conn test4
 aggressive=no
 authby=secret
 left=10.10.10.10
 right=10.10.10.11
 leftsubnet=192.168.131.0/24
 rightsubnet=192.168.124.0/24
 type=tunnel
 esp=3des-sha1-modp2048
 rekeymargin=2m
 rekeyfuzz=1%
 keyingtries=%forever
 keyexchange=ikev2
 ikelifetime=1h
 keylife=480m
 ike=3des-sha1-modp2048
 auto=add
 dpddelay=30
 dpdtimeout=120
 dpdaction=restart
 also=test
conn any_wan0
 left=10.10.10.10
 leftsourceip=10.10.10.10
 right=%any

#16 Updated by Tobias Brunner 18 days ago

Do you mean the every connection config need match at responder and initiator?

You obviously need matching configs, whether that means matching conn sections depends. Check the status output to see if matching configs are loaded.

The responder and initiator config as listed below.The connection config are one-to-one mapping and is there have any setting incorrect?

Didn't you switch to using the also keyword to remove all this redundancy and avoid mistakes? Because your configs test and testX use a different rekeymargin setting. This results in multiple ike/peer configs (due to the default proposal, the responder can use either) with different child configs attached.

By the way, using swanctl.conf makes the relationship between IKE and CHILD_SA configs a lot clearer.

#17 Updated by ray chao 18 days ago

I modified all the conn settings so that the rekeymargin is the same. After restart ipsec, all conn can be established normally.

The description mentioned above:

..,Because your configs _test_ and _testX_ use a different _rekeymargin_ setting. This results in multiple ike/peer configs (due to the default proposal, the responder can use either) with different child configs attached.

It's means the responder can choose either proposal in the same wan ip config?
Responder choose rekeymargin=3 to create child is different other initiator rekeymargin=2 so that connection could not be established?
So when i use multiple subnets scenario all subnet config must be a restriction that all proposals must be same?

#18 Updated by Tobias Brunner 18 days ago

It's means the responder can choose either proposal in the same wan ip config?

I was actually referring to the original issue with the different DH groups in the proposals, not the rekeymargin, which is not negotiated (it will still cause the configs not to match and the child configs get attached to different peer/ike configs).

So when i use multiple subnets scenario all subnet config must be a restriction that all proposals must be same?

All child configs have to be attached to the same IKE/peer config for this to work (you see that that was not the case in the status output you originally posted).

Also available in: Atom PDF