[Swan-dev] expirimental : ipsec device/interface aka XFRMi

[Paul Wouters]

On Thu, 5 Dec 2019, Antony Antony wrote:

> Here is an update from my side.  I rebased the branch. It seems to pass test
> cases, console output need fixing due to changes master.
>
> I briefly saw on Paul's laptop xfrmi did not work for him. I tried to
> reproduce it no luck so far.  May be something to do with WiFi and other
> interfaces? I need more details for this case.

I've redone my test from scratch, and it works now. I will re-test from
a coffeeshop network tomorrow as well, which is I think where I tested
this before.

One oddity I noticed is that I see some plaintext on the physical
interface:

18:12:05.643321 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xaa), length 120
18:12:05.848205 IP 193.110.157.148.ipsec-nat-t > 193.111.228.70.ipsec-nat-t: UDP-encap: ESP(spi=0x20539563,seq=0x60), length 120
18:12:05.848252 IP 92.118.37.88.54351 > 76.10.157.72.macon-tcp: Flags [S], seq 247801487, win 1024, length 0
18:12:05.848301 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xab), length 104
18:12:05.848319 IP 185.176.27.182.47634 > 76.10.157.75.22397: Flags [S], seq 3949598139, win 1024, length 0
18:12:05.848337 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xac), length 104
18:12:06.053702 IP 149.56.134.238.ircu-3 > 193.111.228.70.34570: Flags [P.], seq 0:47, ack 1, win 235, options [nop,nop,TS val 2034210897 ecr 2439042707], length 47
18:12:06.463324 IP 92.246.76.201.52631 > 76.10.157.66.15674: Flags [S], seq 135211186, win 1024, length 0
18:12:06.463401 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xad), length 104
18:12:06.642895 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xae), length 120
18:12:06.769495 IP 193.110.157.148.ipsec-nat-t > 193.111.228.70.ipsec-nat-t: UDP-encap: ESP(spi=0x20539563,seq=0x61), length 120
18:12:07.281537 ARP, Request who-has 76.10.157.67 tell 76.10.157.65, length 28
18:12:07.281557 ARP, Reply 76.10.157.67 is-at 34:e1:2d:b0:08:92, length 28
18:12:07.641894 IP 193.111.228.70.ipsec-nat-t > 193.110.157.148.ipsec-nat-t: UDP-encap: ESP(spi=0x4a70c7eb,seq=0xaf), length 120
18:12:07.793520 IP 193.110.157.148.ipsec-nat-t > 193.111.228.70.ipsec-nat-t: UDP-encap: ESP(spi=0x20539563,seq=0x62), length 120
18:12:07.836110 IP 149.56.134.238.ircu-3 > 193.111.228.70.34570: Flags [P.], seq 0:4

It suspect these are packets that are incoming retransmits that are no
longer being answered by my laptop since the tunnel came up? What should
be the expectation here? Should these existing TCP connections remain
working outside the tunnel, or should these stop working because the
user thinkgs it has a 0.0.0.0/0 VPN up? Although this is not an XFRMi
issue - it just became visible because of the clear seperation of ipsec1
and phyisical interface. Note that 193.111.228.70 is my pre-NAT IP address.

> the keyword parsing at them moment is a bit odd.
> ipsec-interface=yes|no|<n in hex>
> It would be nice to allow decimal numbers. On the other hand we can probably
> start with hex:) and fix it soon.

In our syntax for conf and secret files, hex is always input using 0x
prefix, so that is really something that needs to be fixed either before
the merge or after the merge before a release. But more generally, I still
do not like the yes|no|<number> syntax where yes is an implied number 1.
Why not drop the yes/no, and have 0 mean it is disabled?

> I am not confident to merge to master. The updown script need more testing.

As far as I can see, this code is already performing better that the VTI
code, so adding it now and in the next release removing VTI seems a
reasonable way forward. Especially since our experience is that
basically no external people tests our pre-release code. So it is
better to move forward in a full release so people try to use it and
report any bugs they experience.

Paul