Hi,
I am trying to implement the following scheme:
The traffic from client-1 (192.168.5.2) to the server wan-srv (192.168.6.2) should go directly through the MikroTik and then to the server wan-srv.
The outgoing traffic from client-2 (192.168.5.3) to the server wan-srv (192.168.6.2) on the MikroTik should first be routed through router R1, then return from it back to the MikroTik, and then go to the server. Incoming traffic should return to client-2 directly, without routing to R1.
Server is unaware of the 192.168.5.0/24 network, so NAT needs to be configured on the MikroTik interface facing the server.
The traffic from client-1 is successfully NATed, and the connection is established, but the traffic from client-2 reaches the server with the original IP address because, for some reason, the NAT rule does not work.
I think it’s due to the usage of action=masquerade, which can cause leakages in your scenario, instead of action=src-nat, which in your case is the preferred way because the IP of the router is static:
A quote from the MikroTik wiki about the aforementioned leakages:
Unfortunately, this [masquerade] can lead to some issues with unstable links when the connection gets routed over different links after the primary link goes down. In such a scenario following things can happen:
on disconnect, all related connection tracking entries are purged;
next packet from every purged (previously masqueraded) connection will come into the firewall as new, and, if a primary interface is not back, a packet will be routed out via an alternative route (if you have any) thus creating a new masqueraded connection;
the primary link comes back, routing is restored over the primary link, so packets that belong to existing connections are sent over the primary interface without being masqueraded, > that way leaking local IPs to a public network> .
The reason why it does not work is that the first pass of the packet from client 2 to wan-srv (client 2 → R1) uses the same IP addresses and ports like the second one (R1->wan-srv), so the RouterOS firewall handles them using the same tracked connection. So the initial packet of that connection (from the perspective of the firewall) leaves through ether4 and therefore the action=masquerade (or action=src-nat) rule does not match; once the same packet comes in via ether5, the firewall treats it as another (non-initial) packet of an existing connection so it does not even use the nat table (only the initial packet of each connection passes through nat, all the subsequent ones are handled up to the nat decisions made for the initial packet that are stored in the context of the connection). The fact that a distinct routing table is used to handle the first and second pass is irrelevant.
So I would say that the easiest way out is to add the following rule: /ip firewall raw
add chain=prerouting in-interface=ether3 src-address=192.168.5.3 action=notrack
It will let the first pass of the client 2 to wan-srv packet bypass the connection tracking module, so the latter will treat the second pass as the initial packet of the connection and consult the nat table when processing it.
Off topic - there is an error in the text from Wiki. If the connection has been masqueraded, i.e. its reply-dst-address is set to the address of the primary WAN, and that address gets lost for whatever reason (interface down, change of DHCP lease), the connection is indeed removed from the connection tracking list, and a subsequent packet creates a new tracked connection there. So far so good. But if the newly created connection establishes through the backup WAN and gets also masqueraded locally, its reply-dst-address becomes the one of the backup WAN, hence if the primary WAN starts working again, subsequent packets will be sent via the primary WAN with source address set to the address of the secondary one, not to the original source address. The leakage of private addresses as described in that text would happen if the traffic via WAN 2 was not masqueraded locally, which is technically similar to what happens here.
The difference between action=src-nat and action=masquerade consists in only two things: src-nat assigns the reply-dst-address based on the contents of to-addresses whereas masquerade uses the address attached to the out-interface, and masqueraded connections are made dependent on the availability of their reply-dst-address in the system - once that address is lost, the connection tracking removes all associated connections. All the rest are consequences of these two factors.
Thank you very much!
This should have been obvious to me, but I mistakenly thought that the interface was also considered in the conntrack table. Although it is not.
Now everything works.
