Traceroute ICMP over SVTI tunnel

douglas.watt · ‎08-04-2008

Hi all,

I can't traceroute across a SVTI tunnel. I can ping across the SVTI using local subnet router interface as ping source and this works fine. Normal WAN traffic seems to be unaffected.

Do SVTIs support traceroute? I have setup a SVTI tunnel between R1 and R2 with static routes pointing to the remote subnets via the tunnel interface. The SVTI is configured with encryption.

R1

--

interface Tunnel10

description CORE ADSL SVTI to R2

ip address 192.168.24.1 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

no ip mroute-cache

tunnel source BVI1

tunnel destination 10.32.255.6

tunnel mode ipsec ipv4

tunnel protection ipsec profile ENCRYPT_IT

ip route 155.24.0.0 255.255.252.0 Tunnel10

R2

--

interface Tunnel10

description CORE ADSL SVTI to R1

ip address 192.168.24.2 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

no ip mroute-cache

tunnel source BVI1

tunnel destination 10.32.255.62

tunnel mode ipsec ipv4

tunnel protection ipsec profile ENCRYPT_IT

ip route 155.24.5.0 255.255.255.0 Tunnel10

Richard Burts · ‎08-04-2008

Douglas

I believe that we do not have enough information to be sure what the problem is. In particular I think that we need to see how IPSec and encryption are set up. I would be particularly interested in the profile ENCRYPT_IT and in the access list that it uses.

I will also make a guess at what is causing this problem. The title of the post seems to associate traceroute with ICMP. This is true if the traceroute is done from a Windows machine (using the tracert command) which sends ICMP packets as the probe and receives ICMP responses. But it sounds like you are doing the traceroute from the router. And in IOS traceroute sends UDP packets as the probe and receives ICMP responses. My guess is that the configuration of IPSec is not defining the UDP packets as packets which should be encrypted.

HTH

Rick

HTH

Rick

douglas.watt · ‎08-04-2008

Rick, Thanks for your reply.

The crypto profile is as follows:

R1#

-------

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

lifetime 3600

!

crypto isakmp key *********************** address 10.32.255.6

!

crypto ipsec transform-set TRANS-SET esp-3des esp-sha-hmac

!

crypto ipsec profile ENCRYPT_IT

set transform-set TRANS-SET

R2#

-------

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

lifetime 3600

!

crypto isakmp key *********************** address 10.32.255.62

!

crypto ipsec transform-set TRANS-SET esp-3des esp-sha-hmac

!

crypto ipsec profile ENCRYPT_IT

set transform-set TRANS-SET

Richard Burts · ‎08-04-2008

Douglas

Thanks for the additional information. However it does not include the part that I especially want to see. Can you also post the part of the config that identifies traffic to be included in encryption by IPSec.

HTH

Rick

HTH

Rick

douglas.watt · ‎08-04-2008

Rick, There are no ACL's specified in the config, I didn't think this was required for a SVTI unlike as is required for a crypto-map?

I assumed pointing a static to the tunnel10 interface would work.

Richard Burts · ‎08-04-2008

Douglas

Perhaps you are correct. I have not done an SVTI and assumed that it identified traffic similar to the way that a crypto map does, but perhaps I am mistaken. I will need to think about this some more to identify what to look at next. Perhaps some other participant in the forum will also have a suggestion.

HTH

Rick

HTH

Rick

douglas.watt · ‎08-05-2008

Rick, thanks for your help. I learnt something about traceroute from routers :)

For info. a traceroute from R1 to R2 gives the following:

R1#traceroute 155.24.1.254 source 155.24.5.254

Type escape sequence to abort.

Tracing the route to 155.24.1.254

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 * * *

7 * * *

8 * * *

9 * * *

10 * * *

11 * * *

12 * * *

13 *

R1#

Regards,

Douglas

Richard Burts · ‎08-05-2008

Douglas

I see that the traceroute here fails and you are specifying the source address. Does it work if you just traceroute 155.24.1.254 (without specifying the source address)?

Also it would be helpful to know if you can do a standard ping to that destination (ping 155.24.1.254) and if you do an extended ping to that destination and in the extended ping specify the source address as 155.24.5.254.

HTH

Rick

HTH

Rick

douglas.watt · ‎08-05-2008

R1#traceroute 155.24.1.254

Type escape sequence to abort.

Tracing the route to 155.24.1.254

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 * * *

7 *

R1#

R1#ping 155.24.1.254

Type escape sequence to abort.

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

!!!!!

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

R1#ping 155.24.1.254 source 155.24.5.254

Type escape sequence to abort.

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

Packet sent with a source address of 155.24.5.254

!!!!!

R1#ping

Protocol [ip]:

Target IP address: 155.24.1.254

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 155.24.5.254

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

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

Packet sent with a source address of 155.24.5.254

!!!!!

douglas.watt · ‎08-05-2008

I've also logged a case with Cisco TAC.

Douglas

douglas.watt · ‎08-13-2008

TAC advised removing the "no ip unreachables" command this has fixed the problem.

Apparently the "no ip unreachables" command on a tunnel/interface allows ICMP ping echo and echo-reply but blocks UDP traceroutes.

I'm now able to traceroute around all SVTI tunnels in our network.

Regards,

Dougie

Richard Burts · ‎08-13-2008

Douglas

Thanks for posting back indicating that you have a solution and what the solution is. It makes the forum more useful when people can read about a problem and can read the successful solution to the problem.

Good catch by the TAC. It makes sense. Echo request and Echo reply would work fine but the UDP based traceroute depends on the ICMP port unreachable (which is one of the ip unreachables) to indicate that it has gotten to the destination. So UDP based traceroute would break when no ip unreachables is configured.

HTH

Rick

HTH

Rick