traffic not return in IPSEC tunnel

Unanswered Question
Aug 21st, 2009
User Badges:
  • Silver, 250 points or more

What are possible reasons that traffic doesn't return in an IPSEC tunnel?


I see with sh crypto ipsec sa that packets become encrypted at the sending site and decrypted at the remote site but they doesn't return. :-(

1)routing problem at the other side

2)blocking ACL outbound at the other side

3) other ?


It's for an environment terminitating normally tunnel interfaces in IPSEC mode but now also with a dynamic crypto map tunnel.


Can it be that traffic is 'pulled'at the other side in another tunnel and then dropped?




  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Peter Paluch Fri, 08/21/2009 - 14:59
User Badges:
  • Cisco Employee,

Hello Davy,


Can you at least confirm that, say, a ping packet sent from one end arrives and is understood on the other end? Try the debug ip packet and debug ip icmp for this purpose (these commands can be quite verbose if the router is under load). Try to find out if an ICMP echo packet is received on the other end, whether a response is created and how is it routed.


Can you also please post here the relevant parts of the configuration of the both routers regarding the entire IPsec configuration including the routing entries?


Did it work at all at some time in the past? If it did, what has changed in your network since it was working?


Best regards,

Peter


Istvan_Rabai Fri, 08/21/2009 - 23:30
User Badges:
  • Gold, 750 points or more

Hi Davy,


What first comes to my mind, without deeper delving into the matter:


Did you configure the "reverse-route" command in the dynamic crypto map?


This command dynamically puts a static route into the routing table of the VPN Server router pointing to the other end of the tunnel.


Cheers:

Istvan


davy.timmermans Sat, 08/22/2009 - 00:28
User Badges:
  • Silver, 250 points or more

Hi all,


It worked in a lab but not in the real environment.


I didn't use the reverse-route command because it worked for one site at time in the lab ( and it was decribed in the documentation that it could work only for one crypto map.


As applied in the lab:

crypto dynamic-map DM_profile 10

set transform-set ts1

match address 101

reverse-route

crypto dynamic-map DM_profile 20

set transform-set ts1

match address 102

reverse-route


It worked for each spoke but not for the situation that both spokes where down.


But I've seen yesterday that it's not needed to define interesting traffic at the dynamic side. So the solution could be easier


crypto dynamic-map DM_profile 10

set transform-set ts1

reverse-route


This could work because it's applied under 1 cryptomap (as discussed in the docs). Although Im'not sure if it would work for two sites falling on backup. I'll test this Monday


As we added one site as test I finally added the reverse-route command but although it didn't work.


@Peter

I do a ping from the loopback of the spoke towards a loopback of the hub



interface: FastEthernet0/1

Crypto map tag: static, local addr 3.3.1.1


protected vrf: (none)

local ident (addr/mask/prot/port): (30.0.0.0/255.0.0.0/0/0)

remote ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/

current_peer 1.1.1.1 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10 <---------

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 <---------

#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


interface: FastEthernet0/0

Crypto map tag: CM, local addr 1.1.1.1


protected vrf: (none)

local ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)

remote ident (addr/mask/prot/port): (30.0.0.0/255.0.0.0/0/0)

current_peer 3.3.1.1 port 500

PERMIT, flags={}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 <--------

#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10 <--------

#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


Why I think about the other tunnel was that I


interface: Serial1/0.201

...

protected vrf: (none)

local ident (addr/mask/prot/port):

PERMIT, flags={}

#pkts encaps: 13, #pkts encrypt: 13,

#pkts digest: 13

#pkts decaps: 13, #pkts decrypt: 13, #pkts verify: 13

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 2, #recv errors 0

local crypto endpt.: 10.102.0.2, remote crypto endpt.: 10.102.0.1

path mtu 1500, ip mtu 1500, ip mtu idb Tunnelxxx <----


I thought I saw here not the outgoing interface but some tunnel. When I checked this tunnel it hadn't an overlapping route.



current outbound spi: 0x8590D11F(2240860447)


davy.timmermans Sat, 08/22/2009 - 00:39
User Badges:
  • Silver, 250 points or more

Configuration


HUB


crypto isakmp policy 1

encr aes

authentication pre-share

group 2


crypto isakmp key THEKEY address 2.2.0.1

crypto isakmp key THEKEY address 3.3.0.1

crypto isakmp key THEKEY address 0.0.0.0 0.0.0.0


crypto ipsec transform-set ts1 esp-aes esp-sha-hmac

!

crypto ipsec profile IP_S_Profile

set transform-set ts1


crypto dynamic-map dm_profile 10

set transform-set ts1

match address remote


crypto map dm 10 ipsec-isakmp dynamic dm_profile


interface Tunnel1

ip address 192.168.1.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 2.2.0.1

tunnel mode ipsec ipv4

tunnel protection ipsec profile IP_S_Profile

!

interface Tunnel2

ip address 192.168.2.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 3.3.0.1

tunnel mode ipsec ipv4

tunnel protection ipsec profile IP_S_Profile


interface fas0/0

crypto map dm



int lo0

ip add 172.16.0.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 fas0/0


access-list remote



spoke


crypto isakmp policy 1

encr aes

authentication pre-share

group 2

crypto isakmp key THEKEY address 1.1.1.1

!


!

crypto ipsec transform-set ts1 esp-aes esp-sha-hmac

!

crypto ipsec profile IP_S_Profile

set transform-set ts1

!

!Corresponds with dynamic crypto on hub

crypto map static 1 ipsec-isakmp

set peer 1.1.1.1

set transform-set ts1

match address 100

!

!

!

!

!

!

interface Loopback0

ip address 20.20.20.20 255.255.255.255

!

access list 100 permit lo0 ->loopbHub



over the tunnel interface, RIP is used and a floating static towards backup interface.



In the real environmont, they have lot's of different IPSEC tunnels operating (via tunnel interface but also pure static) but no dynamic tunnels yet.


Although it didn't worked in the real environment, it has to ;-)


Actions

This Discussion