Many-to-One NAT from VPN to Internal

[stich86]

Hello guys,

i'm trying to understand if this type of NAT can be possible on CheckPoint firewall. 

Let me explain the scenario:

We have a VPN with a 3rd party gateway that is formed from remote network 172.16.32.0/24, while on our side we publish a 10.0.0.0/24. The remote network should reach various services hosted on a single IP, in this case it's 192.168.10.1.

On our old firewall we have done a simple NAT in this WAY:

Source: 172.16.32.0/24 Destination: 10.0.0.0/24 Translated Destination: 192.168.10.1

But on CheckPoint is not working. I've also tried Automatic NAT on network 10.0.0.0/24, but looks like this solution is only for traffic originated inside and not from VPN. Obviously create Static NAT with fixed IP from subnet 10.0.0.0/24 is working, but want to avoid because some remote client can have different IP from the already known.

There is a workaround to do that?

Thanks in advance

[the_rock]

Apologies, but Im slightly confused...

When you say below:

Source: 172.16.32.0/24 Destination: 172.16.32.0/24 Translated Destination: 192.168.10.1

...its same source and destination, why do you need to translate that??

[stich86]

Sorry what’s a typo, it is:

Source: 172.16.32.0/24, Destination 10.0.0.0/24, Translated Dest: 192.168.10.1/32

[the_rock]

Im really glad you asked this question and I will tell you how to do it. I know this is not as easy as it may seem...so what you have to do is instead of using host object create address range and give it starting and ending IP as same address, so in your case 192.168.10.1 and once you save, dont push policy yet, just click the option from the menu to verify, because if it shows all green, then its good to go.

Let me know if any issues. I actually discovered this last year when customer had exactly same problem...

[stich86]

Hi the_rock so here is the list of what i've tried:

- first attempt: SRC NET: 172.16.32.0/24 DST NET 10.0.0.0/24 DST XLATE 192.168.10.1 (as address range) -- not working

- secondattempt: SRC NET: 172.16.32.0/24 DST NET 10.0.0.1-254 (as address range) DST XLATE 192.168.10.1 (as address range) -- not working

The only way to make it works is with a single IP as DST NET 😞

[the_rock]

Can you send me a screenshot of the rule you attempted the way I mentioned, as well as how you defined address range?

[stich86]

yes, see the attachments

[the_rock]

Make sure you did not inadvertently configured NAT for auto nat on the network objects. Just for my own sanity, I tested this in the lab and worked fine. See attached. Im free around 1.30 pm EST to do remote if you like, just message me privately.

Cheers.

[stich86]

i've checked all the network objects and auto nat is not enabled.

I'm testing it too into a small lab before production. I'm in Italy, so 1.30PM EST should be 7PM here, but i'm not avaliable at this time 😞

[the_rock]

Ah Italy, ok :). Im just watching some Italian cartoon movie. Buongiorno...hey, send me your email, lets do remote now, I can send you webex or zoom.

[the_rock]

@PhoneBoy ...maybe you can give your CP expert input on this. So I did zoom remote with Gianmarco and he showed me that if you do single IP as destination in original packet, all works fine, BUT, if you do whole network /24, it fails, for some reason nat does not take place...cant say I seen this in a long time. Do you think maybe clearing NAT table might be worth it? We did capture on the firewall for destination IP 192.168.15.19 and all we see are echo requests and no replies and no drops anywhere, but routing definitely seems correct.

[PhoneBoy]

This is sounding like a bug which means we’ll need a TAC.

[stich86]

I’ve already opened a SR and explain the current behavior. I let you know when have a feedback. 

thanks all for your support 

[the_rock]

Thats what I thought as well...maybe fw tab -t fwx_alloc -x command might help, but not sure if even clearing NAT table would do much, but worth a try.

[Vladimir]

Not sure I understand what you are trying to accomplish here.

What is the 192.168.10.1? Is there a network 192.168.10.0/24?

Is this network connected to one of the firewall's interfaces or is it a routed network behind 10.0.0.0/24?

When you are writing  "I've also tried Automatic NAT on network 10.0.0.0/24, but looks like this solution is only for traffic originated inside and not from VPN. Obviously create Static NAT with fixed IP from subnet 10.0.0.0/24 is working, but want to avoid because some remote client can have different IP from the already known."

My understanding is that the clients you are expecting to come in would all belong to the 172.16.32.0/24 (for now).

So your working NAT rules, presumably (or should) look like:

172.16.32.0/24 to 10.0.0.x/32, service; original to 192.168.10.1, original

192.168.10.1 to 172.16.32.0/24, service; 10.0.0.x/32 to original, original

where 10.0.0.x/32 is the single IP your peer would be connecting to for a given service.

You can define that IP either as a dummy host or as a /32 network.

[stich86]

What I’ve to achieve is this:

each packet received from source NET 172.16.32.x and destinated to any IP of the NET 10.0.0.x (it’s a fake network, not present anywhere) should be natted to IP 192.168.10.1. As I’ve said doing static NAT to specific IP of NET 10.0.0.x to 192.168.10.1 is working as expected.

[Vladimir]

But that's exactly what I do not understand the reason for.

I mean, if you have a legitimate need to NAT network to network 1:1, I understand that.

If, on the other hand, your incoming traffic is ultimately targeting a single IP, why would the users in NET 172.16.32.x be trying to connect to random IPs in NET 10.0.0.x, to only be NATed to a single IP?

[stich86]

Because on the other side I don’t have a real user but an IoT device that can be configured with various IP of subnet 10.0.0.x, and we are not aware of all IPs, so to avoid doing NAT for each sigle IP we are using this type of configuration on actual firewall (obviously there is a rule that restrict ports on the target machine)

[Vladimir]

Thank you for explaining your use case, it makes sense now.

[JozkoMrkvicka]

Just an idea ... What if you use VIP in combination of Load Balance ? I mean, you will always connect to the same IP (VIP), but the LB will do the job to transfer traffic to real (random) IoT IP. LB will be "man-in-the-middle" configured with static IP (VIP).

[stich86]

I’ve used a similar solution on another firewall using L3 routing of this subnet to an LB, but in this scenario cannot be done because there is no availability of a dedicated LB 😞

[Vladimir]

@stich86 , did you get anywhere with TAC on this issue? If it is a legitimate hide NAT many to one problem for "phantom networks", I hope it is solved before R81.10 goes GA.

Incidentally, what is the setting for the "allow NAT inside VPN community" for this connection?

[stich86]

Hi Vladimir,

i had a Zoom call yesterday to explain the issue to the TAC. On first attempt they said to me that the many to one is supported only from internal to external (Hide NAT), but i've complained about that cannot be the first customer to have this feature working.

Then we have done some troubleshooting and found a funny behaviour. With the NAT configured as @the_rock suggestion, the NAT rules is engaged but the XLATE DST (where i'm using an address range with start/end a single IP, in my case 192.168.10.1) is translated with the IP into the address range object plus the last octet of the Original DST IP.

Let me explain better:

SRC IP: 172.16.32.10 ---> DST IP: 10.0.0.1 ---> XLATE DST IP: 192.168.10.2

SRC IP: 172.16.32.10 ---> DST IP: 10.0.0.15 ---> XLATE DST IP: 192.168.10.16

And so on.. so it looks like a bug.

I hope they indentify it as an issue and give me a solution

[Vladimir]

Thank you for the update!

Please update the thread with (hopefully) eventual resolution.