How is the configuration on your cisco-side ? Cisco sometimes can be tricky. Especially w/ interop issues.
________________________________________ De: Swan <[email protected]> em nome de Reuben Farrelly <[email protected]> Enviado: segunda-feira, 19 de setembro de 2016 20:07 Para: Paul Wouters Cc: [email protected] Assunto: Re: [Swan] Various problems with VTI on Gentoo (with Cisco IOS as a client) 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@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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
