4 Replies Latest reply on Jun 24, 2013 11:51 PM by grinder

    When To Use NAT In Access Rules

    grinder

      Can someone explain to me in laymans terms when to use NAT and when not to use NAT in access rules.  It seems that this always gets me.  By default when adding a new rule it puts localhost in the NAT selection.  Many times my rules do not work and it ends up being because of this NAT entry.  My firewall experience is minimal but I have been learning a lot working with our new McAfee firewalls.  I would like to be able to understand this better so I know when and when not to use it.  Thanks!

        • 1. Re: When To Use NAT In Access Rules
          PhilM

          With the way that different vendors use the term NAT, it can be easily confused.

           

          In the context of this product the NAT value relates to the source address in any traffic passing through that rule. When the value "Localhost" is used as the NAT value this means the Firewall will apply the primary/default IP address of the engress interface. It could be roughtly translated into "what IP address will the destination host will see..." when a connection is made.

           

          Though not exclusively the case, most environments use a private address scope on the internal side and a small range of ISP-assigned IP address on the external side. Imagine the internal network is utilizing the 10.1.1.x / 255.255.255.0 range (with the Firewall's internal address being 10.1.1.1) and on the external side it has been configured with a primary IP address of 1.1.1.1 and an alias of 1.1.1.2.

           

          Any outbound rule (internal-to-external) with the NAT value set to "Localhost" will take that traffic and will substitute the source IP address of the actual client machine (10.1.1.5, for example) with the address 1.1.1.1 - allowing it to pass out to the internet. When the response traffic returns, the appliance is able to identify which session this traffic belongs to and will automatically swap the address back again (1.1.1.1 becomes 10.1.1.5) allowing it to continue its journey back to the originating machine.

           

          If you had a need for a certain connection (lets say an outbount FTP connection to a specific destination) to use a different NAT address, it is simply a matter of creating a network object for the alias address in question (1.1.1.2) and when creating the outbound FTP rule, instead of using "Localhost" in the NAT field, select the network object for the 1.1.1.2 alias.

           

          Inbound rules tend to involve two components. There's the redirect host value that allows the rule to handle the transfer of traffic from a public address to the private IP address of the machine actually hosting the service. In other environments this is sometimes referred to as "destination NAT". But there's still the NAT value to consider also. Remember it translates to "what the destination host will see...".

           

          So, if you have a web server on your internal network (10.1.1.25) and you want to be able to allow inbound access via the external address 1.1.1.2 a basic inbound rule should look something like this:-

           

          Source zone = external

          Source endpoint = Any

          Dest zone = external

          Dest endpoint = network object for IP address 1.1.1.2

          Redirect Host = network object for IP address 10.1.1.25

           

          Generally, there are two ways to go with the NAT value and there are pros and cons to each.

           

          If the NAT value is set to localhost, you are unlikely to have any routing issues. Traffic from the Firewall to the web server will be seend to be coming from 10.1.1.1 and therefore the web server will have no problem sending its response back. But, on the con side, because all connections will be seen from this address any statistics or reports from this server are likely to be meaningless (it sees all the connections coming from the same place). Change the NAT value to "<None>" and the original source IP address from the client trying to connect to the web server will be preserved (2.2.2.2 for the sake of this example). The web site's statistics will now make a lot more sense and this will please the webmaster. However, you will then need to make sure that the default gateway address on the web server is either pointing to 10.1.1.1 or to an address on the 10.1.1.x network that knows all 'external' traffic needs to pass via 10.1.1.1.

           

          I can recall one specific scenario with a customer who had created a rule to allow inbound access to an FTP server. Connections were not working and he was absolutely adamant that the Firewall was at fault. I ran a TCP dump on the external and internal interfaces and when someone tried to establish an FTP connection I could see the traffic pass from external interface to internal. However, there was absolutely no sign of any return traffic from the FTP server. No amount of reasoning could convince this person that either his FTP server wasn't working properly (because he was able to connect from another internal host) and I was convinced that there was something fundamentally amiss with his routing. When I got him to check the rule he confirmed that the NAT value was set to "<None>". I suggested that he change it to use "Localhost" instead. He did so and inbound FTP connections began to work. The fact that chaging the Firewall configuration had fixed the issue further cemented in his mind the cause of the problem was the Firewall (as he had always suspected).

           

          With this prositive progress, the urgency went away and I was able to get him to check a few more things without being met with resistance. I asked him to check the IP configuration on the FTP server and wasn't the least bit surprised to discover that the default gateway address was....empty. Changing the Firewall had 'fixed' his problem, but this was because the NAT had been changed so that as far as this FTP server was concerned, all the requests were coming from the Firewall's internal IP address.

           

          Anyway, I hope that helps.

           

          -Phil.

          • 2. Re: When To Use NAT In Access Rules
            alex_vani

            Great explanation Phil, glad to count with you on this forum.

             

            Just to be curious, I have a couple of question regarding to NAT.

             

            Using localhost as NAT into a security rule when a connections is made from internal to external, the internal host uses the external IP-Address to reach 'lets say any host on the web.

             

            However could you pleas go deeper on this....  if you set localhost into a security rule using redirect, on the scenario when a conection is made from external to internal reaching an internal host, (as you just mentioned on you recall with the customer) Does the firewall is smart enough to know that in this case it will use the internal firewall ip-address? as it does it when uses localhost on the NAT statement from internal to external?

             

            Thanks for the complement.

            • 3. Re: When To Use NAT In Access Rules
              sliedl

              Yes, the firewall will use the internal firewall IP address when you set the redirect address to 'localhost' for an external-to-internal connection.  It will use the cluster address or the first address listed in 'ifconfig' (if you have aliases addresses on that interface) from whichever interface the traffic will leave the firewall from (which can be found with 'route -n get [dest IP]').

              1 of 1 people found this helpful
              • 4. Re: When To Use NAT In Access Rules
                grinder

                Thanks a lot for your detailed explanation.  I think I am pretty clear now. At least until I go to sleep   Thanks for your help as always.