Project

General

Profile

Issue #3649

IKEv2 in transport mode with Cisco

Added by Jiri Zendulka 12 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.8.4
Resolution:
No change required

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 12 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 10 months 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 10 months ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF