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

Paul Wouters paul at nohats.ca
Tue Dec 10 23:26:32 UTC 2019

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

18:12:05.643321 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xaa), length 120
18:12:05.848205 IP > UDP-encap: ESP(spi=0x20539563,seq=0x60), length 120
18:12:05.848252 IP > Flags [S], seq 247801487, win 1024, length 0
18:12:05.848301 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xab), length 104
18:12:05.848319 IP > Flags [S], seq 3949598139, win 1024, length 0
18:12:05.848337 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xac), length 104
18:12:06.053702 IP > Flags [P.], seq 0:47, ack 1, win 235, options [nop,nop,TS val 2034210897 ecr 2439042707], length 47
18:12:06.463324 IP > Flags [S], seq 135211186, win 1024, length 0
18:12:06.463401 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xad), length 104
18:12:06.642895 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xae), length 120
18:12:06.769495 IP > UDP-encap: ESP(spi=0x20539563,seq=0x61), length 120
18:12:07.281537 ARP, Request who-has tell, length 28
18:12:07.281557 ARP, Reply is-at 34:e1:2d:b0:08:92, length 28
18:12:07.641894 IP > UDP-encap: ESP(spi=0x4a70c7eb,seq=0xaf), length 120
18:12:07.793520 IP > UDP-encap: ESP(spi=0x20539563,seq=0x62), length 120
18:12:07.836110 IP > 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 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 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.


More information about the Swan-dev mailing list