I am setting up a VPN between a 750G_r3 (6.40.5) and a SonicWall that is not under my control.

For various valid reasons, I have to source-nat the traffic as it leaves my side and goes to the SonicWall. This works just fine:

/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.102.10 log=yes src-address=192.168.101.143 to-addresses=172.16.20.143

The local LAN is (obviously) 192.168.101.0/24, and I'm NAT'ing the host .143 to 172.16.20.143 IF it is going to 192.168.102.10.

This works just fine.

The problem occurs when the reply traffic comes back. In the logs, I get something like this:

jan/12 19:19:19 firewall,info forward: in:ether1 out:ether1, src-mac...

The problem is that the traffic is being routed back to the Internet instead of being un-nat'ed back to the internal IP.

Any suggestions?

After beating on this for an hour before breaking down and posting, I had an epiphany and disabled the 'no-track' option in /ip firewall raw that is normally required for VPNs and it started working.

So: With src-nat, don't use 'no track'!

Looks like I spoke too soon. The VPN is now working for traffic that originated on my LAN (the 192.168.101.0/24 that is NAT'ed to 172.16.20.0/24), but traffic that originates at the remote (Sonicwall) still hits the Mikrotik and does the "forward in:ether1 out:ether1" bit.

What am I missing?

To get proper 1:1 nat relationship, I'd add a dst-nat rule as well.
Without it , sessions can only be set up in one direction

To elaborate a bit @16again's advice: the srcnat rule alone is valid for a single packet sent in Mikrotik -> Sonicwall direction. If connection tracking is used, the reverse of this srcnat rule is applied also to packets of that connection which arrive in opposite direction. You can think about it as if a mirror dstnat rule was created dynamically for the lifetime of the connection.

However, if another connection is initiated from the remote side, its initial packet does not hit the srcnat rule, so the whole miracle above cannot happen. So to ensure similar handling for connections initiated from behind the Sonicwall, you have to use dstnat rules in the prerouting chain which take care of this category of initial packets.

If I've got you right and you need a 1:1 NAT of the whole subnet (172.16.20.x to 192.168.101.x where x survives the translation unchanged), you should use action=netmap as described in the manual as otherwise you'd have to provide one rule per each IP address per each packet direction.

Also make sure you don't cut the branch you're sitting on - don't dstnat the IP of the Mikrotik itself to something else (without discriminating on ports, that is).

Thank you both, @16again and @sindy!

That was exactly the information I needed. I especially appreciated the tidbit about the netmap option. After fixing the NATs and then looking at the order of operations and making sure my filter rules were using the *real* addresses instead of the NAT'ed addresses, everything is now working bidirectionally.

Get a decent proxy instead of VPN. For example, I work with fineproxy service for over a 4 months and everything is fine, no bans, glitches or disagreements! Easy to use, no unnecessary features. Well it's better to check on your own experience.