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
