| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| A NAT technique I have used successfully is suddenly failing and I cannot find the loose thread. DMZ servers use RFC 1918 space. DMZ servers are static NAT'd to addresses in a public subnet for this purpose. The NAT rule translates traffic from a vendor's four /25 addresses between the server's public and private IPs. Policy restricts ports. This has worked many times until now. Logs show the vendor hitting the public address and being dropped on the cleanup rule. XlateScr and XlateDst are null. This is why I think NAT is failing for some reason. I cannot see why this is failing and appreciate any assistance. |
| |||
| hi mate before the cleanup rules do u have the rules to permit the traffic from the internet to ur dmz servers.do enable logging on those rules and check are u getting any hitcounts. let us know would like to help u out. regards sebastan |
| |||
| Yes, a rule is in place to allow traffic from the vendors subnets on defined ports to the RFC 1918 addresses for the servers. The NAT rule is also defined; traffic sourced from Vendors subnets to the routable NAT address object is translated to the internal address object (static). I create an object for each hosts NAT address. I know there are other ways to do this, but I inherited this system and am continuing it while I plan an upgrade. The logs show vendor hosts trying to reach the NAT addresses on allowed ports but being dropped on the cleanup rule. Logs entries are null for NAT'g. I appreciate the help. |
| |||
| mate since u have statically translated the internal dmz server to the routable ip address. try in ur policy to permit traffic to the routable address of the servers than the internal server address. let me know if that works. regards sebastan |
| |||
| Bingo! That worked. I looked through the rule base for traffic between the same internal and NAT subnets and see rules (and traffic) with and without the NAT object included in the policy. Is this a bug or something I've missed? Thank you very much for your help. I've got the systems boys off my back! |
| |||
| hey great that thing worked. even with static nat we can still have rules to reach the internal ip directly. but generally we do static nat for hiding our internal server;s ip address on the internet. previously why it did;t work i guess cause u are using private addresses on the internal dmz servers.i guess on the outside router u are not having a route for internal addresses space pointing to the external interface of the gateway. regards sebastan |
| |||
| This is why I use automatic static NAT 99% of the time. You get both IPs assigned to a single object, making it cleaner and easier to manage/configure. This also works for networks/subnets, just use the first IP (usually .0) and it will statically NAT all the range. |
| |||
| This suggestion is what I am going to move forward on. It seems to have the benefit of simplicity. I am not sure why the previous admin defined 2 nodes for each server to implement NAT'g. Thanks for the push. |
![]() |
| Thread Tools | |
| Display Modes | |
| |