Le 09/12/2020 à 15:40, Eyal Birger a écrit : > Hi Phil, > > On Tue, Dec 8, 2020 at 8:51 PM Phil Sutter <phil@xxxxxx> wrote: >> >> Hi Eyal, >> >> On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote: >>> On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter <phil@xxxxxx> wrote: [snip] >> >> The packet appears twice being sent to eth1, the second time as ESP >> packet. I understand xfrm interface as a collector of to-be-xfrmed >> packets, dropping those which do not match a policy. >> >>>> Fix this by looping packets transmitted from xfrm_interface through >>>> NF_INET_LOCAL_OUT before passing them on to dst_output(), which makes >>>> behaviour consistent again from netfilter's point of view. >>> >>> When an XFRM interface is used when forwarding, why would it be correct >>> for NF_INET_LOCAL_OUT to observe the inner packet? I think it is valid because: - it would be consistent with ip tunnels (see iptunnel_xmit()) - it would be consistent with the standard xfrm path see [1] - from the POV of the forwarder, the packet is locally emitted, the src @ is owned by the forwarder. [1] https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg >> >> A valid question, indeed. One could interpret packets being forwarded by >> those tunneling devices emit the packets one feeds them from the local >> host. I just checked and ip_vti behaves identical to xfrm_interface >> prior to my patch, so maybe my patch is crap and the inability to match >> on ipsec context data when using any of those devices is just by design. There was no real design for vti[6] interfaces, it's why xfrmi interfaces have been added. But they should be consistent I think, so this patch should handle xfrmi and vti[6] together. Regards, Nicolas >> > > I would find such interpretation and behavior to be surprising for an IPsec > forwarder... > I guess some functionality of policy matching is lost with these > devices; although they do offer the ability to match ipsec traffic based on > the destination interface it is possible to have multiple ipsec flows share > the same device so netfilter doesn't provide the ability to distinguish > between different flows on the outbound direction in such cases. > > Thanks, > Eyal. >
