Re: GRE over IPSec tunnel issue

saimunpial · ‎11-04-2013

Hello,

one of our remote branch has an issue that they cannot reach our local network. The logical configuration between these two locations are GRE over IPSec tunnel. The scenario is quite strange. Because we can reach any remote host but not the tunnel interface and from the remote location neither the tunnel interface or any host is reachable. The following troubleshoot I have done:

From our location

1. IP OSPF neighbor

172.18.0.1 0 FULL/ - 00:00:30 172.18.100.42 Tunnel40

2. Ping remote tunnel interface

#ping 172.18.100.42 source tunnel 40

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.18.100.42, timeout is 2 seconds:

Packet sent with a source address of 172.18.100.41

.....

Success rate is 0 percent (0/5)

3. Ping one remote host

ping 10.41.200.136

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.41.200.136, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 52/63/104 ms

xnw0252#sh ip route 10.41.200.136

Routing entry for 10.41.0.0/16

Known via "ospf 2", distance 110, metric 20, type NSSA extern 2, forward metric 1001

Last update from 172.18.100.42 on Tunnel40, 01:52:29 ago

Routing Descriptor Blocks:

* 172.18.100.42, from 172.18.0.1, 01:52:29 ago, via Tunnel40

Route metric is 20, traffic share count is 1

From remote location

1. IP OSPF neighbor

Neighbor ID Pri State Dead Time Address Interface

172.18.200.41 0 FULL/ - 00:00:31 172.18.200.41 Tunnel200

172.18.100.41 0 FULL/ - 00:00:32 172.18.100.41 Tunnel100

2. Ping remote tunnel interface

ping 172.18.100.41 source tunnel 100

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.18.100.41, timeout is 2 seconds:

Packet sent with a source address of 172.18.100.42

.....

Success rate is 0 percent (0/5)

3. Ping from remote router to one host

ping 10.101.127.4 source tunnel 100

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.101.127.4, timeout is 2 seconds:

Packet sent with a source address of 172.18.100.42

.....

Success rate is 0 percent (0/5)

xnwj252#sh ip route 10.101.127.4

Routing entry for 10.101.127.0/24

Known via "ospf 2", distance 110, metric 20, type NSSA extern 2, forward metric 1000

Last update from 172.18.100.41 on Tunnel100, 02:37:11 ago

Routing Descriptor Blocks:

* 172.18.100.41, from 172.18.100.41, 02:37:11 ago, via Tunnel100

Route metric is 20, traffic share count is 1

4. Debug tunnel on remote router

Tunnel100: adjacency fixup, 94.X.X.X->62.Y.Y.Y, tos set to 0x0

Tunnel100: GRE/IP encapsulated 94.X.X.X->62.Y.Y.Y (linktype=7, len=144)

*Nov 4 13:43:59.047: Tunnel100 count tx, adding 0 encap bytes

after disable ip cef I didn't see the message 'adjacency fixup'. But it doesn't solve the issue. I check with adjust tcp-mss as well as mtu settings. But until now no hope I have seen. So I would look for further assist.

thanks in advance.

Pial

Karsten Iwen · ‎11-04-2013

The main problem is that your crypto-ACLs are wrong. You only have to specify the GRE-traffic from tunnel-endpoint to tunnel-endpoint. And the crypto-map has to be applied only on the physical interface and not any more on the tunnel itself (that was done with older releases but not now anymore).

EDIT: And your MSS is probably still too big as the tunnel-overhead can be more then 48 Bytes. I would use 1360 to be on the safe side.

Are you using transport-mode in your transform-set? That can be used with GREoverIPSec to reduce the overhead by 20 Bytes.

--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

saimunpial · ‎11-04-2013

Hello Karsten,

thanks for your quick assist. The router has different crypto-maps associated with different tunnels and for that reason it is not applied on the physical interface. It has a older version ios. So it might not be an issue for it. I appreciate your suggestion about mss and I reduce to 1360. But still there is no luck until now. We are using without transport-mode. Very soon we will upgrade and implement DMVPN. But now we are not able change the configuration because of downtime on several locations which have the same type of VPN onfigurations like this one and working without any issue.

#sh version

Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(22)T5

info: From my location (hub side) I can ping any remote host except the tunnel interface. So what I understand there shouldn't be any cause for crypto map issue.

Peter Paluch · ‎11-04-2013

Pial,

I completely agree with Karsten's assessment of the situation. You are not running older IOS version at all - the crypto maps on Tunnel interfaces were required in IOS versions before 12.2(13)T. Your IOS version is newer by multiple generations.

You should indeed follow Karsten's advice and both correct the ACLs (they should only match the GRE traffic), and remove the crypto maps from your tunnel interfaces.

Best regards,

Peter