Tutorial: Network Address Translation

hi this is Tom with the community team and in this episode of the getting started video tutorial series we're going to take a look at Network Address Translation unless you have the luxury of owning a very large IP subnet in the public IP space network address translation is going to be a requirement for your internal hosts to be able to connect out to the internet and for local servers to be reachable from the outside one of the very first things you're going to need is a hide NAT rule also known as a many-to-one or source-NAT for your outbound connections so let's create one the original packet tab should correspond to what a packet looks like before any NAT is applied So the source is going to be your trust interface because the routing of your source IP address points to your trust interface. The destination zone is going to be the untrust interface because the IP addresses is public so your default gateway is going to point out the destination interface is going to corresponds to your public interface and finally in the translators packet we're going to set the translation type to dynamic IP and port and for the address type we're going to start with the interface address interface is going to be the external one because the public IP address is attached to that interface and we're going to select the IP address. If your external interface happens to be a dynamic one like if you have a cable modem or DSL there's not going to be an IP address because that's assigned dynamically and then just leave this is none if you have a static IP address you can select it here. This NAT policy will translate all sessions originating from your trust zone going out to the untrust zone and it will change the source address to the IP address assigned to the external interface and it will randomize the source port used by your clients a couple of variations are available depending on your requirements for example if we change the address type from interface IP to translated address this will give us manual control over which IP this is used for this NAT rule This can come in handy if you want to use a different IP address than the interface IP address for your local subnet or if your isp assigned you a larger subnet to use and you want to prevent oversubscription which is a condition where more source ports per translated address are required then there are available so you can either input a port range or a subnet for example the IP range or subnet The firewall is going to select the IPaddress from this pool based on a hash from the source IP address which means that a any given host will always exit firewall using the same source IP address from the pool that's configured here another variation is dynamic IP let me go ahead and clone this policy so i can show you the difference so in the translated packets were going to change the translation type from dynamic IP and port to dynamic IP the big change here is that the firewall is no longer going to randomize the source port used by the client which also means that the IP pool used in translation needs to be of equal size or greater than the number of internal hosts going through this this policy because each client IP address will be assigned a unique translated IP address this can be very useful if you have a large public IPsubnet that you can use for you translation for example a /24 multiple smaller subnets can be combined to form a larger pool so if your isp is able to provide you with several smaller IP subnets you can combine these to have a larger pool if for example at one point your available IP addresses become depleted we can configure a fallback mechanism that falls back to dynamic IP address and port so you're still going you're going to randomize your port and share source ports with any remaining clients that cannot get an IP address from this pool and then you can assign just like before an IP pool to use or an interface IP address as a fallback mechanism previous example will allow a local subnet to connect out to the internet if you want to make a server available from the internet you'll need a static NAT policy you can either create a uni-directional one or a bidirectional one we'll start off with the simpler one which is bi-directional one which you can use if you have multiple IP addresses on your public interface if you only have one the unidirectional one will probably be a better choice let's start by creating a new policy the original packet is still going to be sourced from the trust zone to destination is going to be untrust or source address is going to need to be your server IP address because you're going to create a one-on-one translation. I'll show you that in a minute translation packet is going to have source static IP address with the IP on the outside and set to bi-directional bi-directional setting will enable an implied rule which is going to have the reverse direction from this one and will allow inbound connections to this server on any port now if you have a single IP address on the outside of your firewall and you need to share this one you can create what we call PAT policies which is a port address translation policy the difference is: let me create a couple of policies the source zone is going to be untrust, the destination zone is also going to be untrust. if you look at the little illustration and if you remember what I told you earlier: zones are determined based on a route lookup, so the source IP address towards your server is going to be located on the internet. The IP address is going to be a random public IP address which will hit your default gateway policy which is located on your external interface and the destination zone will be to an IP address which is attached to your external interface which is also located in the untrust zone so from a NAT perspective the source and destination will both be untrust while for the security policy the source zone is going to be untrust, destination is going to be trust because the final destination is your internal server on for example 10.0.0.10 In this scenario we only need to put in a destination address translation don't forget to set the destination IPaddress and this is going to ensure any inbound connection to your public IP address is routed to your server now if you need to share the same IP address between multiple servers on different ports you can change the destination service to for example and smtp and then set the translated port to a different port if your internal server is running for example port 55 you can translate destination port 25 on the public side internal port 55 you can leave it empty to keep the original port or just put in 25 so you have an overview of which ports you're actually accessing if you now need to have the same translation for a different destination port to different destination server can go ahead and clone this policy and change the name for example to 80 my destination service is going to be HTTP on port 80 same IP address, translated packet Ican translate this to a different server and again i can either use the same destination port or a completely different destination port if this server is turning its service on port 8080 with these NAT policies is in place our security policy should look something like this. We have our inbound security policy from untrust to trust to our two external IP addresses for the applications I'm willing to allow into my network with security profiles to protect myself of course and my internet access rule from trust to entrust For my allowed applications out and with a bunch of security profiles thank you for watching please feel free to leave a comment below or like this video and don't forget to subscribe to our channel thank you

Channel: Palo Alto Networks LIVEcommunity

Views: 31,514

Keywords: Palo Alto Networks, Tutorial, Network, Cyber Security, Firewall, Live Community, Tom Piens, network address translation, port address translation, NAT, PAT, DIPP, tpiens, reaper, dynamic ip and port, dynamic address translation

Id: zLqsSuOVzzU

Length: 10min 6sec (606 seconds)

Published: Wed Oct 12 2016