Auto-accept dstnat mangled flows #28
Conversation
Magically accept packets and subsequent DNAT flows akin other NAT translations. dstnat are mangled before filter hook and they reach filter/forward in state new, with distinct status dnat and otherwise would need secondary filter/forward/accept rule to proceed anywhere. Signed-off-by: Andris PE <neandris@gmail.com>
|
This seems redundant to the already existing per-zone "Accept port forwards" and "Accept port redirection" rules, which are also only emitted if the related zones uses any DNAT rule. |
|
I was thinking vice versa, to terminate evaluation asap. |
Treat DNAT altered flows as any other state flow from early on. Signed-off-by: Andris PE <neandris@gmail.com>
|
The main problem is anomalously slow ?ifname that on one side delays our packet on other consumes processing where others could run. Maybe a bettwer idea to wrap rule(s) in loop to check if any dnat rule is present then emit central rule? |
|
Principal problem is that nat-pmp UDP creates UDP DNAT rule but backs it with TCP ACCEPT and whatsapp glitches more than without any traversal. This is not a solution, but would playnly rule out that problem. |
|
I will re-work it to add early accept in presence of any dnat rule eliminating duplicates. |
Magically accept packets and subsequent DNAT flows akin other NAT translations. dstnat are mangled before filter hook and they reach filter/forward in state new, with distinct status dnat and otherwise would need secondary filter/forward accept rule to proceed anywhere.
Signed-off-by: Andris PE neandris@gmail.com