Hi
As I understand packets first go through Filter and then NAT in the firewall but when I have a matching rule in Filter for adding src to address list it does not match.
Config below When i try port 88 it does not match and put my IP in the address list but it does on port 2222 unless I disable or change the NAT rule.
Have tried it on several devices and latest long term release but it's the same behaviour.

Sorry, I've missed the dst-nat part.

nat/dstnat happens before filter, so as you have redirected the traffic incoming to port 88 to a private address in dstnat, it became a transit one (from one router interface to another), and therefore it is handled by filter/forward, not by filter/input.

Sorry, I've missed the dst-nat part.

nat/dstnat happens before filter, so as you have redirected the traffic incoming to port 88 to a private address in dstnat, it became a transit one (from one router interface to another), and therefore it is handled by filter/forward, not by filter/input.

Ok I thought it was the other way around with Filter first and then NAT. Not sure where I got that from then.
Is there any way to accomplish both dst-nat and saving to address list then?

Is there any way to accomplish both dst-nat and saving to address list then?

Of course. Two ways:

• place the action=add-src-to-address-list rule to filter/input for port 2222 and to filter/forward for port 88 (with additional conditions respecting the direction and destination)
• place the action=add-src-to-address-list rule to mangle/prerouting as mangle/prerouting handles the packet before dstnat (also here you may need to add some conditions).

This set of diagrams shows it all.

Interesting!! Lets debate the issue.

The dst-nat rule matches only on dst-port=88. Hence packets towards the WAN IP:88 get dst-nated, and packets towards the WAN IP:2222 don't. So those to :88 have got a new destination address after the dst-nat operation. And the decision whether the packet is for one of router's own IP addresses, and thus should be handled by the [|NPUT|] chain, or whether it is for any other IP address than the router's own one, and thus should be handled by the [|FORWARD|] chain, is made after the [DST-NAT] stage of chain [|PREROUTING|].

To make it more complicated: whether a connection will be dst-nated and/or src-nated is decided when the first packet of a new connection is being handled by firewall table NAT in the corresponding (dstnat and/or srcnat) chain. But the [DST-NAT] block is changing the destination address of all packets in downstream (initiator=>responder) direction of the connections for which dst-nat handling has been imposed by the rule handling the first packet, and of all packets in upstream (responder=>initiator) direction of the connections for which src-nat handling has been imposed by the rule handling the first packet.

Also, the action=add-src-to-address-list rules should match on connection-state=new if used in mangle/prerouting, otherwise it would be adding the address to the list for every single packet, wasting CPU. Matching on connection-state=new is cheaper than matching on src-address=!test which would otherwise serve the same purpose. If used in filter, and placed after the "accept established" rule, this is not necessary.

Bridging diagram applies only when there's bridge involved and it actually does some bridging. So for example bridge as incoming interface (when you have few ports bridged together as LAN) doesn't count.

But the thing here is that the OP does not do port translation but port based redirection to another address. That's why the incoming connection to dst port 88, which gets dst-nated, is then handled in forward whereas the incoming connection to dst port 2222, which does not get dst-nated, is handled in input.