[Swan] Various problems with VTI on Gentoo (with Cisco IOS as a client)

[Reuben Farrelly]

Responding to some but not all of these things for now:

On 20/09/2016 1:44 AM, Paul Wouters wrote:
> 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?

There is.

Here's after a clean reboot:

lightning ~ # ip route
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
139.162.51.0/24 dev eth0  proto kernel  scope link  src 139.162.51.249
lightning ~ #

The VTI won't come up though.  It fails, as towards the end of the 
negotiation the box loses connectivity with the peer and from the 
Cisco's perspective never completes negotiation - so I had to add a 
route to cover the peer's public subnet:

1.0.0.0/8 via 139.162.51.1 dev eth0

And then the vti comes up on both ends.

What the Cisco does in this situation and what I would expect libreswan 
to do is to install a host route to the peer so that when the default 
route changes (or when those /1 routes are inserted) we still have 
connectivity with the host and can complete the negotiation.

Here's the routing table after the vti comes up:

lightning pluto # 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
1.0.0.0/8 via 139.162.51.1 dev eth0
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 pluto #

This is with vti-routing=no set.

There is no route for 192.168.6.2 (the client side) but even if I add 
one I still get no data flow and error counts increasing on each packet 
received.

Still don't know why that 0.0.0.0/1 route is being put there though.

> 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.

That'll take care of the routing bit nicely I think.

>> 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.

I'm using mark=12/0xffffff in the config.  I tried using markin= and 
markout= as well but those commands were rejected as invalid.

>> 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 ?

Curiously there is no such entry in /proc:

lightning pluto # ls -la /proc/net/xf*
ls: cannot access '/proc/net/xf*': No such file or directory
lightning pluto #

> 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) ?

I have but still no joy:

vti01: flags=193<UP,RUNNING,NOARP>  mtu 1428
         inet 192.168.6.1  netmask 255.255.255.255
         tunnel   txqueuelen 1  (IPIP Tunnel)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 9939  dropped 9939  overruns 0  frame 0
         TX packets 3562  bytes 1352092 (1.2 MiB)
         TX errors 158  dropped 0 overruns 0  carrier 120  collisions 38

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?

lightning pluto # ip tunnel
gre0: gre/ip remote any local any ttl inherit nopmtudisc
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0
vti01: ip/ip remote any local 139.162.51.249 ttl inherit key 12
tunl0: ip/ip remote any local any ttl inherit nopmtudisc
lightning pluto #

>> 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....

It shows as differently to IP/IP however it might only show differently 
as IP/IP would have an inner tunnel not encrypted but IP/IPSEC is.  Not 
sure...it's definitely a different type of tunnel in terms of Cisco 
config though.

Reuben