Hello,

I want to make NAT from local to public IP 1:1 . But I have two internet gateways and it can happends, packet can go thru IGW1 to internet and packet can return thru IGW2.
I made same IP FIREWALL NAT rules on both IGWs:


When packet is returning from the internet by the same IGW , where srcnat was done (packet goes to internet by the same IGW), everything works OK:

in:wan out:lan, proto ICMP (type 0, code 0), 178.217.148.41->10.140.4.2, NAT 178.217.148.41->(185.160.20.177->10.140.4.2), len 56

But when packet is returning from the internet by the second IGW, where srcnat was not done (packet goes to internet by IGW1 but answer come to IGW2), NAT is not working:

in:wan out:wan, proto ICMP (type 0, code 0), 178.217.148.41->185.160.20.177, len 56

I suppose, there is problem, because there is not established connection in connection tracking table. But I want to make NAT 1:1 and ignore connection tracking table ... not matter, if connection is established or not.

dst nat not src nat

Any nat function is part of connection tracking, the netmap is no exception. So if you exclude the packets from connection tracking by matching them by an action=notrack rule in /ip firewall raw, the packets don't even pass through the /ip firewall nat table so the netmap will not happen. At least at 6.43rc42 where I've just double-checked it.

On top of that, only the initial packet of each connection passes through the nat table, all the following packets of the same connection are srcnated and/or dstnated using the context of that connection.

But the connection tracking does not remember the interface, only the addresses, so if the packet comes back via another interface but has source and destination addresses and ports (or icmp id in case of icmp) which match an already tracked connection (which need not be "established" yet, it is enough that the initial request went through), that connection should be identified and matched even though the response packet came in through a different interface than the request one. So something else must be rotten. The connection below has been src-nated by a netmap rule:

Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 SAC s protocol=tcp src-address=10.23.6.188:58742 dst-address=10.215.3.124:22 reply-src-address=10.215.3.124:22
reply-dst-address=10.20.6.188:58742 tcp-state=established timeout=23h59m58s connection-mark="day" orig-packets=23
orig-bytes=2 716 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=19 repl-bytes=4 953
repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=13.2kbps repl-rate=24.3kbps

The one below has seen only its initial packet so far but it is already prepared to accept an answer:

Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 C s protocol=tcp src-address=10.23.6.188:60370 dst-address=10.215.3.126:22 reply-src-address=10.215.3.126:22
reply-dst-address=10.20.6.188:60370 tcp-state=syn-sent timeout=3s orig-packets=1 orig-bytes=60
orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0
repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

OK, thanks for explanation.

Is any way, how to solve the problem? Or is it insoluble?

Když nevím, v čem ten problém je, tak ho těžko můžu řešit

First of all I'd recommend to post the complete configuration following the guidelines in my automatic signature, to exclude any doubts.