Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Bernardes
Advisor
Jump to solution

Manual NAT rule many-to-few mode doesn't work

Hello Mates!

I have an IP range from ISP, 3 of those IPs are used in the members cluster external interfaces and VIP cluster.

Currently, all of my private networks connect to the internet through a single IP (VIP cluster) and I would like to use more IPs from this range so that my private network uses more than just 1 IP dynamically.

So I configured a manual NAT rule following sk142833 :

nat_rule.png

I configured the proxy arp for these IPs that doesn't are directly on the gateways interfaces like asked on sk above:

proxy.png

The fw monitor shows the NAT working apparently, but when the manual rule is enable, the user internet connection doesn't work. When I disable the manual rule and criate NAT hide from the network object so the internet connection works fine.

fwmonitor.jpeg

Any advices?

 

Thank you!

0 Kudos
1 Solution

Accepted Solutions
Bernardes
Advisor

@the_rock I check the box "merge manual proxy arp configuration" and now it works! I'm testing this host and now it connect to the internet with .94 IP normally... The rule seems to be working fine now!

Thank you so much for your advice! I'm keeping in test..

View solution in original post

0 Kudos
19 Replies
AaronCP
Advisor

Not sure if it's relevant, but your FW Monitor screenshot shows a different source port post-NAT.

 

If you run a tcpdump on your external interface, do you see the return traffic coming back to the gateway?

0 Kudos
Bernardes
Advisor

Hello @AaronCP  when I run tcpdump or fw monitor, I can't see the packet returns. The last information is the packet going out from gateway and don´t show nothing coming back.

0 Kudos
AaronCP
Advisor

If the gateway is NATing and routing the outbound traffic correctly, I would guess the upstream router isn't routing traffic for the .94 to your gateway.

 

If you run tcpdump -nnei eth0 host x.x.x.94 and arp on the gateway, do you see any arp requests for the .94 address?

Bernardes
Advisor

@AaronCP I don't think it's a upstream issue, the arp request is happenig like can you see below:

image_2022-11-25_092332032.png

And when the NAT is automatic the connection works, so I am pretty sure that this problem is something wrong on Check Point Gateways.

0 Kudos
AaronCP
Advisor

The upstream router is arp-ing the .94, but the gateway isn't responding to the arp request, so looks to be a proxy arp issue. Have you looked at SK30197

 

You may have to enable Merge manual proxy ARP configuration in Global Properties | NAT.

0 Kudos
AaronCP
Advisor

I see @the_rock beat me to this suggestion! 🙂

the_rock
Legend
Legend

Its all good brother, you STILL owe me money from VPN route help I provided last time, but okay, I will wait patiently HAHA

Just kidding, always a pleasure to see you on here!

the_rock
Legend
Legend

@AaronCP makes super logical point actually...run tcpdump command he gave or just fw monitor and filter for .94 address...fw monitor -e "accept host(x.x.x.94);"

Andy

0 Kudos
Sorin_Gogean
Advisor

Hello,

 

I think your approach is WRONG, and let me tell you why 🙂..... 

Indeed you have 3 Public IPs on the CKP Cluster - one as VIP and other two on the GWs. 

On your set-up, there are several things wrong, as you can't use the stand-by public IP to NAT traffic that would go towards Internet through the primary GW.... or if that traffic will exit, then how you expect to return properly, as the standby appliance will respond to that IP....

 

So for the NAT, the way you want it, you should wither create a separate NAT pool like xxx.xxx.3.95 - 96 and use that .

Also until you figure out how things should be, do a standard NAT so the clients can get outside and have needed/required access, and play with NAT Pool for a couple of clients that you can play with...

 

@All others, am I wrong on my logic ? 

 

Thank you, 

PS: may I ask how many clients you have in the back that you would consider you require an extra NAT IP, there are some NAT alerts in CKP logs that would point out that you're reaching the limit. 

0 Kudos
Bernardes
Advisor

Hello @Sorin_Gogean ,

I have a /27 (30 IPs). I am not using the same IPs that are configured on interfaces to create this NAT. On interfaces I have .66, .67, and .68 to the VIP (currently, this is the IP used to out for the internet) and now I'm trying to use this little IP range for share these connections to the internet, like I showed on NAT rule above (.92, .93 and .94) .

What you saying is not applicable for my environment, but thank you for cooperate!

0 Kudos
the_rock
Legend
Legend

Hey @Bernardes ...just to make sure Im not mistaken when I say this, are you saying that IF you use .94 in manual nat rule as you indicated that fails, but say if you use SAME ip address to hide nat for specific subnet, then users dont have an issue accessing the Internet?

0 Kudos
Bernardes
Advisor

@the_rock exactly! If I set the .94(or any other IP from my range) in the network or host object, this NAT will be automaticly created and will works normally, but setting the manual rule, the user have no connection.

0 Kudos
the_rock
Legend
Legend

Gotcha! Ok, lets start with basics...can you send a screenshot of whats enabled under NAT in global properties? Also, when that rule is in place, what happens if you do zdebug when someone tries to connect? Does it give any drops at all?

Andy

Bernardes
Advisor

The NAT global settings:

natglobal.png

zdebug don't show any drop for this host

image_2022-11-25_100031207.png

0 Kudos
the_rock
Legend
Legend

Can you check all options in global properties for nat except ip pool nat and push policy and test again? For zdebug, also add the service as well, so command you did, and then (space) | grep 443

Bernardes
Advisor

@the_rock I check the box "merge manual proxy arp configuration" and now it works! I'm testing this host and now it connect to the internet with .94 IP normally... The rule seems to be working fine now!

Thank you so much for your advice! I'm keeping in test..

0 Kudos
the_rock
Legend
Legend

You are welcome mate! Here comes my corny joke of the day, week, month, year that everyone is sick of hearing...for you, NO CHARGE, unless you use Iphone, and if you dont, then you get free coffe and a donut ; - )

But, in all seriousness, glad it worked...I apply this mentality to anything really. Sometimes, when you keep trying things and you hit a dead end, its always best thing to step back and start from basics, usually, that works 90% of the time in my experience.

Cheers and happy its solved and happy watching some great football games (or as our American friends would say soccer : - )

Have a good one!

0 Kudos
Sorin_Gogean
Advisor

Hey @Bernardes ,

 

Indeed, now I see that the screenshot it was for the ARP (making those IP to respond to external ICMP ) .

Have you tried without having them in ARP list, still it should not be any different.

 

Thank you,

 

PS: we have manual NATing done, with several IP's, some on the same network like the Checkpoint WAN side, and others from the Private DMZ and we didn't faced any issues.

Could it be that for IP Pool NAT you require that last checkbox ? (SK39327 )

the_rock
Legend
Legend

@Bernardes Toadd to what @Sorin_Gogean said...I would delete those proxy arp entries, you dont need them there. Thats only for DESTINATION nat , you dont need it for source nat at all.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events