On Wed, Jul 29, 2020 at 11:32:58AM +0200, 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. > > > > xfrm if_id 0 was confusing to me. I decided ipsec1 to start with. May be > > time to review it while xfrmi is still expirimental. > > > > and also to avoid confusion from klips. > > > 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. > > 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.
are you proposing to keep name ipsec0 (the interface name), while internally f_id = 0x1 and fwmark would be 0x1 (by default)? I had one version of the code which did this. UINT32_MAX meant no xfrmi inside pluto. It appeared complicated and I dicthed it. At this stage it is probably easy to go back to ipsec0. Currently ipsec-interface=X is the if_id and the mark. > 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. the output mark on the ESP packet is not configurable yet. One confusion was keywords for the new output mark. Note the conflict with mark-out; used by VTI?. The VTI mark-out is a different XFRM attribute than the one needed to work with xfrmi. May be I can have different meaning for mark-out when there is xfrm interface. or add ipsec-interface-output-mark= as the third mark? because XFRM has now 3 marks. AFIK mark-out was never used in VTI case. I don't want to break VTI usecases. Can you can help create a testcase with fwmark and xfrmi? you are using marks with KLIPS? so it is not really configured in ipsec.conf? I wonder how that would translate one-to-one. _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
