Re: XFRM interface and NF_INET_LOCAL_OUT hook

[Phil Sutter <phil@nwl.cc>]

Hi Steffen,

On Thu, Nov 26, 2020 at 10:40:21AM +0100, Steffen Klassert wrote:
> On Wed, Nov 25, 2020 at 12:23:42PM +0100, Phil Sutter wrote:
> > I am working on a ticket complaining about netfilter policy match
> > missing packets in OUTPUT chain if XFRM interface is being used.
> > 
> > I don't fully overlook the relevant code path, but it seems like
> > skb_dest(skb)->xfrm is not yet assigned when the skb is routed towards
> > XFRM interface and already cleared again (by xfrm_output_one?) before it
> > makes its way towards the real output interface. NF_INET_POST_ROUTING
> > hook works though.
> > 
> > Is this a bug or an expected quirk when using XFRM interface?
> 
> This is expected behaviour. The xfrm interfaces are plaintext devices,
> the plaintext packets are routed to the xfrm interface which guarantees
> transformation. So the lookup that assigns skb_dst(skb)->xfrm
> happens 'behind' the interface. After transformation,
> skb_dst(skb)->xfrm will be cleared. So this assignment exists just
> inside xfrm in that case.

OK, thanks for the clarification.

> Does netfilter match against skb_dst(skb)->xfrm? What is the exact case
> that does not work?

The reported use-case is a match against tunnel data in output hook:

| table t {
|     chain c {
|         type filter hook output priority filter
|         oifname eth0 ipsec out ip daddr 192.168.1.2
|     }
| }

The ipsec expression tries to extract that data from skb_dst(skb)->xfrm
if present. In xt_policy (for iptables), code is equivalent. The above
works when not using xfrm_interface. Initially I assumed one just needs
to adjust the oifname match, but even dropping it doesn't help.

Cheers, Phil