cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
861
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)

 

 

 

26 Replies 26

@the-lebowski what identity is being matched in your ikev2 profile? 

We seemed to have regressed, as it previously got further than this.

Can you provide the full debug please.

I got access to the far end and the tunnel interface over there had the same private IP as the hub, 172.21.8.14 which was bad.  And it did not have the tunnel mode ipsec ipv4 either.  I updated hub side tunnel interface to use 172.21.8.13 and added the tunnel mode ipsec to the far end.  Tunnel is up and showing correctly as route based but encapsulating on hub and decapsulating on spoke but not both on either:

SPOKE:

interface Tunnel1
 ip address 172.21.8.14 255.255.255.252
 ip mtu 1400
 ip nat inside
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination xx.xx.xx.xx
 tunnel protection ipsec profile v2


#ping 172.21.8.13 so 172.21.8.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.21.8.13, timeout is 2 seconds:
Packet sent with a source address of 172.21.8.14



    Crypto map tag: Tunnel1-head-0, local addr 192.168.210.21

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 38.108.181.3 port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1

 

HUB:

interface: Tunnel6
    Crypto map tag: Tunnel6-head-0, local addr xx.xx.xx.xx

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer yy.yy.yy.yy port 64917
     PERMIT, flags={origin_is_acl,}
  #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

  

Selector is now 0.0.0.0 that very good 

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

MHM

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

I do not know why that is there but I removed the ip nat inside from the spoke tunnel, bounced crypto and now its working.

Thanks to both of you for all your help.

    #pkts encaps: 724, #pkts encrypt: 724, #pkts digest: 724
    #pkts decaps: 569, #pkts decrypt: 569, #pkts verify: 569

  

@the-lebowski great, glad it is sorted. FYI, it still would not have worked with the mismatched tunnel mode.

Clear crypto need if you do any change in IPsec 

Clear crypto and check

MHM

It simple 

If remote device is FW then it not support GRE and hence you need to try my suggestion 

If remote peer is cisco router then sure there is chance that @Rob Ingram correct about GRE.

MHM

There is tunnel mode auto features' 

Check if your local router support it.

MHM

(config-if)#tunnel mode ?
  aurp       AURP TunnelTalk AppleTalk encapsulation
  cayman     Cayman TunnelTalk AppleTalk encapsulation
  dvmrp      DVMRP multicast tunnel
  eon        EON compatible CLNS tunnel
  ethernet   Ethernet over gre
  gre        generic route encapsulation protocol
  ipip       IP over IP encapsulation
  ipsec      IPSec tunnel encapsulation
  iptalk     Apple IPTalk encapsulation
  ipv6       Generic packet tunneling in IPv6
  ipv6ip     IPv6 over IP encapsulation
  nos        IP over IP encapsulation (KA9Q/NOS compatible)
  rbscp      RBSCP in IP tunnel
  sdwan      SDWAN Overlay
  udp        UDP encapsulation protocol
  vxlan      VXLAN encapsulation
  vxlan-gpe  VXLAN GPE encapsulation

@the-lebowski FYI, "tunnel mode auto" is only available on a tunnel template (DVTI), not a SVTI that you are using. Hence why you need to manually define the mode, if anything other than the default (gre).

It not support auto feature.

As I mention in first comment use ACL and check.

Thanks alot 

MHM