1:1 NAT for Site-to-Site Tunnel - how do I do it ?

First of all, you should draw a network map to find both location for the NAT. Because from my point of view, you need for a 1:1 NAT both peers to NAT. Otherwise nobody will translate the traffic back. 

Then you should be able to figure out, where you need to setup the NAT(s) on both appliances. It should be easily possible via NATs on SFOS, but could get confusing as you need two NATs per network. To NAT both directions (coming and going to). 

There seems to be a misunderstanding:
Both remote networks connectedby IPsec are customer networks.
We have no access to the appliances on the other side and cannot change their configuration.
We have to take them as they come; the remote side is kinda blackbox.

The whole NATing therefore has to be done on our side by the XG.

And how is this possible with a UTM? Somebody needs to translate this back to the original network. Otherwise the IPsec connection will have some issues. 

Please map this via network flow map. 

Well, on the UTM I deal with networks, not with ranges.
Any remote network is unique.

So for e.g. Tunnel_CN2 I first create a CN2_Remote_Network (192.168.5.0/24) and add it to the tunnel definition to bring it up.
In the second step I create a CN2_NAT_Network (192.168.10.0/24)

Then I create two 1:1 NAT rules.
One for each direction:
Requests from INTERNAL to CN2_NAT_Network (192.168.10.0/24) are translated to CN2_Remote_Network (192.168.5.0/24)
Answers from CN2_Remote_Network (192.168.5.0/24) are translated to CN2_NAT_Network (192.168.10.0/24) and then go to INTERNAL

This works with UTM as Networks are a specific source/destination.
This doesn't work with the XG as ranges are unspecific and can match any remote network, in case I'm unlucky and have remote networks of the same range.

Please present a network flow map. A Range and a network are exactly the same from a topology standpoint. If you use 192.168.10.0/24 or 192.169.10.0-255 is the same. 

I am still not able to follow your setup. Because from my point of view, you should be able to create both rules (1:1) in SFOS in the same kind like UTM. 

OK, here is a simple diagram, which hopefully clarifies my requirement.
I only drew the two tunnels wit the identical remote networks.
There are many more, but as they don't overlap, they aren't part of this topic

Ok. First of all, in nearly all scenarios like that, the customer gateways are responsible to NAT the traffic, not the hub vpn gateway. If you build a star and expand this scenario, you will always see overlaps. Therefore the hub will give the customers a IP, which it expects to get, not there "real" IP. 

The NAT will not work only on the firewall. That is due a routing problem. The 1:1 NAT works perfectly fine but somebody (firewall 1 and 2) have to un do the NAT and translate the IP back. Only on the hub gateway, this is not possible, as the NAT occurs before the routing. 

What will happen: 

https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122357/life-of-a-packet-sophos-firewall

DNAT will translate the packet from 192.168.10.0 to 192.168.5.0. Then the routing stack will take over and has two routes to the same network. Which causes this big mess. That is the reason, most products interact with this issue differently. You demand to NAT on the customer gateways. Most likely because you do not want to deal with there networks. 

UTM could do this with a weird hack and UTM does not have route based VPN. In Policy based you have only one interface (Ipsec0). Therefore the routing was done in the ipsec stack. So Sophos hacked the stack and could get this done. 

But overall this can cause more frustration: You should interact with the gateways of the customers and tell them to NAT in the VPN. Never get networks in your VPN, which you cannot control. 

In an ideal world we find sceanrios, where the customer takes response of the NATting.
But in reality I have customers, where I can be happy, when I get a working tunnel and that's it.
The rest is up to me.
If the above scenario were just some theoretical situation, I would not have asked, how to resolve it.
Telling me how things should be, is not very helpful.

As you confirm the UTM was able to handle those scenarios; the XG isn't
That simple, that sad ...

So the other end supports a VTI but not a simple NAT? That is odd to me. 

Hi Toni,

don't you think there was a good reason for the engineers of the UTM to implement, what you call a "weird hack" ?
I think there was !
It was a solution for scenarios like the one described above.

So please face the fact, that Sophos' so called "successor" XG still can't cover all the functions of the UTM.
Discussing with customers and blaming them for the networks, they have to deal with, won't change it !
Plus it leaves your customers dissapointed and angry and will drive them to competitors in the end.
Face it as it is.

To make the XG a real successor to the UTM, there's lots of homework to be done.
Just to list a few others:
- a clearer, better structured and faster GUI
- move more function to the GUI (some basic things can only be done on the shell)
- search function on services doesn't allow to search for port numbers

Migrating a UTM to an XG should be a good experience - not the pain, it currently is.