09-16-2025 07:35 AM - edited 09-16-2025 07:54 AM
Having a problem with a new site with the far end behind a firewall. Tunnel interface is up/up, routes are there but nothing is being encapsulated across the tunnel. I see decaps but no traffic passing from hub to spoke. I cannot ping the far end of the tunnel interface either which is a /30. I have no access to the far end currently (have the config file) so trying to make this work from the hub end but not having much luck.
I have other identical configs working without issue but this one is not and no idea why. Assuming a routing issue on the far end but I should at least be able to ping the far end of the tunnel 172.21.8.13 no?
Tunnel6 172.21.8.14 YES manual up up
interface Tunnel6 ip address 172.21.8.14 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/0/0 tunnel mode ipsec ipv4 tunnel destination 99.66.77.88 tunnel protection ipsec profile ikev2- end
Crypto map tag: Tunnel6-head-0, local addr 88.55.66.77 protected vrf: (none) local ident (addr/mask/prot/port): (88.55.66.77/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (192.168.2.2/255.255.255.255/47/0) current_peer 99.66.77.88 port 64917 PERMIT, flags={} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 349, #pkts decrypt: 349, #pkts verify: 349 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 88.55.66.77, remote crypto endpt.: 99.66.77.88 plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0 current outbound spi: 0x85BEAFA7(2243866535) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x97864AAC(2542160556) transform: esp-256-aes esp-sha256-hmac , in use settings ={Tunnel UDP-Encaps, } conn id: 8517, flow_id: ESG:6517, sibling_flags FFFFFFFF80000048, crypto map: Tunnel6-head-0 sa timing: remaining key lifetime (k/sec): (4607966/3412) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE)
Solved! Go to Solution.
09-16-2025 09:46 AM
Selector is now 0.0.0.0 that very good
Retrun back traffic drop why you config tunnel with ip nat inside??
MHM
09-16-2025 09:47 AM
@the-lebowski great, have inbound/outbound esp sa been established I cannot tell from this output.
I notice the remote peer tunnel has NAT configured. Could the remote peer be unintentially translating the traffic over the tunnel? and your local router does not have a route to the NAT ip address and therefore cause a problem?
09-16-2025 07:54 AM
@the-lebowski you have tunnel mode ipsec ipv4 under the tunnel interface, but is the remote side configured as GRE?....as the local/remote idents (255.255.255.255/47/0) indicate GRE is used. Determine whether its gre/ipsec and amend if required.
09-16-2025 08:21 AM - edited 09-16-2025 08:24 AM
I am not sure, all I have is the config of the remote site before it got shipped on site (could have changed) which is below and the tunnel interface is not configured as ipsec. I removed that command from the hub end, bounced the tunnel but it won't establish now. It just hangs over port 500, never switches to NAT-T and the tunnel interface never comes up.
So how would one end configured as ipsec and the other as GRE establish, but when both sides configured for GRE not establish? Not sure I am going to be able to solve this without getting access to the far end as nothing I have done on the hub end has worked.
interface Tunnel1
ip address 172.21.8.13 255.255.255.252
ip mtu 1400
ip nat inside
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel destination xx.xx.xx.xx
tunnel protection ipsec profile ikev2
09-16-2025 08:26 AM
@the-lebowski if the configuration above is from the remote peer, the lack of "tunnel mode ipsec ipv4" under the tunnel interface confirms it is using GRE, which is default on a tunnel interface. Run "no tunnel mode ipsec ipv4" or "tunnel mode gre" to change the mode from ipsec to gre.
09-16-2025 08:46 AM
Yeah, I replied earlier saying I removed that from the hub end but when doing that the tunnel never establishes. It just hangs over port 500 and the remote ident shows the public IP of the far end and not the private.
interface: Tunnel6
Crypto map tag: Tunnel6-head-0, local addr yy.yy.yy.yy
protected vrf: (none)
local ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/47/0)
current_peer xx.xx.xx.xx port 500
PERMIT, flags={origin_is_acl,}
Sep 16 07:40:27.661 pst: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel6, changed state to down
Sep 16 07:40:56.899 pst: %SYS-5-CONFIG_I: Configured from console by lebowski-admin on vty0 (10.10.20.20)
(config-if)#do show ip int brief | i Tunnel6
Tunnel6 172.21.8.14 YES manual up down
Building configuration...
Current configuration : 333 bytes
!
interface Tunnel6
ip address 172.21.8.14 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel destination xx.xx.xx.xx
tunnel protection ipsec profile ikev2
end
09-16-2025 07:56 AM
tunnel protection ipsec policy ipv4 CACL
Add this under tunnel'
Note:- you need to add ACL just like policy based VPN.
After you add command under tunnel you need to reset crypto
MHM
09-16-2025 08:05 AM
Its supposed to be route based VPN so why would I need an ACL? And I have other tunnels configured almost identical (far end behind NAT as well) that work without any ACLs applied. I went ahead and added an ANY ANY acl to the tunnel interface, shut/no shut to no avail.
Behavior is exactly the same.
interface Tunnel6
ip address 172.21.8.14 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel mode ipsec ipv4
tunnel destination xx.xx.xx.xx
tunnel protection ipsec policy ipv4 CACL
tunnel protection ipsec profile ikev2
end
#show ip access-lists CACL
Extended IP access list CACL
10 permit ip any any (8 matches)
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
09-16-2025 08:08 AM
Because your selector is not 0.0.0.0
So issue is other side use policy and your side use route based VPN
MHM
09-16-2025 08:14 AM
If the peer was using a policy based VPN then the selectors wouild still not be (192.168.2.2/255.255.255.255/47/0), they'd reflect the traffic selectors that identify the interesting traffic.
@the-lebowski check the tunnel mode is the same on both sides, as per my original post.
09-16-2025 08:38 AM
@Rob Ingram I replied below, but the only config I have from the far end shows the tunnel interface doesn't have that command applied to it.
09-16-2025 08:36 AM
Yeah that is the issue but why? I can't for the life of me figure out why the tunnel selector is not 0.0.0.0/0. And as @Rob Ingram said it could be the tunnel mode, but I can't change it on the far end as I don't yet have access to it.
09-16-2025 08:41 AM
@the-lebowski it's an SVTI, you can change either end as it will only affect that tunnel between those 2 peers. Why not change yours to GRE to get the tunnel up and confirm whether that's the issue?
09-16-2025 08:51 AM - edited 09-16-2025 08:53 AM
I changed it on my end to no avail, tunnel never gets past IN-NEG. Nothing I do on my end seems to matter and without access to the far end I am stuck. At this point I just assume something is wrong on the far end that will need to be fixed.
Odd that I can configure my end as ipsec and it comes up, but if I configure as GRE it never comes up so that leads me to believe the far end isn't configured as GRE and is configured as ipsec?
09-16-2025 08:57 AM
@the-lebowski can you try to delete the tunnel interface and recreate with the correct tunnel mode and observe the output?
I notice the peer is behind NAT, so is the device in front of it permitting udp/4500 from your router?
09-16-2025 09:19 AM - edited 09-16-2025 09:21 AM
Yes it is per the vendor but they are nat'ing UDP/4500 t0 64517 which is why I see that port when the tunnel mode is set to IPSEC. I have been shut/no shut the tunnel interface when I make the changes which I assume was enough to clear the crypto? Either way I removed the tunnel interface completely and recreated it without setting the tunnel mode to IPSEC to no avail.
interface Tunnel6
ip address 172.21.8.14 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel destination xx.xx.xx.xx
tunnel protection ipsec profile ikev2
end
Without it set to IPSEC it simply never switches to NAT-T and I see this in the debugs:
Sep 16 08:17:38.290 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):IPSec policy validate request sent for profile v2-profile with psh index 1.
Sep 16 08:17:38.290 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):
Sep 16 08:17:38.291 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):(SA ID = 1):[IPsec -> IKEv2] Callback received for the validate proposal - FAILED.
Sep 16 08:17:38.291 pst: IKEv2-ERROR:(SESSION ID = 379275,SA ID = 1):: There was no IPSEC policy found for received TS
Sep 16 08:17:38.291 pst: IKEv2:(SESSION ID = 379275,SA ID = 1):Sending TS unacceptable notify
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide