[Swan] Various problems with VTI on Gentoo (with Cisco IOS as a client)
Paul Wouters
paul at nohats.ca
Mon Sep 19 15:44:45 UTC 2016
On Mon, 19 Sep 2016, Reuben Farrelly wrote:
> I've been experimenting today with Vti based configuration and run into a few
> problems.
Thanks for testing the VTI support!
> 1. The first problem is when the IPSec completes negotiation. As soon as the
> IPsec connects up, I lose all IPv4 access to the remote box. This is made
> even worse because the public route to the client is also wiped out, so the
> IPsec session basically kills the connectivity to the box including that of
> the IPsec session due to a recursive routing loop and more specific /1's for
> the global routing table:
>
> lightning ~ # ip route
> 0.0.0.0/1 dev vti01 scope link src 192.168.6.1 mtu 1438
> default via 139.162.51.1 dev eth0 metric 3
> 127.0.0.0/8 dev lo scope host
> 127.0.0.0/8 via 127.0.0.1 dev lo
> 128.0.0.0/1 dev vti01 scope link src 192.168.6.1 mtu 1438
> 139.162.51.0/24 dev eth0 proto kernel scope link src 139.162.51.249
> lightning ~ #
>
> Even with: vti-routing=no I still see these routes appear, and experience
> this problem.
That's odd. with vti-routing=no there should be no VTI specific routing
changes?
You seem to have the "half routes" 0/1 and 128/1 installed via the vti
device. Those are most certainly wrong, but I'm not sure why those were
installed.
> 2. What I would ideally like to do is have a tunnel interface on the Cisco,
> and number it with 192.168.6.2/30. Ideally then on the Libreswan box I would
> set 192.168.6.1/30 which would give me a proper traditional numbered link. I
> only need connectivity across the directly connected subnet (don't want or
> need any other routes to be reachable just yet - I'm NATting for this purpose
> in the meantime).
Yes we are adding a leftvti= and rightvti= option to allow updown to
configure and ip address on the created vti device.
> The Cisco insists on 0.0.0.0/0 as the src and dst proxy IDs for these sorts
> of VTI connections on it's side.
It should work fine to set leftsubnet=0.0.0.0/0 and
rightsubnet=0.0.0.0/0 as long as you set mark="5" or some uniqu number.
The marking should prevent anything from being directed into the xfrm
path per default unless it was pointed to the VTI device.
> How would I configure Libreswan to work in this way? [This would allow me to
> match the config I have on the other IPsec Palo Alto head end, and
> consistency is a great thing!]
Currently, just manually configure the IP address in updown?
> 3. I am seeing packets leave the Cisco across the Cisco Tunnel interface, and
> I am seeing these packets enter the Libreswan vti. However every single one
> of them is being dropped:
>
> lightning pluto # ifconfig vti01
> vti01: flags=193<UP,RUNNING,NOARP> mtu 1428
> tunnel txqueuelen 1 (IPIP Tunnel)
> RX packets 0 bytes 0 (0.0 B)
> RX errors 5257 dropped 5257 overruns 0 frame 0
> TX packets 2236 bytes 568568 (555.2 KiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> lightning pluto #
>
> The TX packets were from me doing pings from the head end. The Cisco never
> sees any packets input but sees lots of packets output.
>
> Tested without iptables as well, so that isn't the issue.
>
> What would cause this?
Not sure. You can check /proc/net/xfrm_stat but I guess it would be
packets not within scope? Are you sure you configured a leftsubnet and
rightsubnet of 0/0 ?
Or did you not setup the IP on the vti interface and therefor have no
default route (as it is supposed to be over the tunnel) ?
> 4. Possibly related to (3) are these two tunnel types actually the same?
>
> 22: vti01 at NONE: <NOARP,UP,LOWER_UP> mtu 1428 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1
> link/ipip 139.162.51.249 brd 0.0.0.0
What does "ip tun" say?
> and on the Cisco:
>
> router-2#show int tun 1
> Tunnel1 is up, line protocol is up
> Hardware is Tunnel
> Description: Libreswan site-to-site IKEv2 VPN
> Internet address is 192.168.6.2/32
> MTU 17862 bytes, BW 256 Kbit/sec, DLY 50000 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation TUNNEL, loopback not set
> Keepalive not set
> Tunnel linestate evaluation up
> Tunnel source 10.100.37.15 (Cellular0), destination 139.162.51.249
> Tunnel Subblocks:
> src-track:
> Tunnel1 source tracking subblock associated with Cellular0
> Set of tunnels with source Cellular0, 2 members (includes
> iterators), on interface <OK>
> Tunnel protocol/transport IPSEC/IP
>
> So one is IP/IP and the other is IPSEC/IP. Is this expected?
I don't know how cisco shows that internally....
> The libreswan config looks like this:
>
> conn router-2.reub.net
> left=139.162.51.249
> leftid=@lightning.reub.net
> leftsubnet=0.0.0.0/0
> leftsourceip=192.168.6.1
> right=%any
> rightid=router-2 at reub.net
> rightsubnet=0.0.0.0/0
> authby=secret
> ikev2=insist
> ikelifetime=86400s
> salifetime=3600s
> ike=aes256-sha1;modp1536
> phase2alg=aes128-sha1;modp1536
> mtu=1438
> dpddelay=15
> dpdtimeout=45
> dpdaction=clear
> auto=add
> mark=12/0xffffff
> vti-interface=vti01
> vti-routing=no
> vti-shared=yes
Normally I'd say use vti-shared=no, but I guess that might require you
to have a static right= and not right=%any. You can temporarilly try it
with the known right ip address of the moment and see if that changes
things?
> Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
> remote selector 0.0.0.0/0 - 255.255.255.255/65535
That looks fine.....
> Any advice would be appreciated. I guess by using Cisco IOS and Gentoo Linux
> I am not running an entirely standard combination of client+server but
> nevertheless it would be good to be able to get this working, and to have
> Gentoo be a working OS with VTI.
Well, it is precisely the interop with the big vpn vendors that we want
to learn about and make work. I don't think it matters much what linux
flavour you use, as long as the ip command is new enough to support
the VTI stuff.
Paul
More information about the Swan
mailing list