Tutorial: Understanding the NAT/Security Policy Configuration

[Music] I'm mark bowling one of the instructors at Palo Alto Networks and I want to spend a few minutes talking about how to understand the relationship between the nap policy and the security policy on the Palo Alto Networks firewall one of the challenges of the Palo Alto Networks firewall is explaining to an end user how to create Nance security rules in a way that's easy for them to remember often the phrase Prine an IP post NAT zone is employed to describe how our NAT works but often the end user has left confused as to how it applies many people think it applies to either to NAT policy or to the security policy or both and this confusion tends to leave our end users thinking that our nap process is overly confusing I'd like to demonstrate a simple method of describing that that works in all scenarios and also show how bi-directional now trolls can cause problems in specific situations to start off there are four questions that you should ask in a specific order that will help better explain our NAP process question 1 what is the original source address of the computer's initiating the connection question 2 what zone is that address in question 3 what is my original destination address in question 4 what zone is that address or collection of addresses in the questions regarding the nap policy and the security policy are identical with the exception of the last question on the security policy that would be question 4 what zone will the packet finally come to rest in in this first example we want to create simple NAT and security policy rules that will allow internet access for computers on the inside subnet our inside zone is using the 10.1.1.10 t4 subnet and the outside zones are going to use the 66 dot 1.1.1 IP address for translation out to the internet so let's start with the first question what's the original source address their computers initiating the connection in our case it's 10.1.1.10 / 24 question 2 what zones that address in this address range is in the inside zone so we'll choose that for the source zone here question 3 what is my original destination address since we're trying to allow general internet access here we can use any for the destination address and we will further refine that by asking question 4 what zone is that address or collection of addresses in of course that would be the outside zone now since we're not trying to select a particular outside address to translate our traffic to we don't need to put it in a particular service so we'll just select any here for the service then we'll choose dynamic IP import as our source translation type and assign our interface address as the translator to dress for outbound packets and then next we'll go and configure the security policy rule that will control the traffic out to the internet all the NAP policy does is define how we will translate IPS but it has nothing to do with allowing or denying traffic now let's ask almost the same exact questions when setting up the security policy rules so we can allow traffic out to the internet question 1 what is my original source address of the computer's initiating the connection in our case it's 10110 / 24 in question 2 what zone is that address in this address ranges in the end we'll choose that for the source zone here question three was my original destination address since we're trying to allow general internet access we will use any for the destination address then we change question four when talking about the security policy role question four is what zone will the packet finally come to rest in in other words when that packet lands on his final destination one zone will actually be in from the firewalls perspective in this case our packet is destined for a server out on the internet as far as the firewall is concerned that's the outside zone just keep in mind that when dealing with the security policy that the source zone and both the source and destination addresses refer to pre NAT IP information only the destination zone reversed post NAT information that's why Palo Alto Networks refers to pre NAT IP post NAT zone or source IP and the security policy is the IP address before it goes to the NAT process in the destination zone is where the packet comes to rest after going through the NAP process finally we tell it what the application to match and set the action to allow okay so now that we've created the basic internet access policies let's say that we have a web server in our DMZ zone called server one that we want to allow access to from the internet let's start by asking the same questions in the same order that we asked the first time so let's start with the first question question one what is my original source address for the computers initiating the connection in this case we want to allow anyone on the internet to get to our server so the source address would be any question - and what zone are those address is in Internet addresses are in our outside zone so we'll choose that for the source zone here question 3 what is my original destination address since people on the internet will be accessing a public IP address to get to our server we'll put in the public IP that we've chosen here in the destination address field because this is the original address that the user tried to get to in question for what zone is that address in of course our public IP would be in the outside zone of our firewall since we're not trying to determine where the final packet goes based on the service we'll just select any for the service and since we need to translate packets from the Internet to a specific destination inside our network will choose the 192 168 1 dot 100 IP address as the destination address now our destination ramp policy rule is complete and we can go ahead and set up the appropriate security policy role to allow traffic to reach our server let's start by asking the same questions in the same order that we asked the first time question 1 what is my original source address of the computers initiating the connection we want to allow any address on the internet to get to our server so we'll choose any here question to what zone does that address in internet addresses or in our outside zone so we'll choose outside for the source zone here question 3 what is my original destination address the internet users are going to try to get to our server using the firewalls public IP address that we've associated with a server so we'll enter 66 1.1.2 here and remember the question 4 is slightly different what zone will the packet finally come to rest in in this case our packet is destined for our internal server which is in our DMZ zone so that's what we'll choose here then we just allow web browsing on this default port and our server access configuration is complete now let's say you're just about all done and someone comes along and tells you that even though people on the Internet can reach your web server using its public IP nobody on the inside zone can get to your server using its public IP the reason is because when people on the inside zone go to the sixty-six dot one dot one dot to address the packet goes out like it's going to end up on the server in the outside zone but since your server is in the DMZ zone their packets just get dropped to fix this issue you need to go back to your policies and ask the same questions all over again so the scenario is computers on the inside zone need to access server one in the DMZ zone using its public IP address in the outside zone that sounds complicated but as you can see in just a second if you just ask the same questions in the same order as always it's no more complicated than any other net question here we go starting with an app policy question 1 what is the original source address of the computer's initiating the connection in this case we want to allow anyone on the inside zone to get to our server so the source address would be any question - and what zone of those addresses in inside addresses are in our inside zone so we'll choose that for the source zone here question 3 what is my original destination address since people on the inside zone will be accessing the public IP address to get to our server we'll put in the public IP that we've chosen here in the destination address field because this is the original dress that the user tried to get to in question 4 and what zone is that address in of course our public IP would be in the outside zone of our firewall we still don't care about translating our traffic based on service and we're still trying to get the traffic to a specific destination so all the rest of our values stay the same now we go to the security policy and just jump right into the questions question 1 what is the original source address of the computer's initiating the connection we want to allow any address on the inside zone to get to our server so we'll choose any here question to what zone of those address is in inside addresses are in our inside zone so we'll choose inside for the source zone here question 3 what is my original destination address inside users are trying to get to our server using the firewalls public IP address that we've associated with the server so we'll enter 66 dot 1.1.2 here in question four which is still a little bit different what zone will the packet finally come to rest in in this case our packet is destined for our internal server which is on our DMZ zone so that's what we'll choose here now if you'll take a look you'll notice that the new NAT and security policy rules look identical to their predecessors with the exception of the source zone because of that we can consolidate these roles into one it'll give you the same functionality and it looks cleaner too and now we've completed what sounded to be a somewhat complicated NAT requirement by asking the same questions that we asked for every other NAT situation now I want to talk about an issue that is caused by using bi-directional NAT rules here's the scenario a company has two servers and has created a bi-directional NAT policy rule for each one server one has a NAT rule configured to use the sixty-six dot one dot one dot ten outside IP address to reach a public host at 24.1 2.3 the administrator configured it for static NAT and check the PI direction on that box so that the firewall would automatically create the corresponding destination net rule server two also has an outro configured to use the sixty-six dot one dot 110 outside IP address to reach a public host at 28.4 NAT 5.6 the administrator also configured it for static NAT and check the bi-directional checkbox so that the firewall would automatically create a corresponding destination that rule checking the bi-directional NAT box is convenient it automatically creates in that in the reverse direction as the original one that was defined but it doesn't show up in the web UI you can only see this automatically created NAT role from the CLI this is sometimes used as a shortcut when people don't understand how to properly create destination Nats so they create a source net instead and let the firewall do the rest of the work now when the administrator checked the bi-directional NAT box what he thought the firewall was doing automatically behind the scenes is this but during his troubleshooting he noticed that no traffic was matching server 2 and all inbound traffic from the outside zone was being forwarded to server 1 instead in reality when he checked the bi-directional NAT box this is what was actually created when the bi-directional NAT box is checked the reverse direction that is created with any for the source address and the source zone because of this when traffic comes in from 208 not for DAF six instead of forwarding to server two it gets forwarded to server one because of the any statement in the source address of the first rule therefore traffic will always match rule 1 and will never match rule 2 if the administrator had just created two separate unidirectional NAT rules that were configured to do what he wanted in the first place this problem would have never happened when creating bi-directional NAT rules be aware that this could be the end result if you're not careful now finally let's look at the occasions that require the service to be defined at the NAT policy rule instead of using any for the service we only need to define the service in the NAT policy rule when we're trying to choose the destination of a packet based on the port that the packet is using look at this NAT rule base rule 1 & 2 or source NAT and rule 3 & 4 destination Nats rule 1 says that when the server initiates traffic to the outside zone using TCP 1 2 3 NAT is using the 66 dot one dot one dot 10 IP address but when it initiates traffic to the outside zone using TCP 161 that is using the 66 dot one dot 1 220 IP address because we define the service in the source net rule we can choose the outside address that the server will use when using different services rules 3 & 4 are configured as destination Nats where one outside IP address is being used to send traffic to two different internal servers based on the service of the received packet rule 3 will nap package - server - when someone is trying to make a connection on TCP 82 66 dot one dot one dot 30 but when someone is trying to make a connection on TCP 25 to that same public IP address will forward those packets to server 3 just remember as long as you don't need to use a service as a matching criteria to decide what IP address packets we'll use when coming from our going to their final destination just leave the service as any in the NAT policy rule and that's all there is for this segment on that I hope it helps I'm mark bowling with Palo Alto Networks

Channel: Palo Alto Networks LIVEcommunity

Views: 75,184

Keywords: NAT, Destination NAT, Security Policies, post-nat zone, bidirectional, bi-directional

Id: Ahrao6kBg8w

Length: 12min 47sec (767 seconds)

Published: Wed Nov 08 2017