topic Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface. in General Topics

We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

shopworld — Mon, 08 Jan 2024 04:29:18 GMT

Hi Everyone,

I am sort of stuck in a problem with Destination NAT on a different subnet than the egress interface. To further complicate matters, The destination NAT IP subnet is also part of another interface subnet which is not relevant to this flow. I have made a rough diagram to make it a bit more clear.

* We want our client machines to connect to a destination NAT IP 172.20.112.80 which will translate to 163.116.128.80. The traffic will enter through eth2-01 and exit through eth2-02.611.

* Issue is that the NAT IP 172.20.112.80 is on a different network than the IP of the Ingress interface (172.20.128.65/25)

* Further to this there is also an interface on the firewall eth2-02.628 which is connected to the network 172.20.112.0/24.

* our users need to connect to the NAT IP 172.20.112.80, it should enter through eth2-01 and exit through eth2-02.26.

Appreciate you taking the time to read through. Thanks in advance.

Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

PhoneBoy — Mon, 08 Jan 2024 14:04:01 GMT

You can configure NAT rules this way, but other parts of the network may need to be configured to support it.

What is the default route for your clients here?
Will it direct traffic from 172.20.112.80 to your gateway?
If not, you will need to fix that.

Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

Timothy_Hall — Mon, 08 Jan 2024 14:20:31 GMT

You can probably make this work, but you are going "against the grain" of normal IP routing.

1) First off, under Global Properties, NAT verify that "translate destination on the client side" is checked for both automatic and manual NAT (this the default). DO NOT EVEN THINK ABOUT UNCHECKING ANY BOXES ON THIS SCREEN.

2) Next, add a static route on the firewall for 172.20.112.80/32 to a next hop router reachable through the eth2-02.611 interface. You cannot just specify the interface name, you must specify a nexthop router address leading to eth2-02.611. This /32 is more specific and will override your existing directly attached /24 route to 172.20.112.0/24. Note that the "real" 172.20.112.80/32 reachable through eth2-02.628 will no longer be accessible by any traffic traversing the firewall.

3) Check the topology of your firewall/cluster for interface for eth2-02.611, if not using "network defined by routes" you will need to add 172.20.112.80/32 to the anti-spoofing definition for this interface. You do NOT need to remove 172.20.112.80/32 from the topology of interface eth2-02.628.

4) You will need to ensure that your surrounding network will deliver traffic bound to 172.20.112.80/32 to the firewall on eth2-01; the firewall cannot force/spoof this with proxy ARP or somesuch in your scenario. This may involve static 172.20.112.80/32 routes added directly on user workstations, or adding a static 172.20.112.80/32 route on a router(s) in your network. If the firewall is already the default route for these user workstations you should not need to deal with this.

5) Next step will be a manual NAT rule. Because you are attempting to pluck the 172.20.112.80/32 address from an existing, real /24 subnet and send it somewhere else, there is a danger of asymmetric routing breaking things. For this reason I'd suggest both a source Hide NAT behind the egress firewall interface eth2-02.611 as well as the destination static NAT, to ensure replies come back symmetrically to the firewall. Keep in mind that if you do this connections can only be initiated outbound by the workstations and not the other way around; also this Hide NAT part may not be necessary depending on your network.

Manual NAT rule will look something like this:

Osrc=(initiating workstation subnet)

ODst=172.20.112.80/32

OSrv = Any

Tsrc=Firewall Object (Force Hide)

TDst=163.116.128.80/32 (Static)

Tsrc=Original

GW=(relevant gateway)

6) In your Access Control policy ensure you have a rule accepting the traffic, keep in mind you should always reference the pre-NAT IP addresses here, so:

src= (initiating workstation subnets)

Dst = 172.20.112.80/32

Service=whatever

Action=Accept

Track=Log (make sure "Connection" logging is set in advanced properties so you get proper NAT logging)

Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

shopworld — Mon, 08 Jan 2024 21:09:47 GMT

The default gateway for the clients is another L3 switch before the packet makes its way to the firewall.

Yes, it will direct the traffic to the Checkpoint gateway and I can see it in the logs.

Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

shopworld — Mon, 08 Jan 2024 21:12:28 GMT

Thank you. I'll try this in the next couple of days and report back.

Re: We want to configure Destination NAT but it is not in the same subnet of the ingress interface.

shopworld — Thu, 11 Jan 2024 05:02:03 GMT

Thank you so much. That worked really well. The reason we did this was because we had an old proxy server that we are going to decomission and point all servers to netskope. But changing proxy address on each server would have impacted our deadlines, so the easy approach was to NAT the old proxy IP and redirect traffic to the new netskope IP.