Traffic Flow & Forwarding Logic

0:00Hello and welcome. My name is Keith Barker, and in this set of videos, we get to focus our attention on the forwarding and logic on a Palo Alto firewall, including if there's a problem or hiccup, how we can verify with evidence that what we think is happening is happening. Or if the routing issue, we can also identify what we would expect to see in absence of correct routing. So I'm glad you joined me for this journey, and I'll see you, my friend, in the very next video.

0:00I took the liberty of updating the topology just a little bit. Here on Firewall A, I've got three zones. I've got the inside zone, which includes interface 1-1 and 1-2. I've got the outside zone, which includes interfaces 1-3 and 1-4. Then I've got this DMZ zone here, which includes interface 1-5. And DMZ here in yellow may be a little hard to read, so I'm going to go just below that, just jot down DMZ and point right there. Also on Firewall B, I've got 1-8.20, which is associated with the inside zone over there. And over on Firewall B, interface 1-8.25 and 1-8.26 are both associated with the outside zone on Firewall B. So I'll add those arrows as well, just for clarity there. And on the inside zone, these two interfaces here and over at Firewall B, just that one interface. So the logic and benefit of using zones on the Palo Alto Firewall and pretty much on most next generation firewalls is that we can set up our policy based on zones. So if we have a policy that says allow traffic, if it's sourced on an interface that's coming into the firewall on the inside zone, and from a layer three routing perspective, being forwarded out of an interface associated with the outside zone, then permit it or deny it or take some other action on it. So our security policies are going to include the zones as part of the policies, and those zones include the various interfaces assigned

1:18to those zones. But I also want to emphasize in this set of videos is that it really doesn't matter what our policies say, like what's permitted or what's denied, if we don't have our layer three routing set up first. If it's not working correctly, our policy rules will never be hit. So as far as an order of operations, the routing is going to be decided first, then assuming we have routing in place, then we're going to go ahead and consider our policy. Because there's a temptation sometimes if the firewall is not working as expected to say, oh, let's go take a look at the policy and we can change and modify our policy. But if the routing isn't in place correctly, that policy and looking at that policy is not the problem. It's going to be routing.

1:55If that's not working, the policy isn't even considered. So in this video, as we take a look at the traffic flow and forwarding logic, I'd like you to think of every step along the way, what type of evidence do we have regarding a failure, for example, on the firewall? So as part of that evidence, the first thing we got to verify is the plausibility or the possibility from a routing perspective based on the routing table and firewall to actually forward the traffic. So can the firewall forward? And that's going to be based on its forwarding table, on its routing table. Now, if it's plausible based on the routing table that the firewall could forward a packet, for example, from this user out to the public internet, the next question we could ask is, is there a session in the session table for the firewall?

2:33And we can view that session in the session browser from the GUI or from the command line, just to verify whether or not there's a session present. And then the third piece that we could use is the logging. And on the Palo Alto firewall, we'd go to monitor, logs, and then go to the traffic logs and just see whether or not there's a log entry for the session. And if we see a logging entry in the logs, that proves that a policy was hit. And then that policy would have been the factor regarding was it permitted or denied as far as the traffic coming from the client out to the server. So for the logging, I just say, is it there? Is it logged? And if we don't have these two elements, for example, there's no session information and there's no logging, it's a really, really good tell that our routing is having a problem.

3:15So the absence of log entries and sessions is not a terrible thing. It's helping us point to the direction of where the problem is. Now there's also a consideration that we'll look at together in the set of videos where we have a flow of traffic and yet it's not showing up in any logs. So if we have session information, however, we don't have the logging information. One of the reasons for that could be the security policy rule that it matched on is not logging. There's no logging action or it's hitting a default rule that doesn't have logging. And so we'll experience both of those scenarios as we go through these videos together. So let me clean it up a little bit and let's chat about some other things that could go wrong. Let's imagine that in our security policy, the policy says if traffic is sourced on an interface on the firewall, meaning it's coming into the firewall on an interface associated with the inside zone and a fancy way of saying that traffic coming in would be ingress traffic. If it's coming in on the inside zone, again, that really means an interface associated with the inside zone, like for example, 1 slash 2.

4:13And in our security policy, if it says if that traffic is being routed out of an interface that's associated with the outside zone, an example of that from a routing perspective would be routing it out 1 slash 4 or 1 slash 3, which are both associated with the outside zone. In the policy, go ahead and say, if that's the case, go ahead and allow the traffic. So allow is another way of saying permit or go ahead and forward. And a security policy can also have many other considerations, including the actual source IP address or the range or the applications being used or various other security profiles that are associated with that security policy rule.

4:45But in its basic sense, if this is the security policy rule, that traffic coming in on the inside zone, being routed out of an interface on the outside zone, please allow it. As far as the data plane is concerned, that's enough to get it to go. Now, also to get out to the public internet, if this client is trying to go out to the internet, we'd also need some address translation rules here as well. So in this set of videos, we're going to focus primarily on the traffic flow and forwarding logic. And in other sets of videos, we'll focus on things like address translation and additional security policy tweaks and SSL inspection and so forth. But for now, we're focusing just on the traffic flow and forwarding logic. Let's imagine our traffic gets out to the public internet. So here's the server the client's going to. And the question is, if everything is working as it should, the client goes out to that server, the server responds, comes back to the firewall, and then the firewall forwards it back to the client.

5:32And that return path is a big part of the story too, because getting a network to function is bi-directional communications. So if we are successfully able to go out, but the actual return path isn't in place, or we have asymmetrical routing where the reply traffic is coming back through another path, those also could cause hiccups or issues or problems on a firewall that isn't able to see both sides of the conversation. Because these firewalls are stateful in nature, meaning if we have allowed in our security policy rule, the initial flow of traffic from this client going out to the server, dynamically, that reply traffic should be allowed, assuming that reply comes back through the same firewall. Now, one element that's important to be aware of as we look at and troubleshoot as we go through this together is when we make changes, or we're doing testing, focusing on just one item at a time. And that is really important, because if we change three or four things, we might not know, if it starts working all of a sudden, we may not know exactly which component is now causing it to work. And as a result, we won't really know why it was broken. And as I mentioned, if we are troubleshooting and we're looking at the logs and we don't see the log information, that's not a totally negative thing.

6:41That means, hey, either we have a security policy rule that was hit that doesn't have logging enabled, or it never hit a security policy rule, which once again, would point back to routing. So as we focus on traffic flow and forwarding logic, here's a few items I'd like to put on the table for later sets of videos. Things like network address translation, policy tuning, app ID, or identity services. Those are all extremely important as well. However, in our focus on traffic flow and forwarding logic, I'm going to go ahead and punt those to other videos and other skills where we'll focus on those in depth. And one other element I just want to share with you as we jump in to looking at the traffic flow and forwarding logic. When we're doing logging our security policy rules, there's options of saying when we want to log the traffic. At the start, for example, the start of the session, or at the end, we can also do both. And from the logs that are created, I'll also walk you through how we can identify a log, whether it was created based on a start or end action in the security policy rule as well. So with that in mind, in the next video, I'd like to walk you through the forwarding decision chain that the Palo Alto firewall goes through when it receives a packet and is making a decision on how to forward. So I'll see you in the next video in just a moment.

0:00When we're troubleshooting forwarding on a Palo Alto firewall, we need a consistent story that we can retell and explain quickly. Or if we're not explaining it to someone else, we also need a story in our own mind that we can go through as we troubleshoot the routing. So here's the story. Once upon a time, there was traffic that was coming into the firewall. Meaning, for example, this client has a default gateway. It's 10.12.0.51. The client is trying to reach, for example, an outside server here at 8.8.8.8 or something beyond its local network.

0:32So it forwards the frame at layer two to its default gateway, who then is now in charge of forwarding that packet. So when that traffic comes in, it's coming into the firewall on an interface. And that's referred to as the ingress or incoming interface. So I'll write down there, inbound. Now on the interface where it was received, that interface is associated with a zone. So in our case, when this device sends a frame of data into the firewall, it's coming in on 1.2. 1.2 is associated with the inside zone. So from the firewall's perspective, in the context of this interface in that zone, that ingress packet is coming into the firewall on the inside zone. So as far as our story goes, traffic came in here. It came into the firewall on this zone.

1:14The next part of our story, the second chapter, if you will, is the routing. And specifically, we're talking about layer three routing. And that applies to IPv4 as well as IPv6. And by default, we only have one VR, one virtual router. However, it has the capability of having multiple virtual routers. And depending on which interfaces are associated and assigned to that virtual router, that also is going to have an effect because each virtual router has its own routing and forwarding table. So in our case, we have one virtual router to deal with. So we're looking at the routes within that virtual router. Then as part of step number two here and the virtual router, it's going to do what routers do. And that is they're going to look at the destination address. So if this client is going out to 8.8.8.8, the firewall and its virtual router is going to consider the routing table to find out what is the best route it has to reach that destination IP address. Let's imagine the firewall and its virtual router have five directly connected networks, which does the 1011, 1012, 1015, and also the server spreader A23.12 and server spreader B24.12. So that's five directly connected networks. And then a default route like this for IPv4 that says the next hop is server spreader A at 23.1.2.1. So in that case, we're trying to get to 8.8.8.8. The best match, the longest match, we'll take a closer look at

2:33that as well. But the best match is the default route, which is a catch all for everything that wasn't more explicitly matched in the routing table. And based on that default route with next hop, it then is going to choose the egress or outbound interface. And that's step number three. So the egress interface the firewall is going to use based on its default route to reach 23.1.2.1, that's the next hop, is going to be this interface right here based on the static route that it currently has using server spreader A as its default route. So in that case, the egress interface here would be 1 slash 3. So over here on the ingress, let me make a note that's 1 slash 2, that's the interface. And over here, it's 1 slash 3. And then 1 slash 3, as we discussed in the previous video, is associated with the outside zone based on the configuration of the firewall.

3:15So right down here, outside zone. So in our story about how this firewall is making a forwarding decision, we haven't even yet gotten to the policy consideration because the routing first regarding the inside zone, going to the outside zone, with that information in mind, it then can take a look at the actual security policy rules to see whether or not that traffic is allowed or not. Because if we never got through the routing part, for example, it couldn't determine the egress interface to use, it wouldn't even bother in considering or consulting the actual security policy. And that's why layer three routing is way before and first compared to the actual security policy rules. So think of the security policy as something that's being processed after the layer three routing has been established. Now, one other thing to be aware of is that not every route is correct. For example, we may have a route that is pointing to the wrong next top address, it's not reachable, or we may have a next top that's not working itself and not able to forward. But if we had a situation where the service provider A, for example, could not forward traffic, we would still have made our routing decision. And as far as the flow of traffic, the initial flow would go through the firewall. So we should have session table information there for the initial one-way flow, trying to go out. And if we're doing logging on the security policy rule that allows that traffic, we should also have log entries as well that would show up here at the firewall. So let me make a little note here. The route must work for our client to successfully communicate with the

4:36outside world. So if it's an external component that's not functioning correctly here, for example, a service provider, we'd still have our session information and our logging. Whereas if we didn't have a default route at all, we wouldn't expect to see session information. And we also would not expect to see logging information. So to reinforce this concept, let's do a quick demo. Let's go over to this Raspberry Pi who currently is using firewall A as its default gateway. And let's send some traffic out to the public internet. I've included as part of the skill, a copy of this topology. I would encourage you to have it ready and able to see either print it out or put it on a separate screen. So as we're doing the configuration, the demonstrations, you have a comfort level with exactly where devices are. So this is our Linux device right here on the 10.12.0 network that we're about to look at. So the first thing I'd like to do is confirm that we're on the right device. So let's go up to a command prompt and let's do an ifconfig or ethernet1, which is the lab interface. And it has the IP address 10.12.0.101. And prior to sending traffic out, let's just take a look at the routing table on firewall A. So here's firewall A. To look at the routing table, we'd go to the network tab up here. And on the left-hand side, we click on virtual routers right there. And then we have a more runtime stats right over here. So we'll click on more runtime stats. And here is the route table. However, not every single route is usable.

5:53So if I see the winners, we go to the forwarding table. So if the client tries to go out to, for example, 1.1.1.1, which is a CloudFlare address, the firewalls is making a routing decision. It's going to take a look at all the routes and it doesn't have a more exact route for the one anything. So it default to the default route right here and use the next hop of 23.1.2.1, which is going out through service provider A. Now behind the scenes, what's allowing that to happen once the routing decision is being made is the security policy. So for policy, we go to policy and on the left, we'll click on security. And it's this rule right here called into out. Let's take a look at that.

6:30That's saying if traffic is coming into the firewall on an interface associated with the inside zone and that traffic from a routing perspective that we just looked at is going to be routed out of an interface associated with the outside zone. And then this is wide open, any application, any port, any service, the action is going to go ahead and be allow. You don't in production need the log at the start and at the end. I'm going to enable both of them. They're both enabled right here. And I'll also show you in the logs how we can identify whether it was a start or end log entry that we're looking at. Effectively for working sessions, we're going to have twice as many logs compared to just clicking on one of those versus the other. So I'm going to use both of them. And just as a side, I also have a NAT rule set up for address translation. So it'll actually function. Again, our focus here is on the routing and again, the routings that are network virtual routers. We have one virtual router. And before we bring up our client, let's do a couple things. Let me close that. So let's go to monitor and with monitor selected, let's go to session browser. And this is showing us the current sessions I have in place. Let me click right here and adjust columns. And based on these log entries, this is traffic coming in to the firewall on one slash one, which is from another client. And the Linux client is coming in on one slash two. And just to confirm that, yep, the Linux client is coming into the firewall

7:46off of the firewalls one slash two interface. So that's the session browser and still under monitor. It went to logs and expanded that and went to traffic logs. This will also show us the log based on the security policy rule that's doing the logging. All right. With that in mind, let's go to our client. All right. So here's our client. Let's start off with a ping out to 8.8.8.8. Fantastic. We'll do a control C to stop that. So let's do a ping out to cloudflare1.1.1.1. That's working. Great, great, great. We'll do a control C there and we'll open up a browser and I'll have a whole bunch of tabs that automatically are coming up here, including a speed test, which is shown right here. Also some YouTube traffic, which is shown right here. And also a open tab to Palo Alto, which is shown right here. And I'll leave that open. So because that's all working, the routing decision was made. The security policy was considered. It allowed that traffic. And as a result, we have session information as well as logging information.

8:43So let's take a look at those in order. Let's go ahead and start off by going down to our session browser. And here in the session browser, you'll notice we have a whole bunch of session information here and our client's at 10.12.0.101. So I'm going to click on that source that'll put it in as a filter. We'll click on the arrow and that'll show us only traffic sourced from 10.12.0.101. So I'm going to go ahead and use the down arrow, adjust columns. And we can also add or remove columns as well that we want to see or not see. So this is showing from inside to outside zone wise. We could also add the ingress and egress interfaces. So let's go to columns. Oh, and they're already enabled right there. Ingress and egress. I just wasn't looking hard enough. So let me take the ingress interface and you bring that over here and I'll take the egress or outbound interface and drag it over here. So here it's showing us the effectively ingress and egress zones as well as the interfaces.

9:29And that's why we have those zones there because those interfaces respectively, ethernet 1 slash 2 belongs to the inside zone and ethernet 1 slash 3, the egress interface belongs to the outside zone. Then we have source IP, destination IP, et cetera, et cetera, et cetera. So that's the session browser. We can also see that from the command line. So here's the command show session all. You can press enter to go one line at a time or space do one page at a time. So we have quite a few sessions. And these are the same sessions that we saw in the GUI. So if we scroll up, there's our command show session all. Here's the source IP address and source port that came into the firewall in the inside zone. And the destination was this IP address and this port and the egress zone was this zone. And here's the application that was being used. So we have quick, very likely that was YouTube and some HTTPS and some Netflix. That was our speed test and some Google apps and more.

10:18All right. So with that in mind, let's take a look at the logs. So back at the firewall, go to monitor and under logs, go to traffic logs. So here in the type, it's specifying the type of log. So if it started logging at the start of the session, it says start here and end represents the end. So if you don't want to see that column or don't need it, you can go ahead and just go to columns and say, you know what, we don't need to see that and simply remove it. I've also taken the liberty of adding a few additional columns here just for educational purposes. So here's the source IP address. We can also put a filter here by clicking there and clicking on go to activate that filter. And that way it's only going to show us where 10.12.01 is the source address. So here's the source. Here's the destination where that client was going to.

10:55Here's the ingress and egress zones. Here's the ingress and egress interfaces that caused those zones to be used, which once again points to the fact that routing is working because security policies were then considered and we have sessions and logging information as a result. Now, when it comes to routing, if we go back to network and go to virtual routers, we'll go to the more runtime stats for our virtual router and we look at the routing table. In the next video, I'd like to focus our attention on the logic on the Palo Alto firewall regarding how it decides what is the quote unquote best IP route to use for a given destination. So we'll cover that in the next video and I'll see you there in just a moment.

0:00I'd like to focus on the decisions that the firewall is making regarding layer three routing and come up with a really good way to understand best. Because at the end of the day, when the router, or in this case, firewall, firewall A is making a decision about how to forward a packet, which egress interface it's going to use, it's going to choose the quote unquote best route. And when it comes to the concept of best, let's use an analogy. Let's say we have some advice that's coming in from two different people, from person one and also from person two. So let's say person one, let's say it's about investing. And they say, you know what? It's a good idea to invest. And that's all they say. And it's very vague. And over here, somebody says, well, I've had 20, 30 years experience in this business. And I think you should go ahead and buy these specific kinds of index funds and you should hold them for a period of time. And as you get older, take less risk. And it's more specific. So over here, it's vague.

0:54And over here, it's very specific. So assuming that the person over here is accurate, which of those two would be the quote unquote best advice? And the answer is the one that's more specific. And when it comes to routing on the Palo Alto firewall, it's just like that as well. If it has a bunch of routes that it could use in its routing table, it's going to choose the best route, which is the one that's most specific. So let's narrow that down a little bit and talk about what does that mean more specific? Let's take this routing table here on the firewall, firewall A. It has a directly connected network for 10.11 with a 24-bit mask. It is directly connected to this network here, 10.12.0. So that's in the routing table because it's directly connected. It's got the DMZ of 10.15.0.0. That's in the routing table. And it's there because we configure the interface with an IP address, for example, 10.15.0.51 with a 24-bit mask.

1:44And as a result, it believes it's on the 10.15.0 network because of how we configure the interface. It also has a directly connected network of 23.1.2.0 with a 24-bit mask going through service provider A and also through service provider B with 24.1.2.0.24. And then we also have on this firewall, a default route that says this for IPv4. Effectively, if none of the other routes match, go ahead and use the default route, which has the next top of 23.1.2.1. Now, as far as best is concerned, let's imagine this client is trying to do a ping out to Cloudflare at 1.1.1.1. So that packet comes into the firewall on interface 1.2, which is part of the inside zone. And the firewall is looking at the destination address. It is considering its routing table. It doesn't match these three octets. It doesn't match these three or these three or these three. The destination here does not match on any of these other routes, so it's going to use its default route.

2:40Think of it like a last ditch effort. If nothing else matches, it's going to use the default route. However, let's add some more static routes. So this is a static route, and let's add two more, just in theory here. Let's add a default route for 1.0.0.0.8 and 1.1.0.0.16. And let's say that the next top for the 1.0.0.0.8 with 24.1.2.1 as the next top, and the static route for 1.1.0.0 with the 16-bit match, the first two octets effectively, that the next top is going to be, let's say, this server, which wouldn't be a real good decision. But just for demonstration purposes, let's say that 10.15.0.100 is the next top, which would imply setting out this interface in that direction, which, by the way, wouldn't work for getting to Cloudflare, but this is just an example. So now, once we have these static routes configured, and we click on commit, and we let that commit complete, then when the client pings 1.1.1.1, the firewall, as it receives that packet on 1.2, it now considers the destination and its routing table, and the default route is no longer the best match, because there's two routes that are even more specific. This one right here is eight bits long, and so that's matching on the entire first octet, and this one

3:57right here is even matching on more. It's more specific. So best, in a routing perspective, means the longest match from the routing table, and as a result, that's the longest match. We're matching on the first 16 bits, and that's the one the firewall is going to choose from its routing table. Now, unfortunately, based on the next top, the firewall is going to forward it up here to this poor server at .100, who says, I don't know what to do with that. In any event, that's how it makes its decisions. So if it's wrong or incorrect, that's going to cause the traffic to go the wrong direction. Now, the cool thing is, in the logs, if traffic really is being routed, for example, out interface 1 slash 5 here, that's great to know in the logs, because then we can go back and take a look at the routing table, and we can ask ourselves the question, why did the firewall choose to forward in that direction, out interface 1 slash 5, and go back to the routing problem, or in this case, the static route that's causing the forwarding problem?

4:48And this firewall is not responsible for downstream devices and how they're going to handle the traffic. The firewall is just using what it knows about, based on what it's learned, either through static routes or dynamic routing protocols, or what it's directly connected to, to make its routing decisions. And again, it's based on the longest match, looking at the packet coming in, which route in its routing table matches the most bits of that from left to right, and it's going to use that route to make its routing decision. So I thought what would be fun is to go ahead and demonstrate this in action. So currently, we have our default static route going through service provider A, but we don't yet have these two static routes for the 1.000 and the 1.100, 8 and 16 bits, respectively. So what I'd like to do is, before we create those new static routes, let's take a look at the routing information, both at the GUI and the CLI for this firewall, before we add these static routes, and then we'll add the static routes, and then compare and contrast the difference. So let's first start at the Raspberry Pi, and let's do a ping out to 1.1.1.1, and then let's also see if this will cooperate with us. Let's do a trace route out to 1.1.1.1. Let me also do a dash n for don't bother doing name resolution to 1.1.1.1. And there's our path going out. So the first hop is the firewall interface. And to make

6:05sure on the same sheet of music here, it's the interface one slash twos address. That's the first hop in the path. And then the next hop based on the routing table should be 23.1.2.1, which is through service provider A. So there's that next hop 23.1.2.1. And then it's looping back through my home office network here, and then off to my service provider after doing some additional NAT there, and then onward and upward till it finally got to its final destination. And here we're timed out. We had some devices that weren't responding with the ICP messages indicating that the time to live had exceeded. So here's the firewall. If we want to look at the routing table, we could do a show routing route. So there's our command right here, show routing route, and that's showing us the routing table. But that's not the winners table. The winner's table is the FIB, the forwarding information base. And the command to see that is this one right here. It's show routing FIB for forwarding information base.

6:57So we have one virtual router, and that's what we're looking at here. Here's the name of that virtual router right there. There's the five interfaces that are allocated and part of that virtual router. And here's the route table. So here are the flags. We scroll down. Here are the routes. So here we have our default route with the next hop of service provider A and the egress interface to reach that next hop is Ethernet 1 slash 3. Then we have the 10.11.0 network and the 10.12.0 network and the 10.15.0 network. It's also including some host routes as well. This little H right here effectively is a 32-bit route for the actual interface itself. And then for the service provider, we have the 23.1.2 and the 24.1.2 networks reachable via those respective interfaces.

7:40So if we want to see the forwarding information base from the GUI, it would look like this. Here in the GUI, we'd go to network. On the left, we'd go to virtual routers. And then with our virtual router here on the far right, we'd click on more runtime stats. So we'll click on more runtime stats. And then here's the routing table. If we click on forwarding table, here's the forwarding table right here. So if we want to look for a specific route, let's say we had thousands of routes, we could just go ahead and put in, for example, 10.11.0.0 with a 24-bit mask, press enter, and it would filter and show us that specific route. Where it says next hop is 0.0.0.0, that implies that we are directly connected to that network through Ethernet 1.1. If you want to look for the 12 network, we go ahead and change that to a 12, press enter, and then it shows us that that's reachable out Ethernet 1.3 for that directly connected network. Or if I look for the default route, 0.0.0.0.0, and press enter, and that will show us our default route. We can do the same type of filtering here in the route table. And that way, if we had routes, even ones that were not actively being used, they would show up right here. So again, the forwarding table is like the meat and potatoes regarding what the firewall is actually using to make forwarding decisions. So when the client was sending packets to 1.1.1.1, it didn't have a better match on any of the routes, and so it used the default route, and the egress interface was 1.3. So back at the CLI, we have a couple other tools

8:55we could use, including the test command. So we use the test command of test fib lookup, virtual router, the name of your virtual router, and then the IP you want to test, and that's going to show us how it would forward based on the current routing table. So here's the destination. So the next hop would be 23.1.2.1, the egress or outbound interface would be 1.3, which is at 23.1.2.51.

0:01I'd like to go in and walk you through changing the routing information on the firewall by adding a couple of static routes. And let's do it based on our plan, what we walked through earlier with the whiteboard here. Let's create a static route for the 1.0.0.0 network with an 8-bit mask, using the next top of 24.1.2.1, which is through service provider B, and then yet another one with 1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 static routes to our default virtual router we'll go to network on the left we'll click on virtual routers and then here on our virtual router we'll click on it to edit it and then we'll go down to static routes so currently we have our default static route going through service provider a at the next top of 23.1.2.1 with an egress or outbound interface we're using of 1.3 so we'll click on add so i'm going to call this 1.0.0.8 bit that's just the title the name of it and then for the route itself it'll be 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

1:450.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

2:150.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

2:450.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

3:150.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

3:450.0.0.0.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

4:150.0.0.0.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

4:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

5:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

5:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

6:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

6:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

7:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

7:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

8:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

8:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

9:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

9:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

10:151.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

10:451.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.

11:15Here in the GUI, if we go to monitor and on the left-hand side, if we go down to session browser right there, you notice we have these pings right here that are going out. Protocol number one from one slash two, that's where our client is, and the egress interface is one slash five. There's no response coming back, but we have session information and also we should have logging information because the rule permitting that is also set up for logging. So right here on monitor on the left-hand side, we go to traffic logs. Here we have our ping packets right here. So from the inside to the DMZ, ingress interface one slash two, egress interface one slash five.

11:49And just as a quick confirmation, if we went back to network and went back to our virtual router and then we edited our virtual router, and I'm going to go back to static routes, let's remove this one right here. So go ahead and take this 16-bit route. We'll delete that. So now we have just a eight-bit route, which is more specific for one, one, one, one than the default route. We'll click on okay. We'll click on commit and then commit again. Now if the client tries to ping one, one, one, one, the best route, the longest match route for one, one, one, one is this eight-bit route with the next top of 24.1.2.1 going out interface one slash four.

12:23Now in theory, that should all be well and good. However, there isn't a NAT policy associated with one slash four. So because address translation isn't there, it's going to cause a failure for that traffic to actually get back to the client because it'll be trying to source it from a 10.12.0 address space and to service provider B at the moment, based on our rules here, we're not doing that. However, we should be able to see it in the logs because into out is allowed and we can also confirm the routing decision is going to make by looking at the routing table on the firewall that when we try to reach one dot one dot one dot one, the next top would be 24.1.2 in the absence of that more specific route, the 16-bit one.

13:00So I think that commit is about done. So let's go back and take a look at the routing table. Back at the GUI, one way of looking at the routing table is to go to our virtual router under network, virtual routers, more runtime stats, and then click on the forwarding table. And sure enough, our longest match now for one, one, one, one is going out through interface one slash four is our egress interface with the next top of 24.1.2.1. We can also confirm that here at the command line by using the up arrow key. And now it shows the egress interface is ethernet one slash four and the next top of 24.1.2.1.

13:30So back at the client, if we did a ping now and I'll let that run, the reason it's not working now isn't from our security policy, but it's a NAT issue. So if we go back to the GUI and go to monitor and go to our session browser, here we have our ping attempt from 10.12.0.1.0.1 trying to go out to 1.1.1.1. And here it's also showing us the egress interface that we're using one slash four. And that's based on the routing decision. And because we're doing logging, we can also go back to logs and traffic. And here we have our logs of 10.12.0.1.0.1 that's the Linux device to one, one, one, one.

14:04So ingress interface was in the inside zone, egress interface of one slash four was in the outside zone. So that ping is being allowed. However, there's no response coming back because we're lacking address translation on that second service provider or traffic going to and through that second service provider. So because I don't want to leave this broken, I'm going to go back to network, virtual routers, go back to our virtual router, go to static routes and delete that one. And with that static route deleted, click on OK, do a commit and a commit.

14:34And then once this is done, the best route to reach 1.1.1.1 will be the default route because it's the longest match and it'll go out through service provider A.

0:00In this video, I'd like to walk you through an example of no session in the session table and no log. Although we have seen that once when we had a situation where the default policy rule was denying the traffic and that was the traffic originally between the inside and the DMZ and it's not logging by default. So outside of that, another reason why we'd have no session, no log is just on the fact that the firewall itself doesn't have routing in place, meaning when it gets a packet for a given destination, it's not sure how to reach it. Now to demonstrate that, I'd like to have this client go out to 1.1.1.1 again, we'll just do a simple ping to take a look at that and if the routing is messed up on the firewall where it can't route or forward at all, there will be no session information and there will be no logging because it never got that far because routing is first.

0:47So with that in mind, let's go to our client, verify that we can't ping this IP address, take a look for sessions, take a look at the logs to verify they aren't there, then we'll correct the routing problem, do it again, and then confirm that we have session information and logs based on how our security policy is set up. So here at the client, let's confirm our IP address for Ethernet1, so we're at 10.12.0.1.0.1 and let's do a ping out to 1.1.1.1. So that ping is continually trying to happen in the background, we'll do a control C, yeah, sent five of those, we'll go ahead and just let that run continuously here on this Linux device.

1:21And let's go take a look at the firewall. In fact, we can do it right here from the CLI. So here's the firewall, let's do a show routing fib, and this is the forwarding information base and there's effectively the routing table that's being used. And what I don't see here is I don't see a default route. And as a result, if the client is sending a packet into the firewall with the destination of 1.anything, there's no default route or any detailed route at all for 1.anything. And as a result, what we should see, or we should not see, is we shouldn't see any session information for this as well as we should also not see any log information because it never got that far because it's a routing issue that never allowed the policy even to make a decision.

1:58So we can do a test, the one we did before, test routing fib lookup, the virtual router, the name of a virtual router, IP 1111. And here it's showing us route not found, which means I can't get there from here. So if we minimize that and we go back to the firewall, go to network and virtual routers, more runtime stats, they'll tell us the same story. If we look at the forwarding table, there's no default route here. And as a result, it doesn't know how to forward out to 1111. So we'll close that. And let's take a look at sessions. So if we go to monitor, then we'll go down to the session browser right here on the left. Currently, there's some traffic involving protocol six, which is TCP, but there's no ICMP at all.

2:34So no session for the ping traffic. And if we go to the traffic logs, but notice here, there's also no ICMP traffic from our client at 10.12.0.101. And these are all old logs. In fact, let me go ahead and clear those out. On the Palo Alto from the CLI, clear log traffic, hit Y for yes, it'll delete all the traffic logs. Then if we go back to our client and I'll stop the ping, I'll restart the ping. And again, it won't show up in session information. And also it won't show up as logs because it never got that far to even hit a security policy rule.

3:07So back here under monitor logs traffic, we'll click on refresh and it is squeaky clean. And in our session browser, once again, no new traffic with ICMP protocol one from that client going to the outside. So to fix that, we'll go back to network and virtual routers, select our virtual router to edit it, go back to static routes and add back in the default static route. So we'll call it default via service provider A. We'll put in the syntax for default route. The egress interface is going to be one slash three that goes over to service provider A and service provider A's next top address is 23.1.2.1.

3:40And we'll click on OK. Then we'll click on OK again, and then we'll click on commit and then we'll confirm that commit. And then once it's done, we should then have a default route. And as a result, when the client goes up to one, one, one, one, it should have session information as well as log information based on the security policy rule hit that's doing logging. So all of that commit in the background. In the next video, I'd like to walk you through an example of another scenario where traffic is going, the data plane is working, but we still don't have logs. And that's because of intrazone traffic and some of the default policies that are in place on the Palo Alto.

4:14So I'll see you in the next video in just a moment.

0:00In this video, I'd like to give you a demonstration of intra-zone traffic and how we're not even expecting to see logs as a result. So let's talk about inter-zone versus intra-zone. So inter-zone, think of it like international between two zones, like traffic going between the inside and DMZ or traffic going between the inside and outside zones. Based on the interfaces involved from the routing decision and the zones, those interfaces are associated with. So inter is between, like international between two nations, inter-zone is between or going between two different zones.

0:35And what intra-zone is all about is routing between interfaces that are both members of the same zone. So as an example, I've got a Linux device here on the 10.12.0 network off of 1.2 and I have a Windows device down here off of the 1.1 interface on the 10.11.0 subnet. So if those two devices wanted to communicate with each other, the firewall is directly connected to both subnets. So it knows about those two networks. And because both interfaces are part of the same zone, there's a default security policy rule that says, hey, intra-zone traffic is permitted and it's not logged.

1:10So let me show you that rule first, then we'll confirm the IP addresses of these two devices and they'll do some pings back and forth or send some other traffic back and forth and then verify that they can communicate with each other based on the default intra-zone rule. So in the firewall, if we go to policies and on the left, we select security. Here are our rules that we made into out and into DMZ, our custom inter-zone rule that we're doing logging on, which is the main reason we created it. And then down here in the yellow, we have these two default rules.

1:40Now they only get matched on our hit if nothing else above them matches first. So if we have traffic that doesn't match any of these three rules that we currently see, it's then going to check out the intra-zone rule. And for this default intra-zone rule, it effectively says this, traffic that's trying to be routed between two interfaces in the same zone, go ahead and allow it. Also by default, there is no logging done whatsoever. So that traffic will happen and we'll see session information for that traffic. But what we won't see is log information.

2:10So what we could do is we could do an override and specify that we want to do logging there or we could create our own custom rule. However, I want to start with the two clients, the Linux and the Windows device on interfaces are reaching the firewall and interfaces in the same zone and verify that their traffic is allowed. So we will be able to see that in the session information. Although we won't, based on the logging being absent, we won't be able to see it in the traffic logs. So let's confirm the addresses of those devices. So to do that here on the Raspberry Pi, the Linux device, let's do an ifconfig for ethernet1 and its IP address is 10.12.0.101.

2:45We'll make a note of that. And that is assigned via DHCP. So we can also do a route-n, take a look at the routing table on this local device is default gateway is 10.12.0.51. That's fantastic. That's firewall A's interface 1.2 address. And then let's also take a look at the Windows computer. So this is the Windows computer was an IP config and it is 10.11.0.102. I'll make a note of that. So for IP addressing, this is at .101 on the 10.12.0 network and the Windows device is at .102 on the 10.11.0 network.

3:18And I've enabled IIS or web services here. So we should be able to go ahead and open up a webpage down to this PC right here. So we can first start with a ping, verify that works, then open a webpage for a session. So here at the Linux client, let's open up a browser. So I have some other tabs that are active. Just open up a new tab and let's go to 10.11.0.102, which is the IP address of that Windows 11 computer on the other subnet. We'll press enter and sure enough, that seems to be working. So with that in place, let's go take a look at our sessions. In fact, let me also go ahead and start a ping session just so we have some more traffic that'll be more consistent as well.

3:53So we'll do a ping to that same address and we'll just let that be a continuous ping. Fantastic. So back at the Palo Alto, if we go to monitor and let's go down to session browser and for the destination, I want to use 10.11.0.102. So I'm going to click on that to put that in as a filter and then activate that filter. So sure enough, we have protocol six, which is TCP, protocol one is ICMP. There's the applications being seen by the firewall. Fantastic. So those are the sessions that are currently in play. However, if we went to logs and traffic and looked at our traffic logs, we wouldn't see that traffic here.

4:25So all of this traffic is being sent out, one slash three out to the public internet. And the reason we're not seeing the traffic, in fact, let's go ahead and do a filter. On the destination, and I'm just going to go ahead and activate that. I'm going to plug in the IP address of 10.11.0.102, then activate that. And we have absolutely nothing. And that's because that traffic by the intra zone default rule is not being logged. So I wanted to point out that this is an example of where we aren't expecting logging because logging isn't part of the policy.

4:56However, we do have session information based on the session browser here because that traffic is actually flowing. And if we want to see our logs, we can go back to our policies and our security policy. We can either do an override for the default intra zone policy rule here, assuming it would let us by clicking override and specify we want to do logging, or we could create our own custom intra zone rule that does logging. And then we could see it in the logs as well. And because I'm having a little bit of a challenge with this version of the Pan OS, I'm going to go ahead and add a custom intra zone rule that will hit before we hit the default one.

5:30And that way we can do logging and make sure we're catching everything. So I'm going to click on rule number three, click on add. So I'm going to call this intra custom rule. And for the type, I'm going to say it's intra zone, fill in all the details, I'll go to source and I'm going to say any and destination is grayed out because it's an intra zone rule. And then the application and service are wide open and the action is going to go ahead and allow but I want to go ahead and do logging. So I'm going to do logging at start and at the end, and then click on OK. So now that's in position number four. So we'll click on commit and click on commit again.

6:00And once that's done, we have the same overall effect that intra zone traffic is going to be allowed. But now we'll have logging as a result so we can actually see it in the traffic logs as well. And just to confirm that, let me go ahead and let that finish in the background. Let's go back to our clients. So here's our Linux client, let me go ahead and close the browser. I'll stop the pings. And now that I've waited a moment or two, let me open up a command prompt here and let's go ahead and ping that same device so the pings are working. And let's also open up a browser and go to that IP address with HTTP.

6:33So we'll open up a new tab there. And we'll go to 10.11.0.112. And that is the wrong address. It's not 112. It's 102. So we're going to put the right address there 102, press enter. And there is our IIS. So back in the firewall, go to monitor and session browser and it is refreshing as shown right there. It should show that session information, which it does. There's web browsing and also some ping traffic. And now, because of the rule it's hitting, there's our intra custom rule shown right there that it's hitting as part of the session. So back in our monitor, if we now go to logs and traffic, and I'll leave that filter in for the destination address of 10.11.0.102, it's now showing the web browsing and ping traffic as well.

7:11Because now that rule, the intra custom rule that we made has logging enabled and that's why we're seeing it here in the logs.

0:01For this validation video to help reinforce our concepts that we've learned in this set of videos regarding routing, I've got a problem and I'd like your help in solving it. And here's the problem. This client, which earlier was able to go ahead and ping and access the web interface over here at this machine, this Windows client, that is no longer working. And so I have a few screenshots of the environment here at firewall A and I'd like you to help me identify from those screenshots what you think the problem is. And let me share with you the screenshots. For the first one, I have the routing table on our virtual router.

0:34So here is the routing table. I also have the forwarding table, the FIB, think of it like the winner's table regarding which routes will actually be used. I've got an image here of the policies. So here's our in to out, in to DMZ, the custom inter zone deny, and also the intra custom rule right there. Then here under monitor from the client at 10.12.0.1.01, them attempting to use, looks like HTTP with port 80 and protocol number six at layer four TCP going to that device.

1:05And what I'd like you to do is take those screenshots and collectively identify what you think the problem is that's causing this little Linux client to not be able to reach this device down here at 10.11.0.102. So go ahead and pause the video now, give that some thought. And when you're ready, go ahead and click on resume and we'll walk through this together. Let's take a look, first of all, at the routing. And we can look at this through the CLI or through the GUI here, either way is great.

1:35So let's go to network here on this firewall, go to virtual routers, go to more runtime stats, and let's take a look at the forwarding table right here. So we have a default route to service provider A, then we have a route to 10.12. That's great. And a route to 10.15.0 and a route to 23.12 and 24.12. But right off the bat here, what I'm not seeing is I don't see a route to the subnet where that client lives. Let's take a look at the topology. So here's our topology. This client is down on the 10.11.0 network, and I don't see a route for 10.11.0 on this firewall. Let's just go confirm that.

2:10So back at the forwarding table, yeah, I don't see 10.11.0 anything. So what would the firewall do if it had a packet destined for 10.11.0? Because there's no more specific route in the routing table, it would use this default route, and it would try to forward it out of interface 1 slash 3, which would not be good news because that subnetwork of 10.11.0, it doesn't exist off on the public internet out through our service provider, it's internal. So we have a routing issue here. So here is that Linux client. It is trying to go to 10.11.0.102. Click on reload, reload, reload. That's not happy, happy.

2:49So we'll minimize that, and let's refresh the session browser. And there is one of our hits right there for the destination 10.11.0.102. I'll click on that and activate that as a filter, and it looks like that may have timed out. So let me go ahead and try to reload that a couple times and click on refresh. So I just reloaded at the client. And so this traffic from our client at 10.12.0.1.01, that's our Linux device going to 10.11.0.102 to the well-known port of TCP 80, that is being forwarded out of 1 slash 3. And that's because it's using the default route. It doesn't have more specific route for 10.11. anything.

3:25So it's going to forward it out the default route out to service provider A. So this is absolutely a routing issue. So what the heck is going on? Where's our route to the 10.11 network? Well, if we go to network and we go to our interfaces, let's just confirm our interfaces addresses. So here we have 10.12. Oh, there we go. So that interface, the link state is down. And because it's down, that address space 10.11.0 with the 24-bit mask is not in the routing table. So I'm going to go ahead and bring that back up by going into the interface, going to advanced and here under link settings, instead of saying link state down, I'll go ahead and say auto, meaning you ought to be up.

4:02And we'll click on OK. And then we'll go ahead and click on commit and click on commit and let that finish. So I'm going to click on close there. That'll finish in the background. And let's take a peek at our Windows device. So here on the Windows computer, we'll open up a command prompt and we'll type in IP config and it still has the address 10.11.0.102. Fantastic. So while we're waiting, let's go ahead and do a test routing FIB lookup for that destination. So it currently says to get to that address is still using the egress interface of 1 slash 3 with the next top of 23.1.2.1, which basically means that the commit isn't yet done.

4:35So let's hang out here for a moment and just confirm the routing information before we do the testing. We can also do a show routing FIB just like that. Hit the spacebar and look at that. We do have that 10.12.0 network now available. Hit the up arrow key a couple of times that test is now routing out Ethernet 1 slash 1 for that given destination. So now that our routing is currently in place, let's go ahead and test again from the client. So here at the client, it wasn't working a moment ago, but we'll go ahead and reload. And now it is working.

5:05So now we should have session information showing the correct interfaces involved. So if we go back to the firewall and go to monitor and go to the session browser. Now we have that traffic from our client at 10.12.0.101. That's the Linux device going to the Windows device here. And the source interface is 1 slash 2 and the egress or outbound interface is 1 slash 1. And now because the routing is correct, it could be forwarded. And also because we have logging on that custom rule that we made, we should also look at the traffic logs. And I currently have that filter in place for 10.11.0.102.

5:35And here we have that log entry for the traffic that is now working, matching on that intracustom rule. And you'll notice the interfaces are now correct because the routing is now correct. So this is 100% a routing issue based on the route table. And then once that was solved by bringing that interface up, which added that route back into the routing table, then traffic was able to flow because previously it was attempting to use the default route going out of interface 1 slash 3. So thanks for joining me in this set of videos as we've taken a look at the traffic flow and forwarding logic on a Palo Alto firewall.

6:08And I look forward to seeing you, my friend, in the next set of videos very, very soon. Until then, I hope this has been informative and I'd like to thank you for viewing.