| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Greetings group, When using automatic static NAT, how should rules be configured to prevent external users from connecting to the host's native IP address? If the rule reads: Source Destination Service Action Net_192.168.1.0 Host_object Any Allow And the Host_Object has an automatic static NAT applied, external users can access the host's NAT address *or* the native IP. What's the recommended way of configuring rules so this doesn't happen? Do I have to add a rule for each host with an automatic static NAT? Source Destination Service Action Net_192.168.1.0 Host_object_native_address Any Deny Net_192.168.1.0 Host_object Any Allow Yuck. How do you deal with it? Dan Lynch, CISSP Information Technology Analyst County of Placer Auburn, CA Last edited by ulynch; 2007-12-10 at 10:39. |
| |||
| You don't have to do anything to stop external people connecting to a static nat ip address. You have to manually create a security rule in the first place to allow people to connect through the firewall, so merely creating the NAT does nothing to allow people to connect from the Internet to your host that is statically natted. Am I missing something from your question? |
| |||
| When the rule allows a source to connect to an object that has automatic static NAT applied, the source can connect to *both* the native and NAT addresses. As in my earlier example: Source Destination Service Action Net_192.168.1.0 Host_object Any Allow Where object "Host_Object" has both a native IP address property and an automatic static NAT applied to it. This rule allows the source ("Net_192.168.1.0") to establish a connection to either the native or NAT address of "Host_Object". The rule matches for both addresses. A second rule is required then to prevent the source from connecting to the native IP address. That second rule must use a new destination object with the IP address property set to the native IP address of the host, and no NAT applied. As before: Source Destination Service Action Net_192.168.1.0 Host_object_native_address Any Deny Net_192.168.1.0 Host_object Any Allow Again, yuck. It gets worse when we must allow access to the native IP from internal nets. Like so: Source Destination Service Action Net_10.1.1.0 Host_object_native_address Any Allow Any Host_object_native_address Any Deny Net_192.168.1.0 Host_object Any Allow Thoughts anyone? Dan Lynch, CISSP Information Technology Analyst County of Placer Auburn, CA (I'm sorry the formatting here is so ugly. The board seems to strip off tabs and consecutive spaces, making it difficult to create a columnar or table format. I'm open to ideas here.) |
| |||
| When you create automatic Static NAT in an object, Firewall-1 will assign both IPs to the same object. You have several ways around that: 1 - Create a new object called "Host_object_NAT" and use that one in the policy, rather than the object that has NAT. 2 - Use manual NAT, which will force you to also do 1 anyway :) In reality, they shouldn't be able to connect even as you state. This is what should happen: Client -> Server private IP (this goes past the firewall with no changes) Server private IP -> Client (this will be NATTed by the firewall) Server NAT IP -> Client Client sends a packet to one IP and gets the reply from another IP and this packet will be dropped. |
| |||
| Why are you concerned which IP address is being used if you allow the traffic anyway? Normally NAT is used to assign a routeable address to a host that has an RFC1918 address assigned to it, so it isn't an issue as only "internal" users can connect to the RFC1918 address. I'm sure you have a good reason and knowing that may help us give you a less ugly solution. |
![]() |
| Thread Tools | |
| Display Modes | |
| |