[Swan] vti support
paul at nohats.ca
Wed Jun 1 02:36:52 UTC 2016
On Wed, 1 Jun 2016, Charles Wyble wrote:
> Anyway I'm having a terrible time with VTI. I can't get packets to transit the tunnel. I'm hoping it's something incredibly stupid, and I'll get called out in 2 seconds...
> So here's the Cisco side:
I cannot help you there, but:
> interface Tunnel0
> ip address 192.168.195.2 255.255.255.252
> tunnel source 10.40.170.22
> tunnel destination 220.127.116.11
> tunnel mode ipsec ipv4
> tunnel protection ipsec profile VTI
> # Connection to rack at JUAF-SAT01
> conn satx
> left=18.104.22.168 #ovh outside ip
> leftsubnet=10.253.0.0/16 #ovh network
> leftid=22.214.171.124 #ikeid of ovh side
> right=126.96.36.199 #IOS outside address
> rightsubnet=10.40.170.0/24 #network behind IOS
> rightid=10.40.170.22 #IKEID sent by IOS
You need to vti-routing=yes but I do believe that is the default.
But when you set the leftsubnet and rightsubnet, you limit the tunnel
to those IP ranges. Your ping:
> satx-rtr01#ping 192.168.195.1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 192.168.195.1, timeout is 2 seconds:
is coming from 192.168.195.1, which doesn't fall within 10.253.0.0/16
If you type "ip route list" you will see that only 10.40.170.0/24 got
routed into the vt01 device, and only those packets will end up getting
> 24: vti01 at NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state UNKNOWN group default
> link/ipip 188.8.131.52 peer 184.108.40.206
That only shows you the gateway IP's to switch the VTI tunnel is bound.
You need to use "ip xfrm pol" (or actually ip -s xfrm pol) to see
which packets will match the policy to get encrypted for the IPsec SA.
More information about the Swan