[Swan] Libreswan 3.31 VTI to XFRM Conversion

[Reuben Farrelly]

Hi again,

On 12/03/2020 12:23 am, Paul Wouters wrote:
> 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.

Should this work in current -git ?   Because I just updated this 
morning, and it's still not working (no message about the command being 
deprecated, but it just doesn't work):

lightning ~ # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP mode DEFAULT group default qlen 1000
     link/ether f2:3c:92:08:48:96 brd ff:ff:ff:ff:ff:ff
5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
mode DEFAULT group default qlen 1000
     link/none
lightning ~ #

Also -git master still shows 3.30 as the version despite 3.31 being 
released:

Linux Libreswan v3.30-288-g7518e3d84b-HEAD (netkey) on 5.5.8-gentoo

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

After adding the IP address, counts look like this:

lightning ~ # ipsec trafficstatus

006 #2: "router-2.reub.net-ipv4"[1] 1.144.144.75, type=ESP, 
add_time=1583982889, inBytes=129780, outBytes=504, id='router-2 at reub.net'
lightning ~ # ping 192.168.6.2
PING 192.168.6.2 (192.168.6.2) 56(84) bytes of data.
^C
--- 192.168.6.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1074ms

lightning ~ # ipsec trafficstatus
006 #2: "router-2.reub.net-ipv4"[1] 1.144.144.75, type=ESP, 
add_time=1583982889, inBytes=129780, outBytes=672, id='router-2 at reub.net'
lightning ~ #

Sending traffic increments the counts as above but there is no response 
to the ping (from either end).

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

No.

lightning ~ # cat /proc/net/xfrm_stat
XfrmInError                     0
XfrmInBufferError               0
XfrmInHdrError                  0
XfrmInNoStates                  0
XfrmInStateProtoError           0
XfrmInStateModeError            0
XfrmInStateSeqError             0
XfrmInStateExpired              0
XfrmInStateMismatch             0
XfrmInStateInvalid              0
XfrmInTmplMismatch              0
XfrmInNoPols                    0
XfrmInPolBlock                  0
XfrmInPolError                  0
XfrmOutError                    0
XfrmOutBundleGenError           0
XfrmOutBundleCheckError         0
XfrmOutNoStates                 0
XfrmOutStateProtoError          0
XfrmOutStateModeError           0
XfrmOutStateSeqError            0
XfrmOutStateExpired             0
XfrmOutPolBlock                 0
XfrmOutPolDead                  0
XfrmOutPolError                 0
XfrmFwdHdrError                 0
XfrmOutStateInvalid             0
XfrmAcquireError                0
lightning ~ #

Curiously the ip_vti module is also always loaded, but I unloaded it 
before assigning the IP to the link above.  Is there any reason why we 
would want ip_vti enabled in an xfrm environment?  It creates another 
ipsec type interface (presumably needlessly).

>
> is rp_filter disabled? and ip_forwarding enabled?

rp_filter disabled = yes, but ip_forwarding disabled (can be changed).  
Does this matter if we're only pinging across the /30 link and not 
routing through the box?

Reuben