topic Re: Keyring not found when using hostname in Network Security

Keyring not found when using hostname

dodgerfan78 — Tue, 28 Feb 2023 14:19:39 GMT

I am trying to build an ipsec tunnel in IOS XE 17.6.3 using hostname but I get a keyring not found error. Is there a way to do this without having to use the IP?

Non-working:

crypto ikev2 keyring zscaler-keyring
peer zscaler-peer
hostname sea1-vpn.zscaler.net
pre-shared-key hgjgjhgjhgjgjhgjhgjhghjg
!

Error:

*Feb 28 14:11:02.888: IKEv2-ERROR:(SESSION ID = 0,SA ID = 0):% key not found.
*Feb 28 14:11:02.888: IKEv2-ERROR:(SESSION ID = 0,SA ID = 0):Failed to initiate sa

If I use an IP then this works. I think the issue may be when I specify the hostname in the Tunnel interface, IOS will translate this to an IP:

interface Tunnel10
description vrf10tunneltoZscaler
vrf forwarding 10
ip unnumbered GigabitEthernet3
ip mtu 1500
tunnel source GigabitEthernet3
tunnel mode ipsec ipv4
tunnel destination 165.225.50.10 <--- configured with hostname but gets changed to an IP by IOS
tunnel path-mtu-discovery
tunnel vrf 10
tunnel protection ipsec profile zscaler-ipsec-profile

Any ideas?

Thanks,

Re: Keyring not found when using hostname

MHM Cisco World — Tue, 28 Feb 2023 14:45:24 GMT

you need to use fvrf 10 since your tunnel source is in VRF 10

Re: Keyring not found when using hostname

Rob Ingram — Tue, 28 Feb 2023 20:36:59 GMT

@dodgerfan78 From the Cisco IKEv2 book - "The key lookup by peer hostname is performed only by the hostname string and not by its resolved address, as address resolution is not performed during the lookup. The key lookup by peer hostname has very limited use; although the key lookup by peer hostname can be performed on an initiator, specifying the IKE/IPsec peer as a hostname is possible only with crypto map configuration by use of the set peer hostname dynamic command and not with a tunnel interface configuration."

How about specifying an FQDN as the identity on the initator and match on this identity in the keyring on the responder.

# Initiator

crypto ikev2 keyring KEY
 peer 1
 address 1.1.1.1
 pre-shared-key local Cisco1234
 pre-shared-key remote Cisco1234
!
crypto ikev2 profile IKEV2-PROFILE
 match fvrf WAN
 match identity remote any
 identity local fqdn branch-1.lab.local
 authentication remote pre-share
 authentication local pre-share
 keyring local KEY

# Responder

crypto ikev2 keyring KEY
 peer 4
 identity fqdn branch-1.lab.local
 pre-shared-key local Cisco1234
 pre-shared-key remote Cisco1234
!
crypto ikev2 profile IKEV2-PROFILE
 match fvrf WAN
 match identity remote fqdn domain lab.local
 identity local address 1.1.1.1
 keyring local KEY

Therefore the responder needs only match on the sent identity FQDN of the spoke router (initiator), not the IP address.