firewall3: Useful to leave mark on redirected traffic

[pprindeville]

If I have, for instance, a redirect section such as:

# port redirect of remapped ssh port (22001) on wan
config redirect
       option src              wan
       option src_dport        22001
       option dest             lan
       option dest_port        22
       option proto            tcp

(one of the canned rules enabled), it is useful to be able to distinguish between a connection directly to port 22 and a remapped connection to port 22. In my case, I TARPIT connections to port 22 but only if they're not redirected from 22001. Similarly, I might want to log connections differently depending on which external port they arrived on.

One way this could be implemented is marking a bit (say 0x400 so as to not conflict with mwan3) before any of the redirects happen in zone_wan_prerouting rules, then as the last rule in that section, clear that bit.

Should be a two line change to the rule synthesis:

(1) mark the bit as the second rule in zone_wan_prerouting;
(2) clear the bit as the last rule in zone_wan_prerouting;

so that if we reach the bottom of zone_wan_prerouting, then no redirects have happened and we can unmark the packet.

[pprindeville]

@feckert Including you since this would need to co-exist with mwan3 and I want to make sure I'm not introducing collateral damage.

[brada4]

Hehe years passed. They are marked.... -m conntrack --ctstate snat,dnat or ct status snat,dnat

[pprindeville]

Hehe years passed. They are marked.... -m conntrack --ctstate snat,dnat or ct status snat,dnat

Okay, so how would we add a firewall rule specifier in UCI that says "accept redirected ports" terminating locally?

In the original example, I want to block direct connections to port 22, but not redirected connections...

[brada4]

dnat acts in prerouting , once fields are adjusted ct state is set to dnat, so in input (this case) or forward + postrouting (the real dnat) you can use --state dnat / ct status dnat to accept further path of packet. Rules serve just to expedite 1st packet, conntrack serves following packet exchange.
IMO it is safe to accept dnat state/us packets as status is set in the explicit rule after the translation occurs. Ive tried to add it to fw4, somehow it was turned away....