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

0:06on the forwarding and logic on a Palo Alto firewall, including if there's a problem or

0:11hiccup, how we can verify with evidence that what we think is happening is happening. Or if

0:16the routing issue, we can also identify what we would expect to see in absence of correct routing.

0:22So 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,

0:04I've got three zones. I've got the inside zone, which includes interface 1-1 and 1-2. I've got

0:10the outside zone, which includes interfaces 1-3 and 1-4. Then I've got this DMZ zone here,

0:16which includes interface 1-5. And DMZ here in yellow may be a little hard to read,

0:20so I'm going to go just below that, just jot down DMZ and point right there. Also on Firewall B,

0:25I've got 1-8.20, which is associated with the inside zone over there. And over on Firewall B,

0:31interface 1-8.25 and 1-8.26 are both associated with the outside zone on Firewall B. So I'll

0:37add those arrows as well, just for clarity there. And on the inside zone, these two interfaces here

0:43and over at Firewall B, just that one interface. So the logic and benefit of using zones on the

0:48Palo Alto Firewall and pretty much on most next generation firewalls is that we can set up our

0:52policy based on zones. So if we have a policy that says allow traffic, if it's sourced on an

0:58interface that's coming into the firewall on the inside zone, and from a layer three routing

1:03perspective, being forwarded out of an interface associated with the outside zone, then permit it

1:08or deny it or take some other action on it. So our security policies are going to include

1:12the 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

1:22matter what our policies say, like what's permitted or what's denied, if we don't have our layer three

1:28routing set up first. If it's not working correctly, our policy rules will never be hit.

1:33So as far as an order of operations, the routing is going to be decided first, then assuming we

1:38have routing in place, then we're going to go ahead and consider our policy. Because there's

1:42a temptation sometimes if the firewall is not working as expected to say, oh, let's go take a

1:47look at the policy and we can change and modify our policy. But if the routing isn't in place

1:51correctly, 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

1:59at the traffic flow and forwarding logic, I'd like you to think of every step along the way,

2:03what type of evidence do we have regarding a failure, for example, on the firewall?

2:07So as part of that evidence, the first thing we got to verify is the plausibility or the possibility

2:13from a routing perspective based on the routing table and firewall to actually forward the traffic.

2:17So can the firewall forward? And that's going to be based on its forwarding table,

2:21on its routing table. Now, if it's plausible based on the routing table that the firewall

2:25could forward a packet, for example, from this user out to the public internet,

2:29the 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,

2:38just to verify whether or not there's a session present. And then the third piece that we could

2:41use is the logging. And on the Palo Alto firewall, we'd go to monitor, logs, and then go to the

2:46traffic logs and just see whether or not there's a log entry for the session. And if we see a logging

2:52entry in the logs, that proves that a policy was hit. And then that policy would have been the

2:57factor regarding was it permitted or denied as far as the traffic coming from the client

3:02out to the server. So for the logging, I just say, is it there? Is it logged? And if we don't have

3:06these two elements, for example, there's no session information and there's no logging,

3:11it'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

3:20the direction of where the problem is. Now there's also a consideration that we'll look at together

3:24in the set of videos where we have a flow of traffic and yet it's not showing up in any logs.

3:29So if we have session information, however, we don't have the logging information. One of the

3:34reasons for that could be the security policy rule that it matched on is not logging. There's

3:39no logging action or it's hitting a default rule that doesn't have logging. And so we'll experience

3:45both of those scenarios as we go through these videos together. So let me clean it up a little

3:49bit and let's chat about some other things that could go wrong. Let's imagine that in our security

3:53policy, the policy says if traffic is sourced on an interface on the firewall, meaning it's coming

3:59into the firewall on an interface associated with the inside zone and a fancy way of saying that

4:03traffic coming in would be ingress traffic. If it's coming in on the inside zone, again,

4:08that 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

4:17that's associated with the outside zone, an example of that from a routing perspective would

4:21be routing it out 1 slash 4 or 1 slash 3, which are both associated with the outside zone. In the

4:26policy, go ahead and say, if that's the case, go ahead and allow the traffic. So allow is another

4:31way of saying permit or go ahead and forward. And a security policy can also have many other

4:36considerations, including the actual source IP address or the range or the applications being

4:41used 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

4:50zone, being routed out of an interface on the outside zone, please allow it. As far as the data

4:54plane is concerned, that's enough to get it to go. Now, also to get out to the public internet,

4:58if this client is trying to go out to the internet, we'd also need some address translation

5:01rules here as well. So in this set of videos, we're going to focus primarily on the traffic

5:06flow and forwarding logic. And in other sets of videos, we'll focus on things like address

5:10translation and additional security policy tweaks and SSL inspection and so forth. But for now,

5:15we're focusing just on the traffic flow and forwarding logic. Let's imagine our traffic

5:19gets out to the public internet. So here's the server the client's going to. And the question

5:23is, if everything is working as it should, the client goes out to that server, the server responds,

5:28comes 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

5:37is bi-directional communications. So if we are successfully able to go out, but the actual return

5:42path isn't in place, or we have asymmetrical routing where the reply traffic is coming back

5:47through another path, those also could cause hiccups or issues or problems on a firewall

5:52that isn't able to see both sides of the conversation. Because these firewalls are

5:55stateful in nature, meaning if we have allowed in our security policy rule, the initial flow of

6:00traffic from this client going out to the server, dynamically, that reply traffic should be allowed,

6:06assuming that reply comes back through the same firewall. Now, one element that's important to

6:11be aware of as we look at and troubleshoot as we go through this together is when we make changes,

6:16or we're doing testing, focusing on just one item at a time. And that is really important,

6:22because if we change three or four things, we might not know, if it starts working all of a

6:26sudden, we may not know exactly which component is now causing it to work. And as a result,

6:32we won't really know why it was broken. And as I mentioned, if we are troubleshooting and we're

6:36looking 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

6:44enabled, or it never hit a security policy rule, which once again, would point back to routing.

6:49So as we focus on traffic flow and forwarding logic, here's a few items I'd like to put on the

6:53table for later sets of videos. Things like network address translation, policy tuning,

6:58app ID, or identity services. Those are all extremely important as well. However, in our

7:04focus on traffic flow and forwarding logic, I'm going to go ahead and punt those to other videos

7:08and other skills where we'll focus on those in depth. And one other element I just want to share

7:12with you as we jump in to looking at the traffic flow and forwarding logic. When we're doing

7:16logging our security policy rules, there's options of saying when we want to log the traffic. At the

7:21start, for example, the start of the session, or at the end, we can also do both. And from the logs

7:26that are created, I'll also walk you through how we can identify a log, whether it was created based

7:30on a start or end action in the security policy rule as well. So with that in mind, in the next

7:36video, I'd like to walk you through the forwarding decision chain that the Palo Alto firewall goes

7:40through when it receives a packet and is making a decision on how to forward. So I'll see you in the

7:45next video in just a moment.

0:00When we're troubleshooting forwarding on a Palo Alto firewall, we need a consistent story

0:05that we can retell and explain quickly. Or if we're not explaining it to someone else,

0:09we also need a story in our own mind that we can go through as we troubleshoot the routing.

0:14So here's the story. Once upon a time, there was traffic that was coming into the firewall.

0:19Meaning, for example, this client has a default gateway. It's 10.12.0.51. The client is trying

0:26to 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

0:38of forwarding that packet. So when that traffic comes in, it's coming into the firewall on an

0:42interface. And that's referred to as the ingress or incoming interface. So I'll write down there,

0:47inbound. Now on the interface where it was received, that interface is associated with a

0:52zone. So in our case, when this device sends a frame of data into the firewall, it's coming in

0:57on 1.2. 1.2 is associated with the inside zone. So from the firewall's perspective, in the context

1:03of this interface in that zone, that ingress packet is coming into the firewall on the inside

1:09zone. 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,

1:19we're talking about layer three routing. And that applies to IPv4 as well as IPv6. And by default,

1:24we only have one VR, one virtual router. However, it has the capability of having multiple virtual

1:31routers. And depending on which interfaces are associated and assigned to that virtual router,

1:36that also is going to have an effect because each virtual router has its own routing and

1:40forwarding table. So in our case, we have one virtual router to deal with. So we're looking

1:44at the routes within that virtual router. Then as part of step number two here and the

1:48virtual router, it's going to do what routers do. And that is they're going to look at the

1:52destination address. So if this client is going out to 8.8.8.8, the firewall and its virtual

1:58router is going to consider the routing table to find out what is the best route it has to reach

2:04that destination IP address. Let's imagine the firewall and its virtual router have five

2:08directly connected networks, which does the 1011, 1012, 1015, and also the server spreader

2:14A23.12 and server spreader B24.12. So that's five directly connected networks. And then a default

2:20route like this for IPv4 that says the next hop is server spreader A at 23.1.2.1. So in that case,

2:28we'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

2:38wasn't more explicitly matched in the routing table. And based on that default route with next

2:42hop, it then is going to choose the egress or outbound interface. And that's step number three.

2:47So the egress interface the firewall is going to use based on its default route to reach 23.1.2.1,

2:52that's the next hop, is going to be this interface right here based on the static route that it

2:56currently has using server spreader A as its default route. So in that case, the egress

3:01interface here would be 1 slash 3. So over here on the ingress, let me make a note that's 1 slash

3:062, that's the interface. And over here, it's 1 slash 3. And then 1 slash 3, as we discussed in

3:10the 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

3:20decision, we haven't even yet gotten to the policy consideration because the routing first regarding

3:26the inside zone, going to the outside zone, with that information in mind, it then can take a look

3:31at the actual security policy rules to see whether or not that traffic is allowed or not. Because if

3:35we never got through the routing part, for example, it couldn't determine the egress interface to use,

3:40it wouldn't even bother in considering or consulting the actual security policy. And that's

3:45why layer three routing is way before and first compared to the actual security policy rules. So

3:51think of the security policy as something that's being processed after the layer three routing has

3:55been established. Now, one other thing to be aware of is that not every route is correct. For example,

4:01we may have a route that is pointing to the wrong next top address, it's not reachable,

4:05or we may have a next top that's not working itself and not able to forward. But if we had

4:09a situation where the service provider A, for example, could not forward traffic, we would still

4:14have made our routing decision. And as far as the flow of traffic, the initial flow would go through

4:18the firewall. So we should have session table information there for the initial one-way flow,

4:22trying to go out. And if we're doing logging on the security policy rule that allows that traffic,

4:26we should also have log entries as well that would show up here at the firewall. So let me make a

4:30little 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,

4:40a service provider, we'd still have our session information and our logging. Whereas if we didn't

4:45have a default route at all, we wouldn't expect to see session information. And we also would not

4:49expect to see logging information. So to reinforce this concept, let's do a quick demo. Let's go over

4:54to this Raspberry Pi who currently is using firewall A as its default gateway. And let's

4:59send some traffic out to the public internet. I've included as part of the skill, a copy of this

5:04topology. I would encourage you to have it ready and able to see either print it out or put it on

5:08a separate screen. So as we're doing the configuration, the demonstrations, you have a

5:13comfort level with exactly where devices are. So this is our Linux device right here on the 10.12.0

5:18network that we're about to look at. So the first thing I'd like to do is confirm that we're on the

5:22right device. So let's go up to a command prompt and let's do an ifconfig or ethernet1, which is

5:26the lab interface. And it has the IP address 10.12.0.101. And prior to sending traffic out,

5:33let's just take a look at the routing table on firewall A. So here's firewall A. To look at the

5:38routing table, we'd go to the network tab up here. And on the left-hand side, we click on virtual

5:42routers right there. And then we have a more runtime stats right over here. So we'll click

5:47on 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

5:57example, 1.1.1.1, which is a CloudFlare address, the firewalls is making a routing decision. It's

6:03going to take a look at all the routes and it doesn't have a more exact route for the one anything.

6:08So it default to the default route right here and use the next hop of 23.1.2.1, which is going out

6:14through service provider A. Now behind the scenes, what's allowing that to happen once the routing

6:19decision is being made is the security policy. So for policy, we go to policy and on the left,

6:25we'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

6:33inside zone and that traffic from a routing perspective that we just looked at is going

6:38to be routed out of an interface associated with the outside zone. And then this is wide open,

6:42any application, any port, any service, the action is going to go ahead and be allow. You don't in

6:48production need the log at the start and at the end. I'm going to enable both of them. They're

6:52both enabled right here. And I'll also show you in the logs how we can identify whether it was a

6:57start or end log entry that we're looking at. Effectively for working sessions, we're going to

7:02have twice as many logs compared to just clicking on one of those versus the other. So I'm going to

7:07use both of them. And just as a side, I also have a NAT rule set up for address translation. So it'll

7:13actually function. Again, our focus here is on the routing and again, the routings that are network

7:18virtual routers. We have one virtual router. And before we bring up our client, let's do a couple

7:23things. Let me close that. So let's go to monitor and with monitor selected, let's go to session

7:27browser. And this is showing us the current sessions I have in place. Let me click right here

7:32and adjust columns. And based on these log entries, this is traffic coming in to the

7:37firewall on one slash one, which is from another client. And the Linux client is coming in on

7:42one 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

7:51monitor. It went to logs and expanded that and went to traffic logs. This will also show us the

7:56log based on the security policy rule that's doing the logging. All right. With that in mind,

8:00let's go to our client. All right. So here's our client. Let's start off with a ping out to

8:058.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.

8:12That's working. Great, great, great. We'll do a control C there and we'll open up a browser and

8:16I'll have a whole bunch of tabs that automatically are coming up here, including a speed test,

8:20which is shown right here. Also some YouTube traffic, which is shown right here. And also

8:26a open tab to Palo Alto, which is shown right here. And I'll leave that open. So because that's

8:32all working, the routing decision was made. The security policy was considered. It allowed that

8:38traffic. 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

8:46browser. And here in the session browser, you'll notice we have a whole bunch of session information

8:51here 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

8:56filter. We'll click on the arrow and that'll show us only traffic sourced from 10.12.0.101. So I'm

9:02going to go ahead and use the down arrow, adjust columns. And we can also add or remove columns as

9:07well that we want to see or not see. So this is showing from inside to outside zone wise. We could

9:11also add the ingress and egress interfaces. So let's go to columns. Oh, and they're already enabled

9:17right there. Ingress and egress. I just wasn't looking hard enough. So let me take the ingress

9:20interface and you bring that over here and I'll take the egress or outbound interface and drag it

9:24over 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

9:34belongs to the inside zone and ethernet 1 slash 3, the egress interface belongs to the outside zone.

9:39Then we have source IP, destination IP, et cetera, et cetera, et cetera. So that's the session browser.

9:43We can also see that from the command line. So here's the command show session all. You can press

9:48enter to go one line at a time or space do one page at a time. So we have quite a few sessions.

9:53And these are the same sessions that we saw in the GUI. So if we scroll up, there's our command

9:57show session all. Here's the source IP address and source port that came into the firewall in the

10:02inside zone. And the destination was this IP address and this port and the egress zone was

10:07this zone. And here's the application that was being used. So we have quick, very likely that

10:12was 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,

10:21go to monitor and under logs, go to traffic logs. So here in the type, it's specifying the type of

10:26log. So if it started logging at the start of the session, it says start here and end represents the

10:30end. So if you don't want to see that column or don't need it, you can go ahead and just go to

10:34columns and say, you know what, we don't need to see that and simply remove it. I've also taken

10:37the liberty of adding a few additional columns here just for educational purposes. So here's

10:41the source IP address. We can also put a filter here by clicking there and clicking on go to

10:46activate that filter. And that way it's only going to show us where 10.12.01 is the source

10:51address. 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

10:59zones to be used, which once again points to the fact that routing is working because security

11:04policies were then considered and we have sessions and logging information as a result. Now, when it

11:09comes to routing, if we go back to network and go to virtual routers, we'll go to the more runtime

11:14stats for our virtual router and we look at the routing table. In the next video, I'd like to

11:17focus our attention on the logic on the Palo Alto firewall regarding how it decides what is the

11:23quote unquote best IP route to use for a given destination. So we'll cover that in the next video

11:28and 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

0:05and come up with a really good way to understand best. Because at the end of the day,

0:10when the router, or in this case, firewall, firewall A is making a decision about how to

0:15forward a packet, which egress interface it's going to use, it's going to choose the quote

0:19unquote best route. And when it comes to the concept of best, let's use an analogy. Let's

0:23say we have some advice that's coming in from two different people, from person one and also

0:27from person two. So let's say person one, let's say it's about investing. And they say, you know

0:32what? It's a good idea to invest. And that's all they say. And it's very vague. And over here,

0:39somebody says, well, I've had 20, 30 years experience in this business. And I think you

0:44should go ahead and buy these specific kinds of index funds and you should hold them for a period

0:48of 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,

0:59which of those two would be the quote unquote best advice? And the answer is the one that's

1:04more specific. And when it comes to routing on the Palo Alto firewall, it's just like that as well.

1:09If it has a bunch of routes that it could use in its routing table, it's going to choose the

1:13best route, which is the one that's most specific. So let's narrow that down a little bit and talk

1:18about what does that mean more specific? Let's take this routing table here on the firewall,

1:22firewall A. It has a directly connected network for 10.11 with a 24-bit mask. It is directly

1:29connected to this network here, 10.12.0. So that's in the routing table because it's directly

1:33connected. It's got the DMZ of 10.15.0.0. That's in the routing table. And it's there because we

1:39configure 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.

1:49It also has a directly connected network of 23.1.2.0 with a 24-bit mask going through service

1:54provider A and also through service provider B with 24.1.2.0.24. And then we also have on this

2:02firewall, a default route that says this for IPv4. Effectively, if none of the other routes match,

2:10go ahead and use the default route, which has the next top of 23.1.2.1. Now, as far as best is

2:15concerned, let's imagine this client is trying to do a ping out to Cloudflare at 1.1.1.1. So that

2:21packet comes into the firewall on interface 1.2, which is part of the inside zone. And the firewall

2:27is looking at the destination address. It is considering its routing table. It doesn't match

2:32these three octets. It doesn't match these three or these three or these three. The destination

2:37here 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.

2:44However, let's add some more static routes. So this is a static route, and let's add two more,

2:50just 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

2:59the 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

3:07with the 16-bit match, the first two octets effectively, that the next top is going to be,

3:11let's say, this server, which wouldn't be a real good decision. But just for demonstration purposes,

3:17let's say that 10.15.0.100 is the next top, which would imply setting out this interface

3:25in that direction, which, by the way, wouldn't work for getting to Cloudflare, but this is just

3:30an example. So now, once we have these static routes configured, and we click on commit,

3:35and we let that commit complete, then when the client pings 1.1.1.1, the firewall, as it

3:41receives that packet on 1.2, it now considers the destination and its routing table, and the default

3:47route is no longer the best match, because there's two routes that are even more specific. This one

3:52right 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

4:03the longest match from the routing table, and as a result, that's the longest match. We're matching

4:07on the first 16 bits, and that's the one the firewall is going to choose from its routing

4:11table. Now, unfortunately, based on the next top, the firewall is going to forward it up here

4:16to this poor server at .100, who says, I don't know what to do with that. In any event,

4:21that's how it makes its decisions. So if it's wrong or incorrect, that's going to cause the

4:24traffic to go the wrong direction. Now, the cool thing is, in the logs, if traffic really is being

4:28routed, for example, out interface 1 slash 5 here, that's great to know in the logs, because

4:33then we can go back and take a look at the routing table, and we can ask ourselves the question,

4:38why did the firewall choose to forward in that direction, out interface 1 slash 5, and go back

4:43to 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

4:51the traffic. The firewall is just using what it knows about, based on what it's learned, either

4:56through static routes or dynamic routing protocols, or what it's directly connected to,

5:00to make its routing decisions. And again, it's based on the longest match, looking at the packet

5:04coming in, which route in its routing table matches the most bits of that from left to right,

5:09and it's going to use that route to make its routing decision. So I thought what would be fun

5:14is to go ahead and demonstrate this in action. So currently, we have our default static route

5:19going through service provider A, but we don't yet have these two static routes for the 1.000

5:25and the 1.100, 8 and 16 bits, respectively. So what I'd like to do is, before we create those

5:31new static routes, let's take a look at the routing information, both at the GUI and the

5:36CLI for this firewall, before we add these static routes, and then we'll add the static routes,

5:41and then compare and contrast the difference. So let's first start at the Raspberry Pi,

5:45and 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

5:52a trace route out to 1.1.1.1. Let me also do a dash n for don't bother doing name resolution to

5:581.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

6:08first hop in the path. And then the next hop based on the routing table should be 23.1.2.1,

6:14which is through service provider A. So there's that next hop 23.1.2.1. And then it's looping

6:20back through my home office network here, and then off to my service provider after doing some

6:25additional NAT there, and then onward and upward till it finally got to its final destination.

6:30And here we're timed out. We had some devices that weren't responding with the

6:33ICP messages indicating that the time to live had exceeded. So here's the firewall. If we

6:38want to look at the routing table, we could do a show routing route. So there's our command right

6:43here, show routing route, and that's showing us the routing table. But that's not the winners

6:48table. The winner's table is the FIB, the forwarding information base. And the command

6:52to 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

7:01virtual router right there. There's the five interfaces that are allocated and part of that

7:06virtual router. And here's the route table. So here are the flags. We scroll down. Here are the

7:11routes. So here we have our default route with the next hop of service provider A and the egress

7:16interface to reach that next hop is Ethernet 1 slash 3. Then we have the 10.11.0 network and the

7:2210.12.0 network and the 10.15.0 network. It's also including some host routes as well. This little

7:28H right here effectively is a 32-bit route for the actual interface itself. And then for the

7:33service 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

7:43in the GUI, we'd go to network. On the left, we'd go to virtual routers. And then with our virtual

7:47router here on the far right, we'd click on more runtime stats. So we'll click on more runtime stats.

7:53And then here's the routing table. If we click on forwarding table, here's the forwarding table right

7:56here. So if we want to look for a specific route, let's say we had thousands of routes, we could

8:00just go ahead and put in, for example, 10.11.0.0 with a 24-bit mask, press enter, and it would

8:07filter and show us that specific route. Where it says next hop is 0.0.0.0, that implies that we are

8:13directly connected to that network through Ethernet 1.1. If you want to look for the 12 network,

8:18we go ahead and change that to a 12, press enter, and then it shows us that that's reachable out

8:23Ethernet 1.3 for that directly connected network. Or if I look for the default route, 0.0.0.0.0,

8:29and press enter, and that will show us our default route. We can do the same type of filtering here

8:32in the route table. And that way, if we had routes, even ones that were not actively being used,

8:36they would show up right here. So again, the forwarding table is like the meat and potatoes

8:40regarding what the firewall is actually using to make forwarding decisions. So when the client was

8:45sending packets to 1.1.1.1, it didn't have a better match on any of the routes, and so it used the

8:50default 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,

8:59virtual router, the name of your virtual router, and then the IP you want to test,

9:03and that's going to show us how it would forward based on the current routing table.

9:07So here's the destination. So the next hop would be 23.1.2.1,

9:11the 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.

0:08And let's do it based on our plan, what we walked through earlier with the whiteboard here.

0:11Let'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,

0:20and 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

0:50static routes to our default virtual router we'll go to network on the left

0:53we'll click on virtual routers and then here on our virtual router we'll click on

0:57it to edit it and then we'll go down to static routes

1:00so currently we have our default static route going through service provider a

1:03at the next top of 23.1.2.1 with an egress or outbound interface we're

1:07using of 1.3 so we'll click on add so i'm going to call this 1.0.0.8 bit

1:12that's just the title the name of it and then for the route itself it'll be

1:151.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.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

11:20browser right there, you notice we have these pings right here that are going out.

11:24Protocol number one from one slash two, that's where our client is, and the egress interface

11:29is one slash five.

11:30There's no response coming back, but we have session information and also we should have

11:34logging information because the rule permitting that is also set up for logging.

11:38So right here on monitor on the left-hand side, we go to traffic logs.

11:41Here we have our ping packets right here.

11:43So from the inside to the DMZ, ingress interface one slash two, egress interface one slash

11:48five.

11:49And just as a quick confirmation, if we went back to network and went back to our virtual

11:53router and then we edited our virtual router, and I'm going to go back to static routes,

11:57let's remove this one right here.

12:00So go ahead and take this 16-bit route.

12:02We'll delete that.

12:03So now we have just a eight-bit route, which is more specific for one, one, one, one than

12:07the default route.

12:08We'll click on okay.

12:09We'll click on commit and then commit again.

12:12Now if the client tries to ping one, one, one, one, the best route, the longest match

12:16route for one, one, one, one is this eight-bit route with the next top of 24.1.2.1 going

12:21out interface one slash four.

12:23Now in theory, that should all be well and good.

12:26However, there isn't a NAT policy associated with one slash four.

12:29So because address translation isn't there, it's going to cause a failure for that traffic

12:34to actually get back to the client because it'll be trying to source it from a 10.12.0

12:38address space and to service provider B at the moment, based on our rules here, we're

12:41not doing that.

12:42However, we should be able to see it in the logs because into out is allowed and we can

12:47also confirm the routing decision is going to make by looking at the routing table on

12:51the firewall that when we try to reach one dot one dot one dot one, the next top would

12:55be 24.1.2 in the absence of that more specific route, the 16-bit one.

13:00So I think that commit is about done.

13:01So let's go back and take a look at the routing table.

13:04Back at the GUI, one way of looking at the routing table is to go to our virtual router

13:07under network, virtual routers, more runtime stats, and then click on the forwarding table.

13:12And sure enough, our longest match now for one, one, one, one is going out through interface

13:17one slash four is our egress interface with the next top of 24.1.2.1.

13:21We can also confirm that here at the command line by using the up arrow key.

13:25And 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

13:34working now isn't from our security policy, but it's a NAT issue.

13:39So if we go back to the GUI and go to monitor and go to our session browser, here we have

13:44our ping attempt from 10.12.0.1.0.1 trying to go out to 1.1.1.1.

13:50And here it's also showing us the egress interface that we're using one slash four.

13:54And that's based on the routing decision.

13:56And because we're doing logging, we can also go back to logs and traffic.

13:59And 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

14:09the outside zone.

14:10So that ping is being allowed.

14:12However, there's no response coming back because we're lacking address translation on that

14:17second service provider or traffic going to and through that second service provider.

14:21So because I don't want to leave this broken, I'm going to go back to network, virtual routers,

14:25go back to our virtual router, go to static routes and delete that one.

14:29And 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

14:39because 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

0:04and no log.

0:06Although we have seen that once when we had a situation where the default policy rule

0:11was denying the traffic and that was the traffic originally between the inside and the DMZ

0:16and it's not logging by default.

0:18So outside of that, another reason why we'd have no session, no log is just on the fact

0:22that the firewall itself doesn't have routing in place, meaning when it gets a packet for

0:27a given destination, it's not sure how to reach it.

0:29Now to demonstrate that, I'd like to have this client go out to 1.1.1.1 again, we'll

0:33just do a simple ping to take a look at that and if the routing is messed up on the firewall

0:39where it can't route or forward at all, there will be no session information and there will

0:43be 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,

0:52take a look for sessions, take a look at the logs to verify they aren't there, then we'll

0:56correct the routing problem, do it again, and then confirm that we have session information

1:01and logs based on how our security policy is set up.

1:03So here at the client, let's confirm our IP address for Ethernet1, so we're at 10.12.0.1.0.1

1:09and let's do a ping out to 1.1.1.1.

1:12So that ping is continually trying to happen in the background, we'll do a control C, yeah,

1:17sent five of those, we'll go ahead and just let that run continuously here on this Linux

1:20device.

1:21And let's go take a look at the firewall.

1:22In fact, we can do it right here from the CLI.

1:24So here's the firewall, let's do a show routing fib, and this is the forwarding information

1:28base and there's effectively the routing table that's being used.

1:31And what I don't see here is I don't see a default route.

1:34And as a result, if the client is sending a packet into the firewall with the destination

1:38of 1.anything, there's no default route or any detailed route at all for 1.anything.

1:44And as a result, what we should see, or we should not see, is we shouldn't see any session

1:48information for this as well as we should also not see any log information because it

1:53never got that far because it's a routing issue that never allowed the policy even to

1:57make a decision.

1:58So we can do a test, the one we did before, test routing fib lookup, the virtual router,

2:02the name of a virtual router, IP 1111.

2:04And here it's showing us route not found, which means I can't get there from here.

2:09So if we minimize that and we go back to the firewall, go to network and virtual routers,

2:13more runtime stats, they'll tell us the same story.

2:15If we look at the forwarding table, there's no default route here.

2:18And as a result, it doesn't know how to forward out to 1111.

2:21So we'll close that.

2:22And let's take a look at sessions.

2:24So if we go to monitor, then we'll go down to the session browser right here on the left.

2:28Currently, there's some traffic involving protocol six, which is TCP, but there's no

2:32ICMP at all.

2:34So no session for the ping traffic.

2:36And if we go to the traffic logs, but notice here, there's also no ICMP traffic from our

2:42client at 10.12.0.101.

2:45And these are all old logs.

2:46In fact, let me go ahead and clear those out.

2:48On the Palo Alto from the CLI, clear log traffic, hit Y for yes, it'll delete all the

2:53traffic logs.

2:54Then if we go back to our client and I'll stop the ping, I'll restart the ping.

2:59And again, it won't show up in session information.

3:01And also it won't show up as logs because it never got that far to even hit a security

3:06policy rule.

3:07So back here under monitor logs traffic, we'll click on refresh and it is squeaky clean.

3:12And in our session browser, once again, no new traffic with ICMP protocol one from that

3:18client going to the outside.

3:20So to fix that, we'll go back to network and virtual routers, select our virtual router

3:24to edit it, go back to static routes and add back in the default static route.

3:27So we'll call it default via service provider A. We'll put in the syntax for default route.

3:32The egress interface is going to be one slash three that goes over to service provider A

3:36and service provider A's next top address is 23.1.2.1.

3:40And we'll click on OK.

3:41Then we'll click on OK again, and then we'll click on commit and then we'll confirm that

3:45commit.

3:46And then once it's done, we should then have a default route.

3:48And as a result, when the client goes up to one, one, one, one, it should have session

3:52information as well as log information based on the security policy rule hit that's doing

3:57logging.

3:58So all of that commit in the background.

3:59In the next video, I'd like to walk you through an example of another scenario where traffic

4:04is going, the data plane is working, but we still don't have logs.

4:08And that's because of intrazone traffic and some of the default policies that are in place

4:13on 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

0:05expecting to see logs as a result.

0:07So let's talk about inter-zone versus intra-zone.

0:11So inter-zone, think of it like international between two zones, like traffic going between

0:17the inside and DMZ or traffic going between the inside and outside zones.

0:22Based on the interfaces involved from the routing decision and the zones, those interfaces

0:26are associated with.

0:27So inter is between, like international between two nations, inter-zone is between or going

0:33between two different zones.

0:35And what intra-zone is all about is routing between interfaces that are both members of

0:40the same zone.

0:41So as an example, I've got a Linux device here on the 10.12.0 network off of 1.2 and

0:46I have a Windows device down here off of the 1.1 interface on the 10.11.0 subnet.

0:52So if those two devices wanted to communicate with each other, the firewall is directly

0:55connected to both subnets.

0:57So it knows about those two networks.

0:59And because both interfaces are part of the same zone, there's a default security policy

1:04rule 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

1:14and they'll do some pings back and forth or send some other traffic back and forth and

1:18then verify that they can communicate with each other based on the default intra-zone

1:23rule.

1:24So in the firewall, if we go to policies and on the left, we select security.

1:28Here are our rules that we made into out and into DMZ, our custom inter-zone rule that

1:34we're doing logging on, which is the main reason we created it.

1:37And 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.

1:43So if we have traffic that doesn't match any of these three rules that we currently see,

1:47it's then going to check out the intra-zone rule.

1:50And for this default intra-zone rule, it effectively says this, traffic that's trying

1:54to be routed between two interfaces in the same zone, go ahead and allow it.

1:59Also by default, there is no logging done whatsoever.

2:03So that traffic will happen and we'll see session information for that traffic.

2:08But 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

2:15or we could create our own custom rule.

2:17However, I want to start with the two clients, the Linux and the Windows device on interfaces

2:21are reaching the firewall and interfaces in the same zone and verify that their traffic

2:25is allowed.

2:26So we will be able to see that in the session information.

2:28Although we won't, based on the logging being absent, we won't be able to see it in the

2:32traffic logs.

2:33So let's confirm the addresses of those devices.

2:35So to do that here on the Raspberry Pi, the Linux device, let's do an ifconfig for ethernet1

2:41and its IP address is 10.12.0.101.

2:45We'll make a note of that.

2:46And that is assigned via DHCP.

2:47So we can also do a route-n, take a look at the routing table on this local device is

2:52default gateway is 10.12.0.51.

2:55That's fantastic.

2:56That's firewall A's interface 1.2 address.

2:59And then let's also take a look at the Windows computer.

3:02So this is the Windows computer was an IP config and it is 10.11.0.102.

3:09I'll make a note of that.

3:10So for IP addressing, this is at .101 on the 10.12.0 network and the Windows device is

3:15at .102 on the 10.11.0 network.

3:18And I've enabled IIS or web services here.

3:21So we should be able to go ahead and open up a webpage down to this PC right here.

3:26So we can first start with a ping, verify that works, then open a webpage for a session.

3:30So here at the Linux client, let's open up a browser.

3:32So I have some other tabs that are active.

3:34Just open up a new tab and let's go to 10.11.0.102, which is the IP address of that Windows 11

3:41computer on the other subnet.

3:43We'll press enter and sure enough, that seems to be working.

3:46So with that in place, let's go take a look at our sessions.

3:48In fact, let me also go ahead and start a ping session just so we have some more traffic

3:52that'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.

3:57Fantastic.

3:58So back at the Palo Alto, if we go to monitor and let's go down to session browser and for

4:02the destination, I want to use 10.11.0.102.

4:06So I'm going to click on that to put that in as a filter and then activate that filter.

4:11So sure enough, we have protocol six, which is TCP, protocol one is ICMP.

4:15There's the applications being seen by the firewall.

4:17Fantastic.

4:18So those are the sessions that are currently in play.

4:20However, if we went to logs and traffic and looked at our traffic logs, we wouldn't see

4:24that traffic here.

4:25So all of this traffic is being sent out, one slash three out to the public internet.

4:29And the reason we're not seeing the traffic, in fact, let's go ahead and do a filter.

4:33On the destination, and I'm just going to go ahead and activate that.

4:36I'm going to plug in the IP address of 10.11.0.102, then activate that.

4:42And we have absolutely nothing.

4:44And that's because that traffic by the intra zone default rule is not being logged.

4:50So I wanted to point out that this is an example of where we aren't expecting logging because

4:54logging isn't part of the policy.

4:56However, we do have session information based on the session browser here because that traffic

5:00is actually flowing.

5:01And if we want to see our logs, we can go back to our policies and our security policy.

5:05We can either do an override for the default intra zone policy rule here, assuming it would

5:11let us by clicking override and specify we want to do logging, or we could create our

5:14own custom intra zone rule that does logging.

5:18And then we could see it in the logs as well.

5:20And because I'm having a little bit of a challenge with this version of the Pan OS, I'm going

5:24to 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.

5:33So I'm going to click on rule number three, click on add.

5:35So I'm going to call this intra custom rule.

5:37And for the type, I'm going to say it's intra zone, fill in all the details, I'll go to

5:41source and I'm going to say any and destination is grayed out because it's an intra zone rule.

5:46And then the application and service are wide open and the action is going to go ahead and

5:50allow but I want to go ahead and do logging.

5:53So I'm going to do logging at start and at the end, and then click on OK.

5:56So now that's in position number four.

5:58So 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

6:05be allowed.

6:06But now we'll have logging as a result so we can actually see it in the traffic logs

6:10as well.

6:11And just to confirm that, let me go ahead and let that finish in the background.

6:14Let's go back to our clients.

6:16So here's our Linux client, let me go ahead and close the browser.

6:20I'll stop the pings.

6:21And now that I've waited a moment or two, let me open up a command prompt here and let's

6:25go ahead and ping that same device so the pings are working.

6:28And 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.

6:34And we'll go to 10.11.0.112.

6:38And that is the wrong address.

6:39It's not 112.

6:40It's 102.

6:41So we're going to put the right address there 102, press enter.

6:45And there is our IIS.

6:46So back in the firewall, go to monitor and session browser and it is refreshing as shown

6:51right there.

6:52It should show that session information, which it does.

6:53There's web browsing and also some ping traffic.

6:56And now, because of the rule it's hitting, there's our intra custom rule shown right

7:00there that it's hitting as part of the session.

7:02So back in our monitor, if we now go to logs and traffic, and I'll leave that filter in

7:05for the destination address of 10.11.0.102, it's now showing the web browsing and ping

7:10traffic as well.

7:11Because now that rule, the intra custom rule that we made has logging enabled and that's

7:15why 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.

0:10And 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.

0:20And 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.

0:28And 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.

0:43I'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.

0:51Then 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.

1:17So 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.

1:28Let'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.

1:43So 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.

1:53But 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.

2:02So 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?

2:21Because 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,

2:29which 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.

2:39So 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.

2:57I'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.

3:05So 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,

3:17that 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.

3:31So 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.

3:41So 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.

3:51So 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.

4:07So I'm going to click on close there. That'll finish in the background. And let's take a peek at our Windows device.

4:13So 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.

4:21So while we're waiting, let's go ahead and do a test routing FIB lookup for that destination.

4:25So 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.

4:41We 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.

4:50Hit the up arrow key a couple of times that test is now routing out Ethernet 1 slash 1 for that given destination.

4:55So now that our routing is currently in place, let's go ahead and test again from the client.

5:00So 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.

5:08So if we go back to the firewall and go to monitor and go to the session browser.

5:13Now we have that traffic from our client at 10.12.0.101. That's the Linux device going to the Windows device here.

5:19And the source interface is 1 slash 2 and the egress or outbound interface is 1 slash 1.

5:24And now because the routing is correct, it could be forwarded.

5:27And also because we have logging on that custom rule that we made, we should also look at the traffic logs.

5:32And 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.

5:41And you'll notice the interfaces are now correct because the routing is now correct.

5:45So this is 100% a routing issue based on the route table.

5:49And then once that was solved by bringing that interface up, which added that route back into the routing table,

5:54then traffic was able to flow because previously it was attempting to use the default route going out of interface 1 slash 3.

6:01So 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.

6:12Until then, I hope this has been informative and I'd like to thank you for viewing.