Re: [regression] Completely editing packet should be allowed.

[Florian Westphal <fw@strlen.de>]

allfox wy <allfoxwy@gmail.com> wrote:
> Thank you for explanation. I did a test. It is indeed the protocol
> number change in homebrew causing the block.
> 
> However, calling nf_reset_ct(e->skb) would still result in packet
> being dropped. I didn't do a precise diagnose to find out where it got
> dropped. But replacing nf_reset_ct(e->skb) with "return true" would
> result in a working system.

Unfortunately that is the problematic part.

I'm not even sure how this scheme of yours works:

The NAT dispatch uses the l4proto value from the tuple to decide
what to do.

So as far as I can see NAT postrouting will write updated tcp/udp
port to the packet, which is no longer udp/tcp - corrupting
the l4 header.

> My deduction: in the system's NAT table there is MASQUERADE in
> POSTROUTING. As my understanding, MASQUERADE requires CONNTRACK
> information to work. When the outgoing packet going through MANGLE
> table and got nf_reset_ct(e->skb), later MASQUERADE in NAT table might
> dropped it.

The removal of the conntrack info causes the packet to be treated as
INVALID; MASQUERADE / SNAT will not work on it.

> Is there a function that recalculate the CONNTRACK info rather than
> deleting it please?

We would need to make a re-lookup (possibly creating a new conntrack
entry) that reflects the new/updated L4protocol + any other changes to
saddr/daddr.