Project

General

Profile

Issue #3517

Packets not transfered when ipsec up <conn name> was given on remote host with mode as transport

Added by Sowmya Pola 2 months ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.1.3
Resolution:

Description

1. We were able to establish ipsec connection in transport mode but packets(traffic) were not transferred when ipsec up <conn name> was given on remote host(client).

2. If we use same ipsec up <conn name > on the server we can see packets transfer in ipsec statusall command. However in this case too we observed that connection is established in tunnel mode, even if transport mode is used while defining ipsec policy.

Below is the log for the same:
Connections:
connPKI: 10.33.41.174...10.35.15.167 IKEv2
connPKI: local: [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
connPKI: cert: "C=IN, O=strongSwan, CN=IPSEC"
connPKI: remote: [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
connPKI: child: 10.33.41.0/24 === 10.35.15.0/24 TRANSPORT
Security Associations (1 up, 0 connecting):
connPKI1: ESTABLISHED 12 seconds ago, 10.33.41.174[C=IN, O=strongSwan, CN=IPSEC]...10.35.15.167[C=IN, O=strongSwan, CN=IPSEC]
connPKI1: IKEv2 SPIs: 4dd26929a6d957c4_i* 4e8eacaf6eccc7c7_r, public key reauthentication in 33 minutes
connPKI1: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096
connPKI{1}: INSTALLED, TUNNEL, ESP SPIs: c2b149ab_i ca7222c4_o
connPKI{1}: AES_CBC_256/HMAC_SHA2_512_256, 4696 bytes_i (103 pkts, 10s ago), 1080120 bytes_o (787 pkts, 10s ago), rekeying in 44 minutes
connPKI{1}: 10.33.41.0/24 === 10.35.15.167/32

ipsec_statusall_on_node.txt file attached here shows the complete log of connection.

Could you please help us understand the behavior in these two cases.

ipsec_conf_on_remotehost.txt (393 Bytes) ipsec_conf_on_remotehost.txt ipsec.conf file on remote host Sowmya Pola, 15.07.2020 09:07
ipsec_conf_on_node.txt (383 Bytes) ipsec_conf_on_node.txt ipsec.conf file on server Sowmya Pola, 15.07.2020 09:07
ipsec_logs_on_node.txt (4.79 KB) ipsec_logs_on_node.txt ipsec logs on server Sowmya Pola, 15.07.2020 09:07
ipsec_statusall_on_node.txt (2.09 KB) ipsec_statusall_on_node.txt ipsec statusall on server Sowmya Pola, 15.07.2020 09:07
ipsec_statusall_on_remote_host.txt (4.32 KB) ipsec_statusall_on_remote_host.txt ipsec statusall on remote host Sowmya Pola, 15.07.2020 09:07

History

#1 Updated by Tobias Brunner 2 months ago

  • Category set to configuration
  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

connPKI: child: 10.33.41.0/24 === 10.35.15.0/24 TRANSPORT

This is obviously not a valid config (you can't tunnel subnets using transport mode). (You can configure it and use it for dynamic trap policies, but you can't negotiate such a traffic selector with transport mode, there will automatically be a fallback to tunnel mode if anything but /32 or /128 is negotiated.)

#2 Updated by Sowmya Pola 2 months ago

Tobias Brunner wrote:

connPKI: child: 10.33.41.0/24 === 10.35.15.0/24 TRANSPORT

This is obviously not a valid config (you can't tunnel subnets using transport mode). (You can configure it and use it for dynamic trap policies, but you can't negotiate such a traffic selector with transport mode, there will automatically be a fallback to tunnel mode if anything but /32 or /128 is negotiated.)

Thanks for the information.
I have few more queries regarding this.
With the same configuration if I try to create an Security Association(using ipsec up) from remote host(client) I don't see fallback to tunnel mode.
Does it make any difference if we create a security association from client side?

administrator@tp433vapz053lbat1:~$ sudo ipsec up policyPSK
initiating IKE_SA policyPSK[1] to 10.33.41.174
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 10.35.15.167[500] to 10.33.41.174[500] (1386 bytes)
received packet: from 10.33.41.174[500] to 10.35.15.167[500] (696 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096
sending cert request for "C=IN, O=strongSwan, CN=strongSwan Root CA" 
authentication of '10.35.15.167' (myself) with pre-shared key
establishing CHILD_SA policyPSK{1}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 10.35.15.167[4500] to 10.33.41.174[4500] (496 bytes)
received packet: from 10.33.41.174[4500] to 10.35.15.167[4500] (384 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(USE_TRANSP) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
authentication of '10.33.41.174' with pre-shared key successful
IKE_SA policyPSK[1] established between 10.35.15.167[10.35.15.167]...10.33.41.174[10.33.41.174]
scheduling reauthentication in 2830s
maximum IKE_SA lifetime 3370s
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ
CHILD_SA policyPSK{1} established with SPIs c8d5fad3_i cc126731_o and TS 10.35.15.167/32 === 10.33.41.174/32
received AUTH_LIFETIME of 3033s, scheduling reauthentication in 2493s
connection 'policyPSK' established successfully

administrator@tp433vapz053lbat1:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.1, Linux 5.0.0-38-generic, x86_64):
  uptime: 33 seconds, since Jul 21 04:38:52 2020
  malloc: sbrk 2306048, mmap 0, used 654384, free 1651664
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  10.35.15.167
  2001:1b70:8294:4700:20c:29ff:fe8e:2121
  2001:1b70:8294:4700::167
Connections:
      policy:  10.35.15.167...10.33.41.174  IKEv2
      policy:   local:  [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:    cert:  "C=IN, O=strongSwan, CN=IPSEC" 
      policy:   remote: [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:   child:  dynamic === 10.33.41.0/32 TRANSPORT
   policyPSK:  10.35.15.167...10.33.41.174  IKEv2
   policyPSK:   local:  [10.35.15.167] uses pre-shared key authentication
   policyPSK:   remote: [10.33.41.174] uses pre-shared key authentication
   policyPSK:   child:  10.35.15.0/24 === 10.33.41.0/24 TRANSPORT
Security Associations (1 up, 0 connecting):
   policyPSK[1]: ESTABLISHED 14 seconds ago, 10.35.15.167[10.35.15.167]...10.33.41.174[10.33.41.174]
   policyPSK[1]: IKEv2 SPIs: 3b9d8d0afb5297b4_i* 70bbf347b94b436d_r, pre-shared key reauthentication in 41 minutes
   policyPSK[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096
   policyPSK{1}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c8d5fad3_i cc126731_o
   policyPSK{1}:  AES_CBC_256/HMAC_SHA2_512_256, 0 bytes_i, 0 bytes_o, rekeying in 44 minutes
   policyPSK{1}:   10.35.15.167/32 === 10.33.41.174/32
administrator@tp433vapz053lbat1:~$ 
administrator@tp433vapz053lbat1:~$ 
administrator@tp433vapz053lbat1:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.1, Linux 5.0.0-38-generic, x86_64):
  uptime: 37 seconds, since Jul 21 04:38:52 2020
  malloc: sbrk 2441216, mmap 0, used 661472, free 1779744
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  10.35.15.167
  2001:1b70:8294:4700:20c:29ff:fe8e:2121
  2001:1b70:8294:4700::167
Connections:
      policy:  10.35.15.167...10.33.41.174  IKEv2
      policy:   local:  [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:    cert:  "C=IN, O=strongSwan, CN=IPSEC" 
      policy:   remote: [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:   child:  dynamic === 10.33.41.0/32 TRANSPORT
   policyPSK:  10.35.15.167...10.33.41.174  IKEv2
   policyPSK:   local:  [10.35.15.167] uses pre-shared key authentication
   policyPSK:   remote: [10.33.41.174] uses pre-shared key authentication
   policyPSK:   child:  10.35.15.0/24 === 10.33.41.0/24 *TRANSPORT*
Security Associations (1 up, 0 connecting):
   policyPSK[1]: ESTABLISHED 18 seconds ago, 10.35.15.167[10.35.15.167]...10.33.41.174[10.33.41.174]
   policyPSK[1]: IKEv2 SPIs: 3b9d8d0afb5297b4_i* 70bbf347b94b436d_r, pre-shared key reauthentication in 41 minutes
   policyPSK[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096
   policyPSK{1}:  *INSTALLED, TRANSPORT,* reqid 1, ESP SPIs: c8d5fad3_i cc126731_o
   policyPSK{1}:  AES_CBC_256/HMAC_SHA2_512_256, 0 bytes_i, 0 bytes_o, rekeying in 44 minutes
   policyPSK{1}:   10.35.15.167/32 === 10.33.41.174/32

administrator@tp433vapz053lbat1:~$ ping 10.33.41.174
PING 10.33.41.174 (10.33.41.174) 56(84) bytes of data.
64 bytes from 10.33.41.174: icmp_seq=1 ttl=60 time=0.213 ms
64 bytes from 10.33.41.174: icmp_seq=2 ttl=60 time=0.258 ms
64 bytes from 10.33.41.174: icmp_seq=3 ttl=60 time=0.265 ms
64 bytes from 10.33.41.174: icmp_seq=4 ttl=60 time=0.274 ms
^C
--- 10.33.41.174 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 58ms
rtt min/avg/max/mdev = 0.213/0.252/0.274/0.028 ms

administrator@tp433vapz053lbat1:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.1, Linux 5.0.0-38-generic, x86_64):
  uptime: 80 seconds, since Jul 21 04:38:52 2020
  malloc: sbrk 2441216, mmap 0, used 667600, free 1773616
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  10.35.15.167
  2001:1b70:8294:4700:20c:29ff:fe8e:2121
  2001:1b70:8294:4700::167
Connections:
      policy:  10.35.15.167...10.33.41.174  IKEv2
      policy:   local:  [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:    cert:  "C=IN, O=strongSwan, CN=IPSEC" 
      policy:   remote: [C=IN, O=strongSwan, CN=IPSEC] uses public key authentication
      policy:   child:  dynamic === 10.33.41.0/32 TRANSPORT
   policyPSK:  10.35.15.167...10.33.41.174  IKEv2
   policyPSK:   local:  [10.35.15.167] uses pre-shared key authentication
   policyPSK:   remote: [10.33.41.174] uses pre-shared key authentication
   policyPSK:   child:  10.35.15.0/24 === 10.33.41.0/24 *TRANSPORT*
Security Associations (1 up, 0 connecting):
   policyPSK[1]: ESTABLISHED 61 seconds ago, 10.35.15.167[10.35.15.167]...10.33.41.174[10.33.41.174]
   policyPSK[1]: IKEv2 SPIs: 3b9d8d0afb5297b4_i* 70bbf347b94b436d_r, pre-shared key reauthentication in 40 minutes
   policyPSK[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096
   policyPSK{1}:  *INSTALLED, TRANSPORT,* reqid 1, ESP SPIs: c8d5fad3_i cc126731_o
   policyPSK{1}:  AES_CBC_256/HMAC_SHA2_512_256, 256 bytes_i *(4 pkts, 6s ago), 256 bytes_o (4 pkts, 6s ago)*, rekeying in 43 minutes
   policyPSK{1}:   10.35.15.167/32 === 10.33.41.174/32
administrator@tp433vapz053lbat1:~$ 

#3 Updated by Tobias Brunner 2 months ago

With the same configuration if I try to create an Security Association(using ipsec up) from remote host(client) I don't see fallback to tunnel mode.

Because /32 traffic selectors are negotiated (either due to narrowing or because only that is proposed). Read the logs to see why (increase the log level for cfg to 2 to see more about the traffic selector negotiation).

Does it make any difference if we create a security association from client side?

Depends on the config.

Also available in: Atom PDF