Getting Started: Network Address Translation (NAT)

• After you've set up your firewall following the previous installments of the Getting Started series, you may want to start setting up servers.
• The details below instruct on how to configure Network Address Translation (NAT) or Port Address Translation (PAT) to make hosts reachable from the outside, or to use a specific IP going out to the internet.
• Lets discuss a few scenarios that may come in handy when determining how to configure NAT or PAT to best serve your needs.

Many-to-One, Hide NAT, Source NAT:

1. To cover the basics, hide NAT is the most common use of address translation out there.
2. It hides all internal subnets behind a single external public IP and will look similar to this:

3. This NAT policy will translate all sessions originating from the trust zone, going out to the untrust zone, and will change the source address to the IP assigned to the external physical interface. It will also randomize the source port.
4. Returning packets will automatically be reverse-translated as the firewall maintains a state table tracking all active sessions and their NAT actions

Many-to-Many NAT

1. A variation on the simple hide NAT policy, is to add more source addresses if more are available.
2. If, for example, your ISP provided a public subnet of /29 or larger, you have additional IP addresses that can be used for all sorts of things.
3. If your internal network is quite large, these additional addresses may be needed to prevent oversubscription of the NAT pool.
4. For this configuration the Address Type is changed from 'Interface' to 'translated Address.' Then the available IP addresses are added either as an IP range, or an IP subnet:

5. The firewall will select an IP from the available pool based on a hash of the source IP address.
6. This source address will remain the same for all sessions from that source IP. The source port will still be randomized.
7. If the source ports need to remain the same (some applications may require a specific source port) the Translation Type can be set to Dynamic IP, which will preserve the client's source port per session. The translated address is assigned by 'next available' which means there are some caveats:
   • No more than 32.000 consecutive IP addresses are supported
   • The translated addresses pool needs to be of the same size or greater than your internal number of hosts, as each internal host is assigned its own translated address
8. If the above criteria are usually met but could sometimes be broken, a backup can be set to fail back to Dynamic IP and Port. Both the Translated Address and the Interface Address options are available, the default is none:

One-to-One NAT, Static NAT

• If you need to make a server available from the internet, like a local SMTP or webserver, a one-to-one NAT policy needs to be created that will forward incoming connections to a specific server. There are a few different ways to accomplish this:

Bi-directional policy:

1. In a bi-directional policy, a regular outbound static NAT policy is created just like the above-mentioned NAT policies, and the bi-directional flag is set.
2. This allows the sytem to create an (invisible) implied inbound policy.

3. The policy will source from trust and will be destined for untrust, with a source address set to the server's internal IP and Source Translation being its public NAT address.
4. An implied policy will be created with a source zone of untrust and destination of Any, destination IP of the public NAT address, and destination translation to the server's IP address.
5. This is an easy way to create several one-to-one translations and works perfectly if several servers have their own unique public IP address, which brings us to:

Uni-directional policy:

1. Uni-directional NAT allows for a little more control over the policy than bi-directional, and it allows for PAT or Port Address Translation.
2. PAT enables you to share a single public IP address over different internal services.
3. In the next 3 rules you can see 3 different examples of inbound static NAT:

• Rule #1 is a traditional one-on-one rule that translates all inbound ports to the internal server, maintaining the destination port
• Rule #2 translates only inbound connections on destination port 80 to the internal server on port 8080
• Rule #3 translates inbound sessions for the same public IP address as rule #2, but for destination port 25 to a different internal server while maintaining the destination port 25

Caveats:

• Why are the destination zones set to untrust and what's with the destination interfaces?
• Can 'any' be used as the destination address for an inbound (untrust to untrust) NAT

4. The security policy should be set so the source zone is untrust, destination zone (final destination zone) is trust, and the destination addresses are the public addresses, pre-NAT.

Source and Destination NAT

1.  In some scenarios it may be required to perform source and destination NAT at the same time. One common example is a U-Turn situation, where internal hosts need to connect to an internal server, that is on the same network as the client, on it's public IP address.
2. There's already a great article and a tutorial video that cover U-Turn in more detail, but the short description is this:

• To be able to reach internal resources on a public IP, a new NAT policy needs to be created to accommodate trust to untrust translation.
• If source translation is not included in this policy, the server will receive packets with the original source address, causing the server to send reply packets directly to the client.
• This creates an asymmetric loop: client-firewall-server-client and the firewall session will be terminated as it violates TCP sanity checks.
• The solution is to add source translation to, for example, the firewall IP, so the server's reply packets are sent to the firewall, allowing for 'stateful' sessions.

NAT on a VWire

1. NAT can also be implemented on a VWire if the you are able to edit the routing table on your router (an ISP router may not allow this).
2. Ideally, you would have a router on either end of the VWire to keep things simple, but if you're up for a challenge, you can also get this to work with only an upstream router:
3. Between the two routers you should create a small point-to-point subnet, eg, 10.0.0.0/30.
4. Assign each router an IP and add routes for the translated IP addresses pointed at the remote router's IP on the router located on the translated side. eg. add a route for 198.51.100.1 on the untrust router, pointed at the trusted router's IP. The firewall will take care of the rest.

Caveats:

• Zone resolution is achieved through route lookups. when a packet is received on the firewall, a routing lookup is performed to check where the source subnet and destination subnet are routed to, and the appropriate zone is assigned to the session.
• In the case of inbound traffic from the internet, the source zone will be untrust, as the default route 0.0.0.0/0 is pointed to the untrust interface, and the destination IP address pre-NAT, is also untrust as it is the IP attached to the untrusted interface (198.51.100.0/24 in the above examples)
• The use of destination interfaces in NAT policies can help prevent conflicts when using similar NAT policies. eg. If two external interfaces exist, to two different ISPs, maintaining different public IP addresses, two identical outbound NAT rules can be configured.

• In case a NAT IP is used that is not physically configured on an interface (eg. interface 198.51.100.1 , NAT for server 198.51.100.5), the firewall will send out gratuitous ARP packets to inform neighbours it hosts an IP address and will reply to ARP requests from upstream devices. Gratuitous ARP can also be triggered manually:

  admin@MyFW> test arp gratuitous interface ethernet1/1 ip 198.51.100.6
  1 ARPs were sent

  Caution: if a NAT rule is configured to apply translation to a subnet that is not configured on an interface, the firewall will send out gratuitous ARP for ALL IP addresses in the subnet.
  

• Since the firewall provides proxy ARP resolution for addresses listed in the Destination Address for destination (inbound) NAT, the Destination Address subnet must match the Destination Translation subnet. It is not allowed to use 'any' as the destination address. 
• When creating NAT policies for internal clients to reach servers in the dmz or trusted network via their public IPs, make sure to place these above the Hide-NAT policy regardless .