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

Hi RanX

Thank you for reaching out to Sophos Community.

Translating requests for the same destination network in IPSec would not be possible.

If you've set up a route-based VPN for CN1 and CN2, then you can configure SD-WAN policy to route specific destination host requests from the respective tunnel with a custom gateway.

Route Based VPN

Hello Yash Kothari,
thank you for your reply !
According to the video explanation, you've linked to your answer, I changed the connection type of CN2 to "tunnel interface".
After this I expected to find a network interface, where I could continue configuration.
But there is no interface; so I cannot go on any further.
Do you have any suggestion, how to resolve this ?
Best Regards
RanX

I tried it, and this does not work.
I'm afraid you misunderstood my question and therefore named a solution, which doesn't meet my requirements.
So I try to put it in different words.

I have two IPsec Tunnels (CN1 and CN2) which have the same destination network range. (192.168.5.x)
My idea:
When I want to send packets to CN1, I simply send them to 192.168.5.x addresses.
To distinguish traffic to CN2, I'd like to send them to 192.168.10.x addresses.
To acheive this for CN2 I create a 1:1 NAT rule which converts packets with destination 192.168.10.x to packets with destination 192.168.5.x on CN2
All packets originating from CN2 are converted to source 192.168.10.x before going to my local network.

This was easily done and worked perfect on the previous UTM 9.
Now I need a proper solution, which does the same on XG.

Any help is appreciated
Best Regards
RanX

Actually, you are doing the same in SFOS. Simply create the NAT rule and create a 1:1 DNAT. You need to create two different rules. One for the traffic coming from the Tunnel, translating the traffic. And one from the own network. 

In UTM you had a 1:1 NAT. In SFOS you have 1:1 DNAT. Therefore you need to create two rules to cover both traffics. 

Correct me, if I'm wrong but I think SFOS doesn't meet my requirements at that point:
For creation of a NAT rule I cannot use networks but only ranges.

A network is bound to a specific tunnel; a range isn't.
When I DNAT towards a range, it isn't specified, towards which tunnel the DNAT is done.
When I SNAT from a range and the range represents two networks (remote CN1 and remote CN2), I also can't tell,
whose network's traffic is SNATted

Regarding the above, I doubt NATing with ranges will do the job in my case.

I'd be happy if you can provide a solution for this.

You can only work with DNAT 1:1 nat and ranges. If you have a Range of /24, this is totally fine. If you range expands the /24, this will not work that easily. 

You didn't disagree with my above statement.
Therefore just to put things clear:

When I have two remote customer networks (CN1 & CN2) with the same network (192.168.5.0/24) a range will not distinguish between them.
In result I cannont create a 1:1 NAT, which will mask one of these network to distinguish between both destinations ?

Can you confirm this ?

In case of yes, I still need a solution how to divide traffic to and from both of these remote networks.
Any help is appreciated.

off topic:
it's pretty annoying, when each and every answer of a sophos employee is marked as answer and you receive a mail request to verify it.
please remove this automatism as it makes asolutely no sense !

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. 

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.

Thanks for your Feedback.