Check Point NG[s]AI

1.  

Should I configure NAT rules manually, or use FW-1 to generate them automatically?

2.  

How do I know when to use hide-mode and when to use static-mode NAT?

3.  

When will the firewall use an ARP entry as opposed to a route?

4.  

I have a lot of NAT rules, and it takes a long time to compile my security policy. What can I do to speed things up?

5.  

My management console is managing several firewalls, and we have an assortment of 10.x.x.x networks on our internal network networks spread out across different locations. How can I keep my NAT rule base simple?

6.  

I can t access my remote network over our Virtual Private Network because the firewall is hiding our local network. What should I do?

7.  

How can I troubleshoot my NAT configuration?

8.  

Why can t I get to any servers on my DMZ that are configured with static NAT after rebooting the firewall?

1.  

No matter how you configure NAT, the end result should be the same. In fact, if you configure NAT automatically, you should still check the NAT rule base to ensure that the rules ended up as you expected. So, the answer to this question really depends on your familiarity and comfort level with NAT and with FW-1 in general.

2.  

As a general rule, use static-mode NAT only when the internal device must be accessible from the Internet. This includes devices such as Web servers, FTP servers, or any other server you want external users to have access to. Also, some forms of VPN and some other specialized applications require static-mode NAT. Hide-mode translation should be used when the internal device needs access outbound, but does not need to be reached externally.

3.  

ARP entries are used for devices that are on the same network as the firewall, while routes are used otherwise . For devices on the same network, when the firewall tries to reach an IP address, it first checks to see if it already has an ARP entry for that host. If not, it sends out an ARP broadcast, received by all devices on the same network, requesting the MAC address for the given IP. For devices not on the same network, the firewall simply checks its routing table for a route to that host, and uses the default route if none is found.

4.  

If you have several sequential networks or subnets defined for your hiding NAT networks, you can combine these into one network object with a subnet that will cover all (or as many as possible) of your networks. For example, if you have 10.1.1.0, 10.1.2.0, 10.1.3.0 10.1.128.0, and you have automatic NAT turned on for each of these networks, you could have 256 NAT rules. Instead, you can create one object with address 10.1.0.0 and subnet mask 255.255.128.0 and add the automatic NAT to this one object.

5.  

Create one network object for 10.0.0.0 with netmask 255.0.0.0, and add hide NAT with a translation address of 0.0.0.0 or select Hide behind Gateway . Using this address will hide the traffic behind the firewall s IP address that the traffic is leaving.

6.  

Sometimes it is necessary to create manual address translation rules that do not translate. If you should not be translating your internal network to your remote office, then you could add a rule where the Original Packet fields match these VPN packets, and the Translated Packet section keeps all three columns (Source, Destination, and Service) as Original. This rule would have to be added above any rules in the rulebase that translated this source or destination. Note: you can only use one object in each cell in the NAT rulebase. As a result, it may be necessary to create a group of objects between which you will not be NATing.

7.  

Perform these steps to verify that you have things configured properly for static address translation. You may need to add a security policy rule for this to report correctly. If you cannot determine a problem with ping, check your Log Viewer for dropped or rejected packets as well as look at the following columns in the Log Viewer: NAT rule number, NAT additional rule number, XlateSrc (Xlate is short for Translate) for the translated source IP address, XlateDst for the translated destination IP address, XlateSPort for the translated source port, and XlateDPort for the translated destination port. Don t worry if they are blank, they are only recorded if the particular part of the packet is being changed.

1. From the firewall, ping the internal IP address of the host/server. If you cannot, then check the cabling.

2. From the firewall, ping the routable, external IP address of the host/server. If you cannot, then check the host route on the firewall. If the host route looks right, then check the network object for your workstation; the IP address or Address Translation may be incorrect.

3. From the host, ping the internal IP address of the firewall. If you cannot, then check the cabling.

4. From the host, ping the firewall s external IP address. If you cannot, then check the default route on the host, and the default route of any intervening routers.

5. From the host, ping your Internet router (or the firewall s default gateway). If you cannot, then check the address translation on the workstation s network object in SmartDashboard. If that looks fine, then check the ARP on the firewall (local.arp in NT).

8.  

If you are using a Windows firewall, check that the static host route was added with a “p switch, which stands for persistent or permanent. This ensures that the routes are added into the registry and restored whenever the system is rebooted. If you are using a Solaris firewall, ensure that your ARP and route statements are added in a startup file. If you have a Nokia firewall, make sure that you make any route and ARP change through the Voyager GUI, and that you SAVE your changes after you apply them.