Issue #3649
IKEv2 in transport mode with Cisco
Description
I need an IKEv2 connection in transport mode between Strongswan and Cisco. Cisco is a responder and has a public IP. A device with Strongswan is an initiator and has a non-public IP (it is behind NAT). I got a TS_UNACCEPTABLE error. I think the reason is that remote = 176.102.144.34 and remote_proxy = 192.168.7.232 do not match. But I don't know the cause. I thought NAT-T(UDP Encapsulation of ESP) should solve this case.
IKEv1 works. In this case, remote and remote_proxy match. The status of IKEv1 is also shown below.
IKEv2 Strongswan:
... 2020-12-03 09:01:20 charon: 07[IKE] authentication of 'server.cisco' with RSA signature successful 2020-12-03 09:01:20 charon: 07[IKE] IKE_SA ipsec1[1] established between 192.168.7.232[client@router]...85.xx.xx.xx[server.cisco] 2020-12-03 09:01:20 charon: 07[IKE] scheduling reauthentication in 2710s 2020-12-03 09:01:20 charon: 07[IKE] maximum IKE_SA lifetime 3250s 2020-12-03 09:01:20 charon: 07[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built 2020-12-03 09:01:20 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA Connections: ipsec1: IKEv2, reauthentication every 3060s, no rekeying local: 0.0.0.0 remote: 85.xx.xx.xx local public key authentication: id: client@router certs: C=CZ, ST=Czechia, O=Advantech, OU=Advantech CZ, CN=client@router remote public key authentication: id: server.cisco certs: C=CZ, ST=Czechia, O=Advantech, OU=Advantech CZ, CN=server@cisco ipsec1: TRANSPORT, rekeying every 3060s local: dynamic[gre] remote: dynamic[gre] Security Associations: ipsec1: #1, ESTABLISHED, IKEv2, cf73d614a1f87d19_i* 57d19a5c22eb571b_r local 'client@router' @ 192.168.7.232[4500] remote 'server.cisco' @ 85.xx.xx.xx[4500] AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 established 8s ago, reauth in 2702s
IKEv2 Cisco:
*Dec 3 06:47:04.427: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] Verification of signed authentication data PASSED *Dec 3 06:47:04.427: IKEv2:(SA ID = 1):Processing INITIAL_CONTACT *Dec 3 06:47:04.427: IKEv2:(SA ID = 1):Processing IKE_AUTH message *Dec 3 06:47:04.427: IKEv2:KMI/verify policy/sending to IPSec: prot: 3 txfm: 20 hmac 0 flags 16370 keysize 256 IDB 0x0 *Dec 3 06:47:04.427: IPSEC(validate_proposal_request): proposal part #1 *Dec 3 06:47:04.427: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 85.xx.xx.xx:0, remote= 176.102.144.34:0, local_proxy= 85.xx.xx.xx/255.255.255.255/47/0, remote_proxy= 192.168.7.232/255.255.255.255/47/0, protocol= ESP, transform= esp-gmac 256 (Transport), lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0 *Dec 3 06:47:04.431: map_db_find_best did not find matching map *Dec 3 06:47:04.431: IPSEC(ipsec_process_proposal): proxy identities not supported *Dec 3 06:47:04.431: IKEv2:(SA ID = 1):There was no IPSEC policy found for received TS *Dec 3 06:47:04.431: IKEv2:(SA ID = 1): *Dec 3 06:47:04.431: IKEv2:(SA ID = 1):Sending TS unacceptable notify
IKEv1 Strongswan:
Connections: ipsec2: IKEv1, reauthentication every 3060s local: 0.0.0.0 remote: 85.xx.xx.xx local pre-shared key authentication: id: 192.168.7.232 remote pre-shared key authentication: ipsec2: TRANSPORT, rekeying every 3060s local: dynamic[gre] remote: dynamic[gre] Security Associations: ipsec2: #1, ESTABLISHED, IKEv1, 3eff54892e1406cc_i* 30161434b08159e4_r local '192.168.7.232' @ 192.168.7.232[4500] remote '85.xx.xx.xx' @ 85.xx.xx.xx[4500] 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 established 10s ago, rekeying in 2958s ipsec2: #1, reqid 1, INSTALLED, TRANSPORT-in-UDP, ESP:3DES_CBC/HMAC_MD5_96 installed 10s ago, rekeying in 2574s, expires in 3590s in cfb21598, 0 bytes, 0 packets out b50b8724, 0 bytes, 0 packets local 192.168.7.232/32[gre] remote 85.xx.xx.xx/32[gre]
IKEv1 Cisco
*Dec 3 07:14:51.787: ISAKMP:(2017):atts are acceptable. *Dec 3 07:14:51.787: IPSEC(validate_proposal_request): proposal part #1 *Dec 3 07:14:51.787: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 85.xx.xx.xx:0, remote= 176.102.144.34:0, local_proxy= 85.xx.xx.xx/255.255.255.255/47/0, remote_proxy= 176.102.144.34/255.255.255.255/47/0, protocol= ESP, transform= NONE (Transport-UDP), lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0 *Dec 3 07:14:51.791: [] -> [SADB Tunnel11-head-0:85.207.4.1]: message CM state change
Thanks
History
#1 Updated by Tobias Brunner 3 months ago
- Category set to interoperability
- Status changed from New to Feedback
I thought NAT-T(UDP Encapsulation of ESP) should solve this case.
No, that's unrelated. It's a problem with the traffic selector negotiation during IKE. For transport mode, the responder has to substitute the source address in the received traffic selectors (see section 2.23.1 in RFC 7296). If it doesn't do that, traffic selector negotiation will fail. Cisco might only do that for IKEv1. Alternatively, there could be a fallback to tunnel mode, but Cisco apparently doesn't do that either.
#2 Updated by Jiri Zendulka 26 days ago
I posted the issue on CISCO community.
https://community.cisco.com/t5/routing/ikev2-transport-mode-ts-unacceptable-error/td-p/4192725
Unfortunately, no answer with solution form CISCO yet.
As you wrote it is not strongswan's issue so you can close the issue.
#3 Updated by Tobias Brunner 26 days ago
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to No change required