[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.
ok.
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.
-antony
More information about the Swan
mailing list