[Swan] ?= ?==?utf-8?q? No ipsec0 device with XFRM
Antony Antony
antony at phenome.org
Fri Aug 7 12:58:02 UTC 2020
Hi Wolfgang,
I hope to add something similar to this patch soon. So far my thinking is
use the mark-out config option. Then the user can configure any mark/mask
for xfrmi output mark, PLUTO_XFRMI_FWMARK. This configuration will override
using the default, if_id/0xffffffff used as the mark.
I thave to check if mark-out is allowed without mark-in. The mark-in is not
necessarry for xfrmi. It is ignored. And when using VTI mark-out would mean
different than in xfrmi.
I was avoiding mixing and re-using VTI related option. One issue would
updown script there it should be PLUTO_XFRMI_FWMARK and not CONNMARK_OUT.
-antony
On Thu, Jul 30, 2020 at 03:04:22PM +0200, Wolfgang Nothdurft wrote:
> Am Donnerstag, 30. Juli 2020 08:56 CEST, schrieb "Wolfgang Nothdurft"
> <wolfgang at linogate.de>:
>
> > Am Donnerstag, 30. Juli 2020 03:44 CEST, schrieb Paul Wouters <paul at nohats.ca>:
> >
> > > On Wed, 29 Jul 2020, Wolfgang Nothdurft wrote:
> > >
> > > > Am Dienstag, 28. Juli 2020 20:25 CEST, schrieb Antony Antony <antony at phenome.org>:
> > > >
> > > >> ipsec-interface=0 would translate to
> > > >>
> > > >> ip link add ipsec0 type xfrm dev enp0s5 if_id 0
> > > >>
> > > >> when I started adding xfrmi I wasn't sure xfrm if_id 0 would work properly.
> > > >> if_id is a lookup key to find policy and state. I wonder if 0 would mean
> > > >> also a policy with no xfrmi if_id.
> > >
> > > AFAIK, if_id 0 means the same as "no if_id mark". So it cannot be used.
> > >
> > > >> and also to avoid confusion from klips.
> > >
> > > That was a reason too, but as Wolfgang points out, perhaps the wrong
> > > consideration to have made.
> > >
> > > > I think the problem with if_id 0 could be the fwmark that is used to route the encrypted packets on the base interface.
> > > >
> > > > 100: from all to 10.0.12.2 fwmark 0x1 lookup 50
> > > >
> > > > With fwmark 0x0 all unmarked traffic to the destination would go through the base interface instead of the ipsec interface.
> > >
> > > I thought fwmark and if_id were different type of marks?
> > >
> > > > But ipsec-interface=0 for ipsec0 would be very useful. All our customers use ipsec0 for the first ipsec device, so the change from klips to xfrmi would either confusing for them or a technical problem that we have to solve.
> > > >
> > > > At the moment I test patching libreswan to map if_id to device name if_id-1, which works properly.
> > >
> > > That is not a patch we could easilly carry. And as an option it is a bit
> > > confusing. How about mapping ipsec0 to max(if_id) - 1 ?
> >
> > Tthat would also be a solution I could work with.
> >
> > > > But the next problem is that we use the lower 24 bit fwmarks for our firewall rule set. The upper 8 bit was reserved for ipsec (saref) long time ago. So the next problem is that actual the fwmark is not configurable and I have also to patch either libreswan or overwork our complete rule set to reserve the lower bits for ipsec devices.
> > > > Maybe a configurable minimal fwmark could be a nice feature.
> > >
> > > I don't think if_id marks are related to fwmarks ?
> >
> > At the moment it is statically mapped:
> >
> > /* XFRMA_SET_MARK = XFRMA_IF_ID/0xffffffff */
> >
> > The a simple solution I test for me at the moment is to add a minimal mark to the netlink call and for the environment variable.
> >
> > attr->rta_type = XFRMA_SET_MARK + 0xfff;
> > ........
> > jam(buf, "PLUTO_XFRMI_FWMARK='%" PRIu32 "/0xffffffff' ",
> > c->xfrmi->if_id + 0xfff);
>
>
> Sorry, what I have written this morning is of course wrong. That's what happens when you write in the morning without thinking. ;)
>
> The attached patch uses a static base value for fwmark. The static value could also be replaced by a variable to make this configurable.
>
> Wolfgang
> --- a/programs/pluto/kernel.c.orig 2020-07-29 09:45:39.561145559 +0200
> +++ b/programs/pluto/kernel.c 2020-07-29 13:53:27.185782803 +0200
> @@ -562,7 +562,7 @@
> if (c->xfrmi != NULL && c->xfrmi->if_id > 0) {
> if (addrinsubnet(&sr->that.host_addr, &sr->that.client)) {
> jam(buf, "PLUTO_XFRMI_FWMARK='%" PRIu32 "/0xffffffff' ",
> - c->xfrmi->if_id);
> + c->xfrmi->if_id + 0xffffff);
> } else {
> address_buf bpeer;
> subnet_buf peerclient_str;
> --- a/programs/pluto/kernel_xfrm.c.orig 2020-07-30 14:41:37.773609907 +0200
> +++ b/programs/pluto/kernel_xfrm.c 2020-07-30 14:41:41.353610060 +0200
> @@ -725,6 +725,7 @@
> }
> if (xfrm_if_id > 0) {
> #ifdef USE_XFRM_INTERFACE
> + uint32_t xfrm_fwmark = xfrm_if_id + 0xffffff;
> struct rtattr *attr = (struct rtattr *)((char *)&req + req.n.nlmsg_len);
> DBG(DBG_KERNEL, DBG_log("%s netlink: XFRMA_IF_ID %" PRIu32 " req.n.nlmsg_type=%" PRIu32, __func__, xfrm_if_id, req.n.nlmsg_type));
> attr->rta_type = XFRMA_IF_ID;
> @@ -736,7 +737,7 @@
> attr = (struct rtattr *)((char *)&req + req.n.nlmsg_len);
> attr->rta_type = XFRMA_SET_MARK;
> attr->rta_len = RTA_LENGTH(sizeof(uint32_t));
> - memcpy(RTA_DATA(attr), &xfrm_if_id, sizeof(uint32_t));
> + memcpy(RTA_DATA(attr), &xfrm_fwmark, sizeof(uint32_t));
> req.n.nlmsg_len += attr->rta_len;
> #endif
> }
> @@ -1524,6 +1525,8 @@
>
> if (sa->xfrm_if_id > 0) {
> #ifdef USE_XFRM_INTERFACE
> + uint32_t xfrm_fwmark = sa->xfrm_if_id + 0xffffff;
> +
> DBG(DBG_KERNEL, DBG_log("%s netlink: XFRMA_IF_ID %" PRIu32 " req.n.nlmsg_type=%" PRIu32, __func__, sa->xfrm_if_id, req.n.nlmsg_type));
> attr->rta_type = XFRMA_IF_ID;
> attr->rta_len = RTA_LENGTH(sizeof(uint32_t));
> @@ -1534,7 +1537,7 @@
> /* XFRMA_SET_MARK = XFRMA_IF_ID/0xffffffff */
> attr->rta_type = XFRMA_SET_MARK;
> attr->rta_len = RTA_LENGTH(sizeof(uint32_t));
> - memcpy(RTA_DATA(attr), &sa->xfrm_if_id, sizeof(uint32_t));
> + memcpy(RTA_DATA(attr), &xfrm_fwmark, sizeof(uint32_t));
> req.n.nlmsg_len += attr->rta_len;
> attr = (struct rtattr *)((char *)attr + attr->rta_len);
> #endif
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
More information about the Swan
mailing list