Re: Commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1r "vrf: Reset skb conntrack connection on VRF rcv" breaks expected netfilter behaviour

[Florian Westphal <fw@strlen.de>]

Florian Westphal <fw@strlen.de> wrote:
> Eugene Crosser <crosser@average.org> wrote:
> > Maybe a better solution for stray conntrack entries would be to
> > introduce finer control in netfilter? One possible idea would be to
> > implement both "track" and "notrack" targets; then a working
> > configuration would look like this:
> 
> 'track' is hard to implement correctly because of RELATED traffic.
> 
> E.g. 'tcp dport 22 track' won't work correctly because icmp pmtu
> won't be handled.
> 
> I'd suggest to try a conditional nf_ct_reset that keeps the conntrack
> entry if its in another zone.
> 
> I can't think of another solution at the moment, the existing behaviour
> of resetting conntrack entry for postrouting/output is too old,
> otherwise the better solution IMO would be to keep that entry around on
> egress if a NAT rewrite has been done. This would avoid the 'double snat'
> problem that the 'reset on ingress' tries to solve.

I'm working on this.

Eugene, I think it makes sense if you send a formal revert, a proper
fix for snat+vrf needs more work.

I think this is fixable but it will likely be not acceptable for net
tree.