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" > <[email protected]>: > > > Am Donnerstag, 30. Juli 2020 03:44 CEST, schrieb Paul Wouters > > <[email protected]>: > > > > > On Wed, 29 Jul 2020, Wolfgang Nothdurft wrote: > > > > > > > Am Dienstag, 28. Juli 2020 20:25 CEST, schrieb Antony Antony > > > > <[email protected]>: > > > > > > > >> 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 > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
