2017-08-23 11:59 GMT+02:00 Tobias Brunner <[email protected]>: >> I had in mind an existing vti use case with IPsec offloading. The >> kernel does not need the inbound SA to be marked, but the IPsec >> offloading solution benefits from the fact that SPs and SAs reference >> their vti through the mark. > > I see. VTIs themselves don't seem to require a mark on the SA or the > packets (I guess they are just selected based on the IPs), the kernel > will even apply the key configured on the VTI interface as mark to the > packet before doing the inbound policy check (it removes it again, though).
Indeed, I confirm. > I actually never liked the inbound handling of the marks on IPsec SAs, > I'd very much preferred it if the kernel, instead of using it as > selector when looking up an SA, would simply apply the mark to decrypted > packets. I find it tricky too. It's not a simple marker, it is really part of the SA ID. The kernel even enables 2 SAs to have the same triple (@dst, proto, SPI), provided their mark do not overlap... >> But I am aware it is not the general case, that's why I advocate a >> configurable behavior. >> >> A patch proposal follows, with a global boolean option in strongswan.conf. > > Thanks. But I'd actually prefer a connection specific config. I did > something like that in the mark-inbound-sa branch. OK, thanks. I had a look in the mark-inbound-sa branch, I think there are other methods where the SA mark must be set: child_sa_t.update, child_sa_t.destroy. Best regards, Christophe
