cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
788
Views
15
Helpful
26
Replies

IKEv2 tunnel not encapsulating traffic

the-lebowski
Level 4
Level 4

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)

 

 

 

2 Accepted Solutions

Accepted Solutions

Selector is now 0.0.0.0 that very good 

Retrun back traffic drop why you config tunnel with ip nat inside??

MHM

View solution in original post

@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?

View solution in original post

26 Replies 26

@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.

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

 

@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.

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

 

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

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

 

Because your selector is not 0.0.0.0 

So issue is other side use policy and your side use route based VPN

MHM

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.

 

@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.

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. 

 

@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?

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? 

@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?

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