1-to-1 SNAT v18.0.4 MR-4

This KB is doing it with a 1:N NAT. https://support.sophos.com/support/s/article/KB-000037043?language=en_US (MASQ). 

If you want to SNAT 1:1, you need to use the IPsec NAT Option. https://support.sophos.com/support/s/article/KB-000035848?language=en_US

I'm afraid both articles are not exactly what I need.

The first article is more similar to what we need, to have SSL clients reach the other side of a IPSEC connection without altering the IPSEC connection. However, this only NATs the source to a single IP-address. As far as I have tried it is not possible to NAT the Source to a network rather than a single host.

In the second article it indeed looks like a complete network is source natted from within the IPSEC connection. That is the right type of NAT but at the wrong place unfortunately. 

Policy based IPsec is limited to this SNAT (within the IPsec tunnel).

Route based VPN can work with the NAT Page for MASQ. 

Too bad, had really hoped with all the improvements in v18 that the product would at least match UTM at every point. 1:1 NAT in UTM is so easy to configure that it is hard for me to understand why this is so much harder if possible at all in XG...

Thanks for your input anyways. Really appreciate it.

Policy based VPN is somesort the old school of handling IPsec. Hence those limitations. I would prefer to move to Route based VPN. If not possible or the other appliance is a SG, you could also move to RED site to site, which also can use the NAT table. 

Policy based VPN as a VPN technology has plenty of limitations. Starting with restarting the tunnel, if editing Local/Remote subnet, the management of plenty of tunnels and/or multiple SAs etc. 

Policy based VPN is somesort the old school of handling IPsec. Hence those limitations. I would prefer to move to Route based VPN. If not possible or the other appliance is a SG, you could also move to RED site to site, which also can use the NAT table. 

Policy based VPN as a VPN technology has plenty of limitations. Starting with restarting the tunnel, if editing Local/Remote subnet, the management of plenty of tunnels and/or multiple SAs etc. 

I'm aware of the shortcomings of policy based VPN. Unfortunately much of todays connections are still policy based, even connections we have to some really large companies.

SG had this perfect option where a 1:1 NAT was really quick and easy to configure. I'm sure we will find a solution somehow but stepping back when you expect to step up is always painful 

Personally, i would rather step back from 1:1 NAT in the first place, as this lead always to confusing Networks. Likely its used between a Big vendor, which assigns networks to each and everybody, but they likely use route based, if offered or its used because of duplicated networks (same network range etc.). Both requirements could be easily solved by other approaches (use route based or rethink your network and not invest more time on such bad design in the first place). 

The SG solution with the checkbox about NAT was a workaround to get this done, as NAT also did not apply on IPsec traffic (due the limitation of policy based VPN). I cannot remember, which version implemented this checkbox, but its "rather new compared to the 21 years UTM".