Unable to NAT an external ip to a gateway on another network

[VincentEmmanuel]

Hi everyone,

I have a scenerio as below

The CATO socket uses its WAN port to access internet and it is currently connected to the FW LAN for internet access
The LAN port is connected as an interface in the FW marked as CATO. I setup the FW IP 10.1.79.2 to use its LAN Port as a GW 10.1.79.1

My goal is to NAT 172.16.1.3 from my DMZ to 10.1.79.1.

SO far my attempts are unsuccessful and hence wanted some help here.

What I have done so far

NAT 1:1 172.16.1.3 => 10.1.79.1 NAT reflection enabled

In DMZ rules, allow DMZ net to access CATO net

The result now

On my server, I can ping 172.16.1.3 but it seems unreal as the TTL is > 1ms
Ping to 10.1.79.1 is unsuccessful.

On FW, it can ping 10.1.79.1
it can ping 10.1.79.1 as DMZ interface.

Any help is appreciated. THanks! :)

[viragomann]

@VincentEmmanuel said in Unable to NAT an external ip to a gateway on another network:

The CATO socket uses its WAN port to access internet and it is currently connected to the FW LAN for internet access

Internet access across the firewall is working so far?

My goal is to NAT 172.16.1.3 from my DMZ to 10.1.79.1.

Which device is 172.16.1.3 assigned to? To the DMZ interface of pfSense?
Can you state all interface IPs, please.

Why NAT 1:1?
As I got you, you want to call 172.16.1.3 on the DMZ server and get to 10.1.79.1?
If the IP is assigned to pfSense a simple port forwarding should do the job.

Which gateways are defined on pfSense?

Which do the involved devices use as default gateway?

I guess, all subnets are /24, as you didn't state.

Why are you using a public IP space for the DMZ?
Is it bridged to WAN or is it routed through pfSense?

[VincentEmmanuel]

@viragomann

Yes internet access is working so far.

Which device is 172.16.1.3 assigned to? To the DMZ interface of pfSense?
172.16.1.3 is consider an external ip address, it does not belong to any interface on the FW. (It is a internal ip inside the cato network)

172.65.1.0/24 (DMZ)
10.65.1.0/24 (LAN)
10.1.79.0/24 (CATO)
118.xxx.xxx.xxxx (WAN)

Gateway are
WAN = > 118.xxx.xxx.xxxx (default)
CATO => 10.1.79.1

I set a rule to allow this particular DMZ server ip to access the CATO network via the CATO GW.

[SteveITS]

@VincentEmmanuel If it’s not on your pfSense then pfSense doesn’t know about it so you need a static route:

https://docs.netgate.com/pfsense/en/latest/routing/static.html#example-static-route

[viragomann]

@VincentEmmanuel said in Unable to NAT an external ip to a gateway on another network:

172.16.1.3 is consider an external ip address, it does not belong to any interface on the FW. (It is a internal ip inside the cato network)

So this means, the CATO will know, how to route this IP?
And the CATO also know, how to route the source 172.65.1.12 back to pfSense?
Since you say, pfSense is the default gateway, it should.

In this case you would only need to add a static route to pfSense for 172.16.1.3 and point it to CATO. No NAT needed then.

[viragomann]

@SteveITS
This isn't necessary here, since pfSense is the default gateway on the server. So it routes this IP to pfSense anyway.
pfSense just need to forward it properly.

[SteveITS]

@viragomann said in Unable to NAT an external ip to a gateway on another network:

In this case you would only need to add a static route to pfSense

but also

This [static route] isn't necessary here

?

[viragomann]

@SteveITS

If it’s not on your pfSense then pfSense doesn’t know about it so you need a static route:

This small statement and the fact that the TO was fighting with NAT let me assume, that you were talking about the DMZ host.

For sure, on pfSense itself there is a static route needed for this IP. NAT would also be possible though, but this would need an additional forwarding on the CATO.

[SteveITS]

@viragomann gotcha, agreed :)

[VincentEmmanuel]

@SteveITS said in Unable to NAT an external ip to a gateway on another network:

https://docs.netgate.com/pfsense/en/latest/routing/static.html#example-static-route

Thanks guys for the advices.

Yes, the CATO socket does have its internal routing which it will know how to route once it reaches its interface.

Let me conclude. I just needed a static route in my case 172.16.1.0/24 to gateway 10.1.79.1. Then set the rules to allow it in the CATO interface and then set outbound NAT for it. After which, my DMZ will be able to do a ping 172.16.1.3 and then the gateway should be able to response to the ping because it would forward that packet to the responding server in its network.

[viragomann]

@VincentEmmanuel
The outbound NAT should not be required here. All traffic will be controlled by routes if pfSense is the default gateway in both networks.

With the static route, when the DMZ server sends a packet to 172.16.1.3, it is routed to pfSense, since that's the default gateway. pfSense forwards it to the CATO due to the static route and the CATO forward it to the destination host, since it knows the route to it (however, your graphic is missing 172.16.1.3, so I don't know, how this is set up).

Presupposed the CATO is the default gateway on 172.16.1.3, the response packet will be routed to it, and there it is forwarded to pfSense, since this is the default gateway on the CATO, as you said. pfSense has an existing state for the packet and will forward it to the DMZ server.