How It Really Works
In the scenario diagrammed in Figure 1.8, a client wants to connect to the www.newyork.com server. Provided the DNS is configured properly, a packet is created with a source IP (SIP) of 4.3.2.1 (Client IP) going to a destination IP (DiP) of 38.1.1.3.
Figure 1.8 Server-Side Static NAT
Through the magic of the Internet, the packet is routed along to the external router as follows:
1. The router has a packet with a DIP of 38.1.1.3, a network to which it is directly connected. If there is no specific route in place, the router will ARP asking for the MAC address of this IP.The firewall must be configured to reply to this ARP request with the MAC address of the external interface. The packet is then forwarded to the firewall.
2. The firewall now has a packet to match against the Rule Base, provided a rule is configured to accept the communication. (Yes, this implies that 4.3.2.1 is a valid SIP on the external interface.)
3. The packet is then passed up the stack to the network layer to determine routing. Internally the firewall will have a route for the 38.1.1.0 network back through the external interface. Because the DIP has not yet been modified, a host route is needed on the firewall. In this case, we want to route 38.1.1.3 via 10.1.1.3 so the packet is then directed out the internal interface.
4. At the internal (server side) interface, the DIP is now changed to 10.1.1.3 and the packet is forwarded to www.newyork.com.
5. Being a friendly Web server, a reply packet is then sent with SIP-10.1.1.3 to DIP-4.3.2.1. In this configuration, the default gateway is the firewall.The packet is modified before inspection by changing the SIP from 10.1.1.3 to 38.1.1.3. Now think back to Check Point 101 class. Before matching a packet to the state table or Rule Base, the SIP is checked against antispoofing settings. Without NAT, this interface should be configured as this net, meaning that an inbound packet to the firewall on this interface must have a SIP of 10.1.1.x.The packet has already had the SIP changed to the 38.1.1.3 address; unless we create a group containing the 10.1.1.0 network and 38.1.1.3, the antispoofing configuration will drop the packet.
Client-Side NAT
Client-side NAT occurs when the destination address is translated on the client-side interface of the firewall, the inbound interface. This removes the need for the static route required when you use the server side, the host route on the firewall, and the modification of the antispoofing feature.This option is new in NG and prior to FP3 was only available when you used automatic rules. FP3 adds the ability to do client-side translation for Manual NAT rules as well.The previous NG releases only use server-side NAT when manual rules are used. Enabling client-side translation is done in the
Global Properties | Network Address Translation screen by selecting Translate destination on client side, as shown in Figure 1.9.
Figure 1.9 The Global Properties Network Address Translation Settings
How It Really Works
The packet flow is not different, only the interface where the actual translation occurs (see Figure 1.10).The DIP on an incoming packet and the SIP of the reply packet are both modified at the external or client-side interface. A reminder for readers who are using a pre-FP3 version of NG:This function is only available for automatic NAT:
1. The router has a packet with a DIP of 38.1.1.3, a network to which it is directly connected. If there is no specific route in place, the router will ARP asking for the MAC address of this IP.The firewall must be configured to reply to this ARP request with the MAC address of the external interface. The packet is then forwarded to the firewall.
2. The firewall now has a packet to match against the Rule Base, provided a rule is configured to accept the communication. Now on the client-side interface, the DIP is changed from 38.1.1.3 to the illegal internal address of 10.1.1.3.
3. The packet is then passed up the stack to the network layer to determine routing. Because the DIP has already been modified, the packet is then forwarded out the internal interface; no host route is necessary.
4. A reply packet is then sent with SIP-10.1.1.3 to DIP-4.3.2.1. In this configuration, the default gateway is the firewall. The internal interface receives the packet; a valid response to a connection request, and routes it to the default route. Before the packet is sent out the external interface to the destination, the SIP is changed back to 38.1.1.3.
Figure 1.10 Client-Side Static NAT
Bidirectional NAT
The one option in Figure 1.9 to enable bidirectional NAT is another new option.This option allows two NAT rules to apply to a connection. It is useful when you need to translate both the source and destinations. One scenario for using this option is when a remote location is using identical address space. For example, both the corporate office and remote office have used the 10.1.1.0/24 IP address space and communicate through an internal WAN connection. Both networks need static translation to different address ranges in order to talk with each other. This is only one particular scenario that might be applicable for your environment, and you should know the available options.
