[Swan] Libreswan 3.31 VTI to XFRM Conversion

[Paul Wouters]

On Wed, 11 Mar 2020, Reuben Farrelly wrote:

> As it turns out, this error was caused by missing bits of kernel support for 
> the use of 'ip rule'.

> So things are looking better now:

> I had to manually set an IP address on the ipsec1 interface, but it still 
> doesn't work.

Yes, in the next release, leftinterface-ip= should work for that.

> lightning ~ # ip -d link show dev ipsec1
> 5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode 
> DEFAULT group default qlen 1000
>     link/none  promiscuity 0 minmtu 68 maxmtu 65535
>     xfrm if_id 0x1 addrgenmode random numtxqueues 1 numrxqueues 1 
> gso_max_size 65536 gso_max_segs 65535
> lightning ~ # ip -s link show dev ipsec1
> 5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode 
> DEFAULT group default qlen 1000
>     link/none
>     RX: bytes  packets  errors  dropped overrun mcast
>     1130640    13460    0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     170268     2027     0       12      0       0
> lightning ~ #

So it does see packets both ways. What does ipsec trafficstatus say? Did
it receive encrypted packets and send encrypted packets too?

> lightning ~ # ip route
> default via 172.105.178.1 dev eth0 metric 2
> 172.105.178.0/24 dev eth0 proto kernel scope link src 172.105.178.21
> 192.168.6.0/30 dev ipsec1 proto kernel scope link src 192.168.6.1

Hmm that looks okay.

> Looks a lot like IPSec is happy but the routing/interface side of things is 
> not.

Do you see an increase in numbers in /proc/net/xfrm_stat ?

is rp_filter disabled? and ip_forwarding enabled?

> I've made no changes at all on the Cisco and I assume that I won't need to do 
> so for this to work given it did previously with vti.

Correct. Nothing different is negotiated. It is all local changes only.

Paul