Cisco VTI tunnel routing

[Nub65]

How is it possible to route packets from one VTI tunnel interface to another?

Both VTI tunnels are up and work perfectly, I just cant route packets that come into one tunnel to another.

Without.  ipsec protection, with naked GRE tunnels I have connectivity, but as soon as I configure ipsec, I am losing connectivity

[Karsten Iwen]

Routing is the same with or without IPsec. I assume something is wrong with your crypto. Do the tunnels come up with IPsec? Can you reach the remote tunnel-IPs?

[Nub65]

Thanks for your response,

Yes, tunnels are up and working. I can reach both of their destinations. I just can not reach destination sourced from one tunnel interface going to another. I removed "tunnel mode ipsec ipv4" command from the tunnel interfaces and it fixed the problem, I'm just not sure that this is the best solution.

Whats your thoughts about it?

[Karsten Iwen]

That doesn't really make much sense ... If you are using an early IOS it could be worth an update.

If you do a traceroute, how far do you get to the destination?

[a.alekseev]

My thoughts...
It would be great to see the configs :)

[Nub65]

R1:

interface g1/0
ip address 192.168.1.1 255.255.255.0
no shut
crypto isakmp policy 1
auth pre
enc aes
hash sha
group 5
crypto isakmp key cisco address 192.168.3.1
crypto isakmp key cisco address 192.168.4.1

crypto ipsec transform-set cisco esp-aes esp-sha-hmac
mode tunnel
crypto ipsec profile cisco
set transform-set cisco
interface tun0
ip address 1.1.1.1 255.255.255.252
no shut
tunnel source 192.168.1.1
tunnel mode ipsec ipv4
tunnel destination 192.168.3.1
tunnel protection ipsec profile cisco
interface tun1
ip address 2.2.2.1 255.255.255.252
no shut
tunnel source 192.168.1.1
tunnel mode ipsec ipv4
tunnel destination 192.168.4.1
tunnel protection ipsec profile cisco

ip route 0.0.0.0 0.0.0.0 192.168.1.2
ip route 172.16.3.1 255.255.255.255 1.1.1.2
ip route 172.16.4.1 255.255.255.255 2.2.2.2

R3:

interface g2/0
ip address 192.168.3.1 255.255.255.0
no shut
crypto isakmp policy 1
auth pre
enc aes
hash sha
group 5
crypto isakmp key cisco address 192.168.1.1

crypto ipsec transform-set cisco esp-aes esp-sha-hmac
mode tunnel
crypto ipsec profile cisco
set transform-set cisco
interface tun0
ip address 1.1.1.2 255.255.255.252
no shut
tunnel source 192.168.3.1
tunnel mode ipsec ipv4
tunnel destination 192.168.1.1
tunnel protection ipsec profile cisco

ip route 0.0.0.0 0.0.0.0 192.168.3.2
ip route 172.16.4.1 255.255.255.255 1.1.1.1

int loop0

ip address 172.16.3.1 255.255.255.255

R4:

interface g2/0
ip address 192.168.4.1 255.255.255.0
no shut
crypto isakmp policy 1
auth pre
enc aes
hash sha
group 5
crypto isakmp key cisco address 192.168.1.1

crypto ipsec transform-set cisco esp-aes esp-sha-hmac
mode tunnel
crypto ipsec profile cisco
set transform-set cisco
interface tun0
ip address 2.2.2.2 255.255.255.252
no shut
tunnel source 192.168.4.1
tunnel mode ipsec ipv4
tunnel destination 192.168.1.1
tunnel protection ipsec profile cisco
int loop0
ip address 172.16.4.1 255.255.255.255

ip route 0.0.0.0 0.0.0.0 192.168.4.2
ip route 172.16.4.1 255.255.255.255 2.2.2.1

From R1 I can reach both loop interfaces, but can't reach from R3 to R4.

R3#traceroute 172.16.4.1 source 172.16.3.1
Type escape sequence to abort.
Tracing the route to 172.16.4.1
VRF info: (vrf in name/id, vrf out name/id)
1 1.1.1.1 76 msec 40 msec 44 msec
2 * * *
3 * * *

[Rob Ingram · Accepted solution]

Hi,

Are you using a C7200 image in GNS3? If so, from memory I believe I had this exact same issue when using "tunnel mode ipsec ipv4" but this would work with "tunnel mode gre ip" (default), which by the sounds of it you have done. I now use a VIRL image and this works without issue.