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...
Maybe :)
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 158.69.183.161
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
# Connection to rack at JUAF-SAT01
conn satx
left=158.69.183.161 #ovh outside ip
leftsubnet=10.253.0.0/16 #ovh network
#leftsubnet=0.0.0.0/0
leftid=158.69.183.161 #ikeid of ovh side
right=38.103.217.178 #IOS outside address
rightsubnet=10.40.170.0/24 #network behind IOS
#rightsubnet=0.0.0.0/0
rightid=10.40.170.22 #IKEID sent by IOS
ike=aes128-sha1;modp4096
esp=aes128-sha1
type=tunnel
authby=secret
auth=esp
keyexchange=ike
keyingtries=2
disablearrivalcheck=no
ikev2=no
auto=start
mark=5/0xffffffff
vti-interface=vti01
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
encrypted.
24: vti01@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state
UNKNOWN group default
link/ipip 158.69.183.161 peer 38.103.217.178
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.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
