Florian Westphal <fw@xxxxxxxxx> wrote: > Eugene Crosser <crosser@xxxxxxxxxxx> 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.
