HiddenOne

Static NAT is a function that is commonly used when you want to offer services on the Internet from a server that sits on a protected subnet that uses a private address scheme (RFC1918). In a previous article, I detailed the process of creating static NAT entries on a Fortigate 800 using the web interface. I will cover the same process, this time on a pair of Juniper SRX240H security gateways. The two gateways are configured as a cluster (HA); however this has a minimal effect on some of the commands that will be entered.

Unlike the process on the Fortigate, I will be configuring static NAT on the Juniper devices using the command line. There are several reasons for not using the Juniper web interface (Jweb) for configuring static NAT. First, I could not find a location on the Jweb interface to configure static NAT. Second, in my opinion, the Jweb interface is clumsy and slow. It might be good in certain situations, but for the majority of the work I do on all equipment is done using the command line.

Keep in mind that any static NAT rules that are created for an internal host will apply to both inbound and outbound traffic to and from that host. This means that any static NAT rules will also take precedence over your NAT overload rule. It’s a good idea to keep that in mind when troubleshooting.

Within Junos static NAT is achieved with a rule set that is made up of multiple rules. In this case I will create a rule set named MY-COMPANY-STATIC. Within that rule set there will be rules for the mail server (R-MAIL) and the web server (R-WEB). In reality you can split your rule sets and rules up any way you like.

First, drop into static NAT configuration mode using the command.

{primary:node0}
chris@SRX240H-01> configure
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode

{primary:node0}[edit]
chris@SRX240H-01# edit security nat static

{primary:node0}[edit security nat static]
chris@SRX240H-01#

Next, create the rule set and define the zone in which the outside world (the Internet) exists. In this case the “untrust” zone is the Internet.

{primary:node0}[edit security nat static]
chris@SRX240H-01# set rule-set MY-COMPANY-STATIC from zone untrust

The configuration of the zone can be a source of confusion as some people take this to mean that the rules will only apply in one direction. Always keep in mind that static NAT rules apply to both inbound and outbound traffic.

The next two commands will create a rule for a particular destination. The first line of the rule defines the destination address that the rule should match in inbound traffic. Since the untrust zone is connected to the Internet, the destination address is set to the public IP address of the host (The mail server in this case).

{primary:node0}[edit security nat static]
chris@SRX240H-01# set rule-set MY-COMPANY-STATIC rule R-MAIL match destination-address 1.2.3.4/32

The second line of the rule defines the IP address that the destination should be translated to. In this case this is the private IP address of the server that resides in the trust zone of the SRX.

{primary:node0}[edit security nat static]
chris@SRX240H-01# set rule-set MY-COMPANY-STATIC rule R-MAIL then static-nat prefix 192.168.1.100/32

Both lines of the R-MAIL rule point to a specific host as is indicated by the 32-bit mask (/32).

Now you must configure proxy ARP for the IP addresses you will be translating. In this case we will be configuring proxy ARP for the public IP addresses that reside in the untrust zone.

To configure proxy ARP you have to be in the “edit security nat” section.

{primary:node0}[edit security nat static]
chris@SRX240H-01# up

{primary:node0}[edit security nat]
chris@SRX240H-01#

Now the set proxy-arp command is used. This command is fed the interface through on which you want to configure proxy ARP as well as the IP address for which proxy ARP will be performed.

{primary:node0}[edit security nat]
chris@SRX240H-01# set proxy-arp interface reth0.0 address 1.2.3.4

The interface reth0.0 is used because these configurations are being made on a pair of SRX240H’s that are in cluster mode. On a single SRX you would use an interface name such as ge-0/0/0.0.

At this point the static NAT configuration is complete. Most likely you will have to create firewall policies for inbound and outbound traffic from the host (if you have not already done so).

In my previous article, I covered how to configure NAT overload, or PAT, on a Fortigate firewall. This time around I will cover how to configure static NAT.

Static NAT is used to map one IP address to another. This is typically used to perform translations from public address space to private address space. Many organizations do not put servers directly on the internet. Instead the servers may sit on a private LAN, or even in a DMZ. Static NAT mappings are used in these cases to allow servers that are sitting behind a firewall to extend services to the Internet.

Static NAT Configuration

Fortigate firewalls call the static NAT function “Virtual IP Mapping”. These virtual IP mappings can be used for static or dynamic NAT; however I will only be covering static NAT with a one to one mapping relationship.
A new virtual IP mapping is created on the “Virtual IP” tab under Firewall -> Virtual IP. On the “Virtual IP” tab, click on the “Create New” button. This will bring you to the “Add New Virtual IP Mapping” page as shown below:

Fill in the following information:

• Name – This is a name that will uniquely identify this mapping. It may be easy to use the name of the server that mapping is for just to keep things simple.
• External Interface – This will almost always be set to “external” unless you have a different configuration.
• External IP Address/Range – Here you can enter either the first and last IP addresses in a range, or just a single IP address (Leaving the second text box empty). Remember to use the public IP address here.
• Internal IP Address/Range – Same as the external IP, except this time you will use the private IP address of the server.
• Port Forwarding – Only use this if people will be sending requests from the outside on one port, while your server will be listening on another. For example if people will be requesting web pages on port 80, but your server’s web server runs on port 8080.

Once you have configured the virtual IP mapping it is time to create the corresponding policy. This will be done by going to Firewall -> Policy and then the “Policy” tab. Click on the “Create New” button to create a new policy.

This time we are going to create a policy for traffic entering our network, so the source interface will be “external” and the destination interface will be “internal” (or DMZ depending on your configuration).

The next crucial step is to set the “Destination Address. If you expand the drop down menu, you will see a section titled “Virtual IP”, under which you should see the name of the “Virtual IP Mapping” that was just created. It’s also good practice to only accept traffic for the services that the server will be running. There is no use in accepting incoming HTTP for a server that only runs SMTP services, plus it’s a good security practice.

Finally, in this case you do not need to select “NAT”. The virtual IP mapping will take care of all of the NAT work.

Now you should be armed to configure all of the basic NAT services on a Fortigate.

At work we recently migrated to a different Internet Service Provider. This migration brought many changes, but a big one for me as the network administrator was the fact that we would be handling our own address space and network address translation (NAT). Although Fortigate support was great at confirming the NAT configuration process for me, I found that the documentation of NAT Overload/PAT configuration was lacking. My hope is that someone out there will find this document useful in their work environment.

I will be using the Fortigate web interface for all configuration steps. The unit I am using is a Fortigate 800 running software 4.0.2,build0099. Other versions or Fortigate models may use a different process to configure NAT.

Before starting, ensure that your Fortigate is in NAT mode. This can be accomplished by going to the “Operation” tab under System -> Config. Keep in mind that you will lose many, if not all, of your policies and settings by making this change. Be sure to backup your configuration file first so you have something to fall back on if things go south.

NAT Overload/PAT Configuration

NAT overload, also called Port Address Translation (PAT), is a process used to allow many computers to access the Internet using one or more IP addresses. This is used when you have a large number of computers on your LAN, but your public IP address space does not allow for a one to one mapping of public IP addresses for each computer. Without going into detail, PAT uses one public IP address with a TCP port number appended to the IP address. The port number is what is used to identify which session maps to which computer.

First a public IP address must be assigned to the external interface on your firewall. This can be accomplished by going to System -> Network -> Interface tab. On the Interface tab, click the edit icon for the external interface. You will see the screen below:

Under “Addressing mode”, click “Manual” and enter the IP address and subnet mask. The IP address and subnet mask should be separated by a forward slash like this: “176.16.1.2/255.255.255.0”. Click “Ok” to save your changes.

Next, we need to make sure the firewall knows how to get where it needs to go. This is done through routes under the Router -> Static -> Static Routes tab. Here, you’re probably going to need at least two routes. The first route you will need is a default route, which is represented using “0.0.0.0/0.0.0.0”. Here the gateway address should be set to the next hop of your Internet bound routing equipment.
Now your firewall needs to know how to get back to your LAN subnets. It’s up to you how you configure this, but for simplicity sake we will use a blanket route. Say all of the IP addresses on your LAN subnets start with “10.70.xxx.xxx”, you can simply create a route for all of the subnets that start with “10.70” using the following IP address and subnet mask combination: “10.70.0.0/255.255.0.0”. You may choose to be more specific with your routes.

Below is an example route configuration. This is used on a production Fortigate, so I have blocked out some information to protect the innocent.

Now that the routing has been setup we can create a policy to allow outbound traffic and enable NAT. This is accomplished by going to the “Policy” tab under Firewall -> Policy. Once there, click the “Create New” tab. Here you will be presented with a list of options, but we will focus on a select few.

The “Source Interface” and “Destination Interface” options are self explanatory. We are going to set the source to “Internal” and the destination to “External” since we want to configure internal to external translation (the translation table will automatically handle the reverse mapping). The next crucial step is to ensure that the “NAT” checkbox is selected to enable NAT for this policy. You can create an “allow all” policy for now just to test if NAT is working. Various “what’s my IP” web sites should be able to confirm that the public IP address of the external interface on the firewall is being used for NAT.

One note about the NAT checkbox; it needs to be checked for any internal to external policy that you wish to allow traffic. At work I have a policy that blocks outbound RDP access; however there is one vendor’s server to which we need to permit outbound RDP access. If you create the outbound policy and place it in the appropriate spot on the policy list, but forget to check the NAT option the policy will not work. If things don’t seem to be working as they should, or is seems that the policy is being ignored, always check the Nat checkbox!

That covers NAT overload/PAT configuration on the Fortigate 800. In a follow-up article I will cover static NAT configuration, which is a less involved process.