[Swan] No ipsec0 device with XFRMi

Antony Antony antony at phenome.org
Wed Aug 26 18:47:43 UTC 2020

On Tue, Aug 11, 2020 at 09:13:46PM -0400, Paul Wouters wrote:
> On Mon, 10 Aug 2020, Antony Antony wrote:
> > I would leave it as ipsec1 but if others think ipsec0 is better I would
> > apply this patch. I don't have a strong opinion for either.
> Based on Wolfgang's feedback, I think we should allow ipsec0 for easier
> migration from KLIPS to XFRMi.
> > Paul commented something here. However, I wonder that message is after this
> > patch or before.
> > https://lists.libreswan.org/pipermail/swan/2020/003616.html
> Before.
> Isn't it still true that you cannot use if_id set to 0 because that
> means the same as not using if_id. I mean within the kernel, not

no, I know if_id 0 works in some situations. now iproute allow if_id 0 and 
strongswan allow if_id 0. I think now, 5.4 or later,xfrmi does not need 
physcial dev ethX associated with it.

I think kernel is fine with if_id 0. It would work simples cases
such as typical test scenario eastnet===westnet where the east IP and west 
IP are not part of the extruded subnet. Things can get tricky when east IP 
and/or west IP are part extruded subnet, such ash 0/0 == 0/0 or /32 
host-to-host. So I decided not to allow if_id 0 initially. If there is a
generic solution with if_id 0 we can fix go that way.  It might need more 
testing and patches!  Another question is what happens when there is conn 
with xfrmi=no and second conn xfrmi=yes and if_id 0? I am not sure how 
policy look up would work. Would the traffic go through xfrmi=no connection 
if that was the last connection established?

> within libreswan. Within libreswan we have that problem too, but we
> can fix that. If we make the default -2, and ipsec-device=0 maps
> to if_id of -1, then we can map ipsec0 to if_if(max-1) so that all
> ipsecX maps to if_id == X except for the special ipsec0.

My guess is libreswan parser code need work to support -1 uint32.
AFIK parser only support uint32_t.  uint64_t is not supported. The if_id 
need that whole uinit32_t. That is my re-collection while working on xfrmi 
and also I have branch where I tried to add byte limit. There I ran into 
issues not able to support uint64_t, because byte counter is 64bit.
> However, if others prefer the simpler ipsecX == if_id + 1, than I'm
> okay with that too. I think for almost all users, if_id is magic
> under the hood that they will never deal with.
> Alternatively, we could make ipsec-device=STRING and allow people
> to use any name they want. But I think that requires a little more
> from our code since we cannot match on the "ipsec" prefix anymore.
> And we would need something for %unique too, although it could keep
> using an ipsec prefix and look for the first free one? 

In general I am not in favor of configurable xfrmi device name, ipsecX is 
simple:) I also realized with adavnced namepace tricks such as possiblity to 
move xfrmi to different namespace, and continer use cases name of interface 
has some limitations. In those case updwon script  won't configure xfrmi 
interface. Also interface does not have to be present when pluto bring up a 
connection. Actully my guess is that is why strongswan only allow
if_id and not the interface name.

> > Paul what do you think of applying this patch?
> See above. Otherwise, it looks good to me, although I'm still a
> little confused about the interaction of the old mark's and this.
> But if youare confident and we have test cases, I'm fine.
> so please, based on this, go and push one or the other version of
> your patch into main.


My plan is first the output mark patch. Then later on ipsec0 patch. This 
will need many smaller test updates, both script and output.
I will have to rebase my branch. Recent logger changes broke my branch.


More information about the Swan mailing list