I'm configuring the NAT on CheckPoint 2200. But, it doesn't work. Please advise how can I do? Thanks.
What exactly did you configure in an effort to make this work?
How did you test this to see that it worked (or didn't)?
What entries did you see in the logs when you tested this, if any?
See: How to Troubleshoot NAT-related Issues
I created the new host 192.168.1.20 and set static nat 18.104.22.168. After that, I ping to IP 22.214.171.124, but it's not forward to 192.168.1.20. I didn't see the log to 192.168.1.20. Is there any advise, I'll do it and update the result.
add a proxy arp.
Can you advise how to add a proxy arp on CheckPoint FW?
wonder about one thing, you may know that by heart but I just don't remember:
- once you've got "object-nat" based on single host, you obviously don't do the manual NATs and make them higher in sequencing, do you need a proxy-arp or not at all?
I was having one case with my old customer with R77.30 VSXs on 12xxx appliances in HA (ClusterXL not LSM) where they insisted that proxy-arp made on clish need to be in place, otherwise public IPs won't communicate with upstream router.
you agree or not - simple query though
I believe that the proxy-arp is not required if Static Nat in object's properties is defined, at least in R77.30.
The problem that client of yours was experiencing without it is likely due to improperly configured routing on the upstream router.
I.e. public network may not have been forwarded to the Cluster XL's vIP and the network between Cluster XL and the upstream router or HSRP router pair may have been a subset of their public range, /28 or some such.
Possibly, vMAC was not enabled on cluster object.
excellent point. thanks Vlad. I think it is spot on, the HSRP indeed turned out to be the case.
Vlad, to make it even more complicated I will add a little bit of naughty stuff here:
- vMAC wasnt enabled indeed
- HSRP/VRRP was causing an issues
- Hosts on STATIC object IP were 2 SMS devices (Management HA)
- proxy arp was set but when removed there was no difference traffic flow wise, still Management HA couldn't communicate via VIP IP from ClusterXL hosts (core gw).
- when proxy arp was removed it still didn't work, only when IPS got into the Huawei crap (...) they've found mismatches on their config, fixed dynamic routing and all started to work as it should
now I'm facing similar story on R80.10 infra where Management HA cannot comm with CPUSE due to (potentially) upstream FW glitch as the proxy-arp in or not in place makes no difference. Static object NAT made on SMS boxes itself (by Dash).
still CPUSE cannot be reached by SMS's itself.
good thing is that it will get resovled soon when Compliance Team get on with it and sort their FW ruleset mess out.
Can you elaborate on this please: "Static object NAT made on SMS boxes itself (by Dash)."
Unless I am misreading this, there are still gateways upstream of the SMS HA members and ultimately, those will be deciding what public IPs will be present to the outside world for SMS to CPUSE communication.
If you need the SMS HA members to have static IPs at all (i.e. they are managing gateways in other locations, such as branches, secondary data centers, etc..), then whatever the NAT configuration for these object is imposed on the gateways between SMS and the Internet should be the definitive authority, is it not?
For CPUSE specifically, you should be able to use the proxy settings in the Gaia to circumvent whatever impediments the NAT currently causing.
It's a function of this:
Thanks, I got that as it was quite frustrating so far. Now all clear. EOT
1. You have two public IP ranges on the outside of your firewall (reason?). You have to verify that routing between them and the Internet is working (from the router, ping Internet hosts using source IP of 126.96.36.199).
2. Properly define topology of the 2200 gateway (i.e. eth0 as External Interface, eth1 as Internal with defined network)
3. Verify that hosts on the Internet are reachable from 2200 (i.e. ping www.yahoo.com from expert mode)
4. Configure host object with IP address of 192.168.1.20 and its NAT properties as Static with IP of 188.8.131.52 (this is only necessary if you are trying to reach the 192.168.1.20 from the Internet. If all you are trying to achieve is outbound access, configure NAT properties as "Hide" behind gateway).
5. If you are using Static NAT, verify that the packets from upstream router hitting External interface of 2200 (Enable ICMP in Global Properties, traceroute from the router to the 184.108.40.206, check the CP logs for ICMP packets).
6. Verify that the gateway on 192.168.1.20 is defined as 192.168.1.1
Thanks for your information. I'll check some thing and update the result.
Just looking at the drawing, you need to add proxy arp, unless your using automatic NAT
add arp proxy ipv4-address 220.127.116.11 macaddress xx:xx:xx:xx:xx:xx real-ipv4-address 18.104.22.168
Where macaddress is the address of the interface with 22.214.171.124
In the global properties of the management server check the NAT page for these settings:
After adding a proxy do not forget to push the policy otherwise it will still not work.
To check if the proxy arp is working use: fw ctl arp
Thanks for your advise. Let me check on it.
Here is also related sk30197-Configuring Proxy ARP for Manual NAT where are all steps described well.
As described by the other users:
- add proxy arp
- enable manual proxy arp configuration
Here you can find a flowchart of how nat (source NAT and destination NAT) is implemented:
R80.x Security Gateway Architecture (Logical Packet Flow)
proxy arp from clish (for simplicity)
clish> add arp proxy ipv4-address "public desirable IP" interface ethx real-ipv4-address "interface-physical-ip"
hope it helps
Retrieving data ...