After you've set up your firewall following the previous installments of the Getting Started series, you may want to start setting up servers. Unless you have the luxury of owning a public IP subnet large enough to host all your internal hosts, the details below instruct you 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.
In this installment, I will discuss a few scenarios that may come in handy when determining how to configure NAT or PAT to best serve your needs, and throw in a couple of caveats to be mindful of.
To cover the basics, hide NAT is the most common use of addres translation out there. It hides all internal subnets behind a single external public IP and will look similar to this:
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.
Returning packets will automatically be reverse-translated as the firewall maintains a state table tracking all active sessions and their NAT actions
A variation on the simple hide NAT policy, is to add more source addresses if more are available. 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. If your internal network is quite large, these additional addresses may be needed to prevent oversubscription of the NAT pool.
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:
The firewall will select an IP from the available pool based on a hash of the source IP address. This source address will remain the same for all sessions from that source IP. The source port will still be randomized.
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:
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:
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:
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, which allows the sytem to create an (invisible) implied inbound policy.
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. 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.
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 NAT allows for a little more control over the policy than bi-directional, and it allows for PAT or Port Address Translation. PAT enables you to share a single public IP address over different internal services.
In the next 3 rules you can see 3 different examples of inbound static NAT:
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.
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.
To be able to reach internal resources on a public IP, a new NAT policy needs to be created to accomodate 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 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). 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:
Between the two routers you should create a small point-to-point subnet, eg, 10.0.0.0/30. 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.
admin@MyFW> test arp gratuitous interface ethernet1/1 ip 198.51.100.6Caution: 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.
1 ARPs were sent
Oversubscription occurs when the firewall has multiple (two or more) concurrent sessions sharing the same translated IP address and port pair and provides scalability when there are too few public IP addresses for the amount of sessions being created. Eg. normally the maximum amount of concurrent sessions would be 64K (65.000 source ports minus 1024 'server' ports). oversubscription, depending on the platform, allows for up to 512K concurrent sessions per IP with an oversubscription of 8x.
Some related articles:
Thanks for reading!