Building a Palo Alto PCNSE Lab

0:00[AUDIO LOGO] Hello, and welcome. My name is Keith Barker. And in this set of videos, you and I get to focus our attention on the design and implementation of a base infrastructure for a lab that we can then use to play with, demonstrate, test, and verify a lot of the cool features on the Palo Alto Firewall. So welcome aboard, and join me the next video, as we put our plan together. I'll see you in just a moment.

0:00[AUDIO LOGO] One of the key components for a successful lab is a good design or at least a good plan regarding how we're going to implement that lab. So in this video, let's you and I put that plan together. And over the years, I had the opportunity to build labs on lots of different technologies and platforms, including physical gear. For example, a physical firewall or virtualized gear in the form of a virtual machine that could be running in ESXi or on Hyper-V or up in the cloud.

0:31And other options for virtualization for lab environments include GNS3 and EVE-NG. And so for a lab, here's what I like to do. I've got a couple of PA-440s, and that's like the baby bear these days, the baby bear hardware flavor of the Palo Alto firewall. Now, in the old days, there's a PA-200, then a PA-220, but those are all end-of-life now. Now, there's a 400 series. That's the baby bear. And there's a 410, as well as a 440 and other flavors. And as I was doing some research on these smaller versions of the firewall, the 440s included the support for logging, which is really important.

1:04They can log locally. And the lower models, like the 410s, didn't have that ability at least as of this recording. So I've got a couple of PA-440s. In fact, let me go ahead and show you one of them right now. So here is the PA-440. And on the back side here, we have a couple of connectors for power, with power 1 and power 2 that we can have fault tolerance. You have two different incoming power supplies. And then we turn it over here on the front. Here, we have eight ethernet ports. And then we have an Ethernet management port right here for out-of-band management. Then we have a little USB micro B connector for the console.

1:36There's also a traditional RJ45 connector right here that we can also use for console access. Then we have a couple of USB ports. And then some LED indicators for status over here. This is one of the two PA-440s I've got to work with here. And just a few minutes ago, I did a factory reset on it, so it's factory-fresh. And don't you just love that factory-fresh smell. All-day long. So one of the challenges with a firewall is that if we have a perfectly configured firewall, if there's no traffic to forward or analyze or route, it's a pretty boring existence. So we're also going to need some devices, like clients, and servers, and so forth, that we can use to forward traffic through the firewall in our lab environment.

2:11And to do that, I'm going to leverage a whole bunch of virtual machines. And those will be acting as our clients and servers. And so behind me, I've got a few rack servers. And one of those is a rack server that's running ESXi from VMware. And in that ESXi host, I've got a whole bunch of virtual machines running various flavors of operating systems, including a Windows Server, Windows clients, some Linux devices. And they're all connected into a virtual switch that also lives inside the ESXi hosts.

2:42And ESXi, they refer to that as a V switch. And they have the ability to go ahead and associate each of those VMs with a unique port group representing a different VLAN. So this PC here could be connected into VLAN-10, for example. And this one can be connected to VLAN-20, and VLAN-30, et cetera. And that way, we can logically place one of these virtual machines as a client or a server into any of our VLANs and have it interact with the Palo Alto firewall. Now, the next question is, well, if this is the Palo Alto firewall here, it's hardware, and we have this virtualized switch, what's the connectivity between the two?

3:14And I'm glad you asked. And that's done through a physical connection on the ESXi host. I'll go ahead and put it right here. And logically, that can go up to this switch right here. And that's going to be acting as a trunk, with 802.1q tagging. So if client 1 sends traffic down, it'll be tagged with VLAN-10. As device 2 sends traffic down, that frame of data will be tagged with VLAN-20. As client 3 sends traffic down, those frames will be tagged within 30 and so forth. So the receiving device, whether it's another switch or in our case, it's going to be a Palo Alto firewall, it can identify, oh, that's for this VLAN or that VLAN.

3:46And that's how we can integrate the two. So down here in my physical environment, I've got a physical switch. This port right here is also a trunk port. And then on the Palo Alto firewall, we could break out multiple interfaces. And we can have one interface, for example, go to a port that's assigned to VLAN-10. And another port is assigned to VLAN-20. And another port designed to VLAN-30. However, in a lab environment, what I discovered is that when we start doing features such as high availability and we have multiple firewalls, you have lots of ports, it's a pain. You have to physically connect all those ports from each firewall into the same VLAN.

4:19So another option, which I propose we do, is to go ahead and use trunking once again. So if this port right here is configured as a trunk and this port right here is configured as a trunk, we can take our Palo Alto firewall. I'll go out and draw it right here. So here's our firewall. And we take one of its interfaces. Let's take this one right here and plug that physical ethernet port into this trunk port. And then on the firewall, we can just logically create Layer 3 subinterfaces. And the subinterfaces, we can create our subinterface to support VLAN-10. We can create a set of interfaces for VLAN-20, a subinterface to support VLAN-30, and a subinterface to support each and every separate subnet and VLAN that we have in this virtualized environment.

4:58And when building a lab environment, I learned this trick about 20 years ago when I started studying for my CCIE. And I discovered that by having one physical port and then just logically carving out the interfaces we need, again, is a lot quicker as far as physical cable management and everything else when working in a lab environment. So with that concept in mind about using one physical port and then supporting multiple logical Layer 3 subinterfaces off that physical port with trunking, let's go ahead and put a design together for our overall lab. So let me go ahead and clean this up just a little bit. In fact, let me clear it up a lot.

5:28And let's design our lab. So we'll have a firewall here. And I'm going to call this PA-18. That's going to remind me that, hey, Keith, this firewall is going to use dot 18 for all of its IPv6 addressing for each of its logical interfaces. So that's going to be our firewall. And then we're going to want some connectivity to the outside world. I find that very helpful when testing real-world scenarios. So for connectivity to the outside world, so this would represent the internet. Let's have two different service providers. We have service provider A service provider B. That will be going through.

5:59And that we'll be using two different logical interfaces on the Palo Alto. And we'll label those here in just a moment. And with service provider A, the network is 23.1.2.0, with a 24-bit mask. And for the network going to service provider B, it's 24.1.2.0. And I just want to point out also that those are globally routable addresses, but I'm also using them here locally in my lab, as well. And then as traffic goes out to the real internet, I've got a few other devices in the path doing additional network address translation to make everything happy. So I use these address spaces here and then doing some net up here.

6:31Traffic from the Palo Alto going after the real internet can be great, unless we're trying to reach these two specific networks of 23.1.2 and 24.1.2 because the Palo Alto firewall is going to think that those two subnets are local and directly connected. But everything else should work with me doing some initial net here on that traffic before it goes out to the public, real internet. And while we're at it, the service provider A, which is the little VM I have running in my lab, that little pseudo internet service provider A is reachable at dot 1 as a next stop address. And the little pseudo internet provider here for ISP B is also at one .1.

7:05So 23.1.2.1 and 24.1.2.1. So next, let's carve out a couple of user subnets. Let's go and put one here and another one right here. And for this bottom one on the left here, let's use the IP address space of 10.10.0.0. Everything here is going to be with a 24-bit mask, by the way. And then for the second subnet, let's use 10.20.0.0. And we'll put some connectivity from the firewall here to each of those subnets. And let me go ahead and cap those subnets at the end there. So in the old days, that'd be like a 50-ohm terminator on coax cable.

7:37That's like 25 years ago. Of course, now, this is just a logical representation of an Ethernet VLAN. And let's draw a couple hosts. Put one on each subnet right here. So a little host here, a little computer there, and another one right here. Just represent some type of a client on that network. And let's also go ahead and put another network right here. We'll go ahead and draw a connection from the firewall to that logical network, as well. And let's imagine that this is the 10.30 address space. Again, everything here on this topology will use with a 24-bit mask. So this segment of the network could be where we're placing our servers or services that are going to be made publicly available to internet clients.

8:12So in the old days, that may have been called the DMZ. Sometimes it still is, or we call this the data center subnet. And let's go ahead and put a server or two on that segment. So there's one. There's two. I'll say S1 for server 1 and S2 for server 2. And we'll put some connectivity there for each of them. And another server 1 is going to have an IP address of dot 100. So I'll label that and the 10.30.0 network. And as we bring another servers, we'll identify those as we bring them in. And for these clients down here, they're going to be DHCP clients.

8:43So in all the Layer 3 interfaces on this Palo Alto firewall PA-18, we're going to use dot 18 For that fourth and final octet of the IPv4 address. So here would be 10.10.0.18. Over here would be 10.20.0.18. Here would be 10.30.0.18, et cetera. Now, for the actual interfaces that we're going to use. Let's go ahead and use Ethernet 1/1 as the main interface. We're going to trunk over to our switch. And then going off to the internet to service provider A and B and to the two local internal networks into the DMZ. For those subinterfaces that are supporting these various VLANs, I would like to actually use the VLAN numbers.

9:16And that way, when I see those interfaces, I'll know exactly what VLANs they belong to here in my lab. So the 23.1.2 network is in VLAN-23. So let's use Ethernet 1/1.23 for that logical interface that goes to service provider A. And on service provider B, let's use 1/1. Same physical parent interface. Dot. Let's name it 24. And that when we see it, we'll know oh, this is the logical Layer 3 subinterface that's supporting VLAN-24. And down, here we use 1/1.30. And over here, 1/1.10.

9:48And over here, 1/1.20. So for the zones, let's go ahead and let's use a zone called outside. And we'll place both of our ISP interfaces as members of that outside security zone. Let's also create a zone called DMZ, which we can assign an interface like 1/1.32. And we'll also create a zone called inside. So let me go ahead and label those. So the red will be outside. The yellow, we'll call DMZ. And the green, we'll call inside. And as far as which interface is going to which zones, let's go ahead and put these two interfaces here into the zone called outside.

10:22We'll put these two interfaces here that connect to our internal subnets. We'll put those in the zone called inside. And then for this interface 1/1.30, we'll put it in the zone called DMZ. So I'll just illustrate that right here. So with this topology in mind, which these are going to be a winner for us, we have a few things that we need to configure in order to get traffic to initially flow through the firewall. And that's the point I'd like to get to so that we can actually use a functional network with the firewall as we start building and working with the Advanced. Features on the Palo Alto. So here's a few things we need to do. One is we need to initialize the firewall.

10:53So for that, on the firewall, I've already done a factory reset. And so it's ready to go. But we do need a few, basic commands to make it work, including specifying on the management interface. And then we go ahead and draw that right here. Here's our management network. And here in my lab, that management interface is going to connect to 192.168.1 network. And so, again, that management interface address will be dot 18. So on the firewall, as part of our tasks here, we'll need to go ahead and configure the details for its IP address, default gateway, the mask, and some DNS, so it can actually interact with the public internet going out of this interface right here, the management interface.

11:25Also, here in my lab, I've got a default gateway here at dot 1, they can go ahead and use to access the internet through the management interface. So this will be the management plane. And for all these other interfaces that are shown here, those are all going to be part of the data plane. The next step would be to configure all the other Layer 3 interfaces. So Layer 3 interface config, which involves setting up these subinterfaces and assigning those IP addresses. And also for the benefit of these clients down here off the inside, we want to make sure we enable DHCP services. So we'll make the firewall a DHCP server on ports 1/1.10.

11:57and 1/1.20. And then for these clients, if they want to get out through the firewall, we're going to need to have security policies, at least enough for them to be allowed the initial flow of traffic going out to the internet. We're also going to need some network address translation to allow traffic as it flows through the firewall to be sourced and added to either a routable address or to an interface address here on the outside of the Palo Alto. And then finally, we're going to go ahead, and we want to test and troubleshoot, if necessary. So a good test would be to take one of these clients and verify that the client once the firewall is all configured, that the client can go out to an internet resource and get a response.

12:31And that would be a great test just to verify we have the basic components set up correctly in our topology. So with that in mind, in our next video, you and I get to do the basic bootstrap of the firewall itself. So I'll see you there in just a moment. Until then. I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] In this video, you and I get to do the basic bootstrapping of the firewall, including the configuration for the details regarding its management interface, and how to reach the internet. So in our journey, we are right here, initialize the firewall. I've taken the liberty of doing a factory reset on this Palo Alto firewall. And let's take a moment and just confirm if I've got a console connection going over to this firewall. So sure enough, it is right where I left it. So here is the firewall, the PA-440.

0:31I've got the console cable connected to the RJ45 jack connection on the firewall. And on my computer, I've got a terminal emulator. I'm using SecureCRT to connect to this console port. Also, notice I have not yet connected any cable here to the management port because, by default, this bad boy is using 192.168.1.1, which I currently am already using in my lab. So we're going to change the management interface address to 192.168.1.18 and then tell it, the firewall, to use .1 as its default gateway. So currently, we are connected to that firewall that we just hooked up via its console port.

1:05And I've also said yes, I want to stop the zero-touch provisioning and configure the firewall in standard mode, and that's where we are right here. So we press Enter. And let's go ahead and log in with the default username of admin, and I'll put the default password of admin, and press Enter. And now it wants me to change that default password. So I'll put in the old password of admin, and I'll put it in a new password, press Enter. I'll confirm the new password I just set and I'll press Enter again. [LAUGHTER] And it's a typo. All right, let's do it again. So on the initial password change there, I must had a typo.

1:37And then when I try to confirm it, it wouldn't let me. So let me try that again. Log in as admin, password of admin. Old password is admin. New password is-- and I'll do this a little bit slower. So I put in the new password, press Enter, and I'll confirm the new password, and press Enter. Yay. So now if we do a show system info and press Enter, so there's the command there. And it currently is using the management IP address of 192.168.1.1 and that's what we want to change. So we'll type in configure to move out of operational mode into configuration mode.

2:08And from here, what I like to do is go ahead and use these commands. Do the initial configuration of the management IP address to .18, set the default gateway to .1, and set up a couple of DNS servers with 8888 and 1111. So I take these commands right here, just right-click, and copy them. And then go over here to SecureCRT, right-click, just confirm the settings. Those look great. Click on Paste, and boom, we've just implemented those four commands, and now we'll go ahead and do a commit. So that commit is in progress, moving the candidate configuration, these commands we just put in over into the running config.

2:41And it is almost done. Of course, we could also type in Control C to return to the command prompt and let the commit finish in the background. Either way is great. All right. It says it's done. Let's type in exit to exit configuration mode and go back to operational mode. And let's do a show system info one more time, and now it is using this IP address. Great, great, great. Default gateway is .1, which looks great. And before we call this done, we should go ahead and test it as well. So I'm going to take the PA-440. I'll take a nice long cable and I'll plug in the management port into my home office network just to verify that we have connectivity from this PA-440 out to the internet.

3:18And on second thought, I think what I'll do instead of using a super long cable, I'm going to go ahead and turn the thing off, move it back to the rack, and then plug it in there. And in that way, we can use a shorter cable and that be the final resting spot for it as well for the duration of these videos. So give me a moment right now and I'll go ahead and place this on the rack. All right. So it's now sitting on the rack and it has an Ethernet cable plugged into the management port that connects to the home office network. Also, in preparation for the next video, I also plugged in to port number 1, Ethernet 1/1. I plugged in a cable there that goes to a switch port that is doing trunking.

3:51So these should be the only two physical connections needed from an Ethernet perspective for the management and operation of our lab firewall. All right. So let's have a moment to go ahead and boot up. Let's go ahead and verify its basic connectivity. So once again I'm using SecureCRT as my terminal emulator. But this time I'm connecting to the firewall to its management IP address at 192.168.1.18 using SSH. And I've logged in successfully. That's great news. So let's do a quick test with a ping host, and let's go to www.paloaltonetworks.com. And if that works, which it is, I'll do a Control C there, that verifies that DNS is working.

4:24It also verifies that we can reach paloaltonetworks.com, which is fantastic. So we have initialized the firewall, boom, done. And our next step is to configure the Layer 3 subinterfaces as shown in our topology. And then my friend, this is what you and I get to do in the very next video. So I'll see you there for that in just a moment. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] In this video, we're going to continue with our game plan by implementing layer-3 subinterfaces based on our topology. And as a reminder, here are the five interfaces we're going to be configuring, this one here for service provider A, service provider B, one for our DMZ, and a couple for our inside networks. And again, the number we're going to use represents the VLAN I'm using in my lab environment. That way, when I see it, I'll know exactly what VLAN it belongs to based on the actual name we give it.

0:30So for my management computer, which is right here at .151 on the management network, let's go ahead and connect via HTTPS, or the Palo Alto firewall, and configure those five interfaces. So we're currently attempting an HTTPS session over at 192.168.1.18. My browser doesn't like the signing CA that signed the cert the firewall is using initially. That's OK. We'll fix that in a subsequent set of videos. But for now, we'll go ahead and click on Proceed. We'll log in as the user admin. We'll supply the password we configured in the previous video, and we'll click on Log In.

1:01All right, welcome to PAN-OS 11, fantastic, so we'll say don't show that again. And I don't need to see any of those others as well, so I'll dismiss those messages. And with those dismissed, we'll click on Close. And we'll set up telemetry data collection later, so we'll click here on Remind Me Later, because our goal right now is to go ahead and configure the layer-3 subinterfaces. So we'll click on the Network tab. On the left, we'll make sure that Interfaces is selected. So on this P-440, in this default config, it has ethernet1/1 as Type Virtual Wire cell. We're going to fix that.

1:31We're going to click on ethernet1/1, and I'm going to specify that as a Type of Layer 3, not because we're going to be using the parent interface with an IP address, but because we are going to create logical layer-3 subinterfaces, so the parent needs to be layer 3. We'll make that one change. Click on OK, and then we'll go ahead and make sure that ethernet1/1 is selected and highlighted. And then down below, we'll click on Add Subinterface. I'm going to go ahead and do VLAN 10 first, so I'm going to name it 10. And then as far as the 802.1Q Tag, I'm going to say it's also looking for 10. And then for the Virtual Router, we don't have anything except for the default virtual router, so I'm going to say New Virtual Router.

2:06And let's call our new virtual router R1, as in Router 1, and we'll click on OK. And then for the Security Zone that this subinterface is going to go into, that's going to be the Inside security zone, which we don't have yet, so we'll go ahead and click here on New Zone. And we'll specify the name of Inside. We'll click OK. And then we'll give it an IPv4 address by clicking on the IPv4 subtab, clicking on Add, and this is going to be 10.10.0.18 with a 24-bit mask, just like that. I also want to specify an interface management profile so we can have that interface pinged by clients, just to verify their basic connectivity.

2:41So under the Advanced subtab here in the Management Profile section, we'll go ahead and use the dropdown, and we'll click New Management Profile. And I'm goiong to call this Ping_Only, just like that. And for Network Services, we'll allow Ping, and click on OK. And boom, we're done. We'll click on OK. So for the other four interfaces, it's going to be a fairly similar process, except we're going to swap out the appropriate zone and the appropriate IP address based on the interface that we're configuring. Also, for the intro or fundamentals regarding configuring interfaces on the Palo Alto firewall, please check out our PCNSA content as well for a slightly slower pace.

3:14All right, having said that, let's go do 1/1.20 next. So we'll make sure that ethernet1/1 is selected, and then with it selected, we'll click on Add Subinterface. I'm going to go ahead and name this 20 because it's going to be supported in the 802.1Q tag of 20. So I'll put the tag of 20 there, and we're going to send that to the same virtual router, which is R1. And this also goes into the inside security zone. And for its IPv4 address, we'll click on Add, and it is going to be 10.20.0.18 with a 24-bit mask, just like that.

3:46And under Advanced tab, we'll go ahead and use the management profile called Ping_Only and click on OK. All right, two down, three to go, so we'll make sure that 1/1 is still highlighted here and then click on Add Subinterface right here. And let's go ahead and do our DMZ next, and that is going to be identified as ethernet1/1.30, paying attention to the 802.1Q tag of 30, assigned to the virtual router called R1. And the security zone is going to be a DMZ. It doesn't exist yet, so we'll create it by clicking here on New Zone.

4:16And we'll call it DMZ and click on OK. And then click on the IPv4 subtab here and click on Add, and this is going to be 10.30.0.18 with a 24-bit mask, just like that. And then we'll click on the Advanced tab, and we'll specify we want to have the Ping_Only management profile used there. And click on OK. All right, everything looks great so far. Let's create two more for our two service providers. So with 1/1 still highlighted here, down below we'll click on Add Subinterface. We'll go ahead and call this one 23 for service provider A, paying attention to the 802.1Q tag, so VLAN 23.

4:51And the virtual router is going to be our same one, R1. The security zone is going to be the outside security zone based on our plan, so we'll click here on New Zone. And we'll specify Outside and click on OK. Click on IPv4. Click on Add for the IP Address, and this is going to be 23.1.2.18 with a 24-bit mask. And with that supplied, we'll then go to the Advanced tab, and we may or may not want to be able to be pinged from the outside. In fact, you know what? I'm going to leave that off. And that way, if we have devices on the outside that are trying to ping our IP address on the outside, there won't be any responses because the management profile is not going to be allowing ping.

5:26So I'm going to go ahead and leave that part off here, and we'll click on OK. All right, one more to go, and that'll be the interface for our service provider ISP B. So we'll make sure ethernet1/1 is still highlighted. Click on Add Subinterface right there, and we'll call this one 24 because in my lab it's going to be VLAN 24. And we'll match on the tag of 24. So up here, that's just for me, so I remember where it is, and down here is the actual 802.1Q tag that we're matching on. And we'll assign that to the same virtual router, R1, and we'll also assign that to the outside security zone by selecting it from the dropdown there and clicking on it.

6:01And then we'll go to IPv4, click on Add, and the IP address we're going to give it is 24.1.2.18 with a 24-bit mask. And then we'll click on Advanced. And just like ISP A, we're not going to go ahead and assign it a management profile for ping or anything else, so I think we're good there. We'll click on OK, and let's check our work. So we have the VLAN 10, VLAN 20, VLAN 30, for the two inside and the DMZ. I also want to confirm the zones here, so I'm going to drag this over so I can see that right next to it. So inside, inside, the DMZ, and then we have 23 and 24 for outside.

6:34And the IP addresses look correct as well, so let me go ahead and commit this. And click on Commit again. Let that cook in the background. And it's giving me an error about a virtual wire. Let's take a look at that and fix it right now. So with Network selected up here on the top, on the left, let's click on Virtual Wires. And sure enough, right there, this default-vwire came with the default configuration, and it had two interfaces, 1/1, 1/2. And we changed the type to 1/1, so now it feels hurt. So what we'll do is we'll fix it by saying goodbye. So we'll just highlight that default-vwire. Click on Delete. Click on Yes, and now it's gone.

7:06Let's go ahead and click on Commit, and we'll click on Commit again. And it looks like it's on its way. So as this commits, our next step is to configure DHCP services so that clients on the 10/10 subnet or the 10/20 subnet, they can come up, ask for an IP address, and get one from the firewall, who's acting as a DHCP server. So we'll configure that piece in our journey next, and I'll see you there in just a moment. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Based on our plan, we want to enable DHCP services on the firewall, including support for the 10.10 subnet and the 10.20 subnet, and that's what you and I get to do right now. So we've initialized the firewall. We've configured the layer three interfaces. And the DHCP services we want to enable over here on the 1/1.10 subinterface and also the 1/1.20 subinterface. And for a game plan, let's use the range of dot 51 through 99 on each of those respective subnets.

0:33So with that plan in mind, let's head over to the firewall and set up DHCP services on those two subinterfaces. So back at the firewall the previous commit finished, great, we'll click on Close. And with network still select at the top on the left, let's go over to DHCP. And we'll click on Add to go and add DHCP services. So we'll click on Add. And for the first one, let's use interface 1/1.10 to support subnet 10. I'll ping before we allocate a new IP address. And I set a timeout for one day, which means that the clients have to renew their lease at least every day.

1:04And For the range for the subnet 10, let's click on Add. And let's say the range is 10.10.0.51 based on our plan all the way through 10.10.0.99. Looks great. And we're getting options. Let's go ahead and specify the default gateway. It should be the firewall itself, which is at 10.10.0.18. For the mask we're heading out, it's going to be a 24-bit mask. For primary DNS, let's use 8.8.8.8. And for our secondary DNS, let's use 1.1.1.1. And we'll click on OK. All right. Then we'll repeat that for interface 1/1.20 by clicking on Add.

1:37From the dropdown, we'll choose the right interface to the dot 20 interface. We'll do a ping as a check before handing out a new IP address, which may or may not be super helpful because a lot of computer like Windows computers have a firewall in place that don't respond to a ping. But for devices that don't, that may help us not accidentally hand out the same IP address twice if there's a static address already in place. And I'm going to do a timeout, specify a one day lease, and let's specify the pool range of 10.20.0.51 all the way through 10.20.0.99 based on our plan.

2:08And for options, the default gateway would be 10.20.0.18 and a 24-bit mask. And the primary DNS, we'll use 8.8.8.8. And a secondary DNS, we use 1.1.1.1. And we'll click on OK. All right. Look at the details here. Those look good. So we'll go ahead and click on Commit. And we'll click on Commit again. Now, once this commit is completed and it's now part of the running config, if we bring up clients in VLAN 10 or 20, they can get an IP address, yes. They can learn about the default gateway and DNS servers. But they're not getting up to the internet. And that's because the firewall has a default policy that says no for Inter zone traffic.

2:42So in the next video, let's put in a simple security policy rule that allows those initial flows of traffic from VLAN 10 and VLAN 20 out to the internet. So I'll see you in the next video for exactly that. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] By default, the firewall, if there's traffic that needs to be forwarded between two different zones, the answer is no. We're not going to do it. So what we need to do is set up a basic, simple security policy rule that says, you know what, if traffic is trying to be sourced from a device coming in to the firewall on the inside zone, and if that traffic needs to be routed out to the outside zone, please go ahead and allow that initial flow of traffic to go. And this can be done through the security policy rule, and that's what you and I get to do right now.

0:33So here is our commit that was successful from the last video, fantastic. And to set up our simple security policy rule, we're going to click on Policies at the very top. And on the left, we're going to make sure that we're selecting Security. So with Security selected on the left, here we have rule one that came by default. Let me go ahead and select that and delete it. We don't need that. We'll click on yes. And let's go ahead and create our own. So we'll go ahead and click on Add. And let's call this in2out. And for the source, we'll specify the source is going to be traffic entering the firewall on the inside zone.

1:04And for the destination, it'll be traffic that's trying to exit out of an interface associated with the outside zone. And what we can also do is let's go ahead for source, let's also throw in some source address information right here. So we'll click on Add, and let's go ahead and make a new address group. And let's call this Internal_Subnets. And we'll go ahead and click on Add here. And then I'm going to add a couple new address objects as part of this group. So I click right here to do a new address object. And we'll call this Subnet_10. And that is going to be the 10.10.0.0 network with a 24-bit mask, just like that.

1:38And click on OK. And then we'll add one more new address, object, and this will be Subnet_20. And the IP address range there is going to be the 10.20.0.0 network with a 24-bit mask. And we'll click on OK. So effectively we're creating three new objects. Two address objects and one address group object right in one fell swoop, and we'll click on OK. So for the source, it's the inside zone in the IP range of any those two subnets, and the destination is going out of the outside zone. And for application, we'll say "any" and all the application default. We're getting ports, and we'll click on Actions.

2:10And that's going to be allow. And we'll leave a log on there, and click on OK. Also, before we leave our security policy rules, I want to modify the default behavior regarding the interzone_default because if it's dropping traffic by default, it's not talking about it. It's not logging it. So I'm going to highlight interzone_default here, click on the override button right there, and then for the actions, I want to say, I want to log it. Now, in a production environment, you may or may not want to have that logged, but in a lab environment it's super helpful when you're trying to troubleshoot why didn't that get forwarded because the denies based on that default rule are going to be logged now if we enable this.

2:44So I'm going to click on OK. So now, with the interzone_default rule here in the bottom position, if we scroll to the right, in the column where it says options if we hover there, it's now showing if we hover over the options here, this is the icon for logging, meaning that we're now logging on hits on this rule. All right, so we'll go ahead and Commit that. And we'll click on Commit again, and we'll let that complete. Now, in order for our client's traffic to actually get out to the internet, besides having permissions with our security policy role, we're also going to need to do some network address translation. So in the next video, let's set up a simple network address translation rule for source net, so our clients can get out to the internet.

3:18So we'll do that in the next video, and I'll see you there in just a moment. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] In the previous video, we set up a security policy rule to allow the initial flow of traffic from clients in our subnets to go out to the internet. And in this video, we're going to add on another very important aspect of that, and that is network address translation so that the private RFC 1918 addresses that we're currently using in our network can be swapped out with globally routable addresses as they go through the firewall. So we are right here. And what we want to do is make sure that the firewall is going to swap these IP addresses out as traffic goes out to the internet.

0:33And let's use this interface right here, 1/1.23, and specify, as traffic goes out that interface sourced from these clients down here, that that should be swapped out to whatever the IP address is on this interface. So at the moment, this 1/1.23 interface is using 23.1.2.18. So we'll set up source NAT rules to allow that translation to happen on the initial flows of traffic from these clients going out to the internet. So from our previous video, the commit completed successfully. That's great. We'll close that. And with Policies on the top selected, on the left, we're going to click on NAT to configure our NAT policy rules.

1:08So there aren't any at the moment, so we'll click on Add right here to add a new rule. And let's call this SNAT_In-2-Out, just like that. And we're in the Original Packet. The considerations are going to be is traffic that's entering the firewall on an interface associated with the inside zone. And it's trying to be routed out of the outside zone. And for our demonstration and for our lab, let's use interface 1/1.23, going through service provider A. And for the source address, let's also lock that down to our subnets. So there we have the address group we created earlier that includes subnet 10 and subnet 20.

1:42So we'll select that. And then for the translated packet, we want to do source address translation. And we're going to do dynamic IP import. And specifically, we're going to be doing overloading. A lot of vendors refer to this as port address translation. So we'll go ahead and specify the interface address. And then we're going to use interface 1/1.23. And the interface IP address that's currently sitting there is this guy. So potentially, we could map thousands of internal client IP addresses to this one externally routable address. So we'll click on OK.

2:13And then we'll click on Commit to go ahead and move that from the candidate configuration over into the running config. Now, one of the challenges with the two policies we just created, the security policy and also the NAT policy, is that the firewall at this moment has no desire to forward packets out a certain direction because it does not have a route, a default route, that says, hey, use service provider A. So in the next video, let's fix that by adding a static default route that tells the firewall, hey, if you need to forward a packet and you don't have a more specific route in your routing table, forward it to service provider A using the next type of service provider A, which in our topology is going to be 23.1..2.1.

2:51So in the next video, join me as we implement a default route on the firewall. So I'll see you there in just a moment. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] In this video, you and I are going to configure a static default route on the firewall. So in our steps, we are right here. We'll put in routing, very important. So we've already done the initialization, Layer 3 interfaces, DHCP server, security policy, the NAT policy, and now we're going to set up the default route. And the reason this is so important is because if a client here, let's say we have a client at 10.10.0.60 and it wants to forward a packet out to the internet, the security policy says yep, please allow it to happen.

0:34The network address translation swaps out the source address with this one through service provider A, but the firewall itself won't even try to forward it out to the internet unless it has a default route that says that's the way it should go. So what we get to do right now is configure a static default route on the Palo Alto that says, hey, listen, if you don't have a more specific route to whatever the destination IP address is the client is trying to reach, go ahead and use the default route, which is going to use service provider A with the service provider A next hop of 23.1.2.1. So that's what we're going to configure right now.

1:06So to configure the default route we're going to go to Network. And with network selected over on the left, we're going to go down to Virtual Routers. And I've got the default virtual router which we're not using, so I'm going to go and select it and delete it. Goodbye. And click on Yes. So currently our virtual router R1 has these five logical Layer 3 interfaces associated with it. And as a result, if we clicked right here on More Runtime Stats, and I'll scooch this over just a little bit, and we went to the Forwarding Table-- [LAUGHTER] --what we should see is we should see directly connected networks associated with each of those five interfaces.

1:42But I don't see any, so let me go ahead and close that for a moment. And let's go back to Interfaces, and that's because this interface is down. I must not have plugged it in. I thought I did. Let me take just a moment and physically plug ethernet1/1 into the physical switch where it's currently doing trunking. I'll be right back. So I just moved the physical cable over to the correct port, 1/1. Let me click on a refresh right here, and that looks much better. Now, if we go back to Virtual Routers, so now if we click here on More Runtime Stats, we should see here in the route table that each of those networks are showing up as directly connected.

2:18So those are these flag of C represents here. The C represents directly connected. So the 10.10 up ethernet1/1.10 and the 10.20 network up ethernet1/1.20, and so forth. So the route table is everything that the firewall knows about, and then the forwarding table is actually what's being used. Sometimes we have multiple routes to the same destination and it may prefer one over the other. And so the actual winner's table is the forwarding table right here. So if we look at this list here, if we scroll up and down-- in fact, we can make a little bit taller here, there is no default route.

2:49So this firewall only knows how to reach these networks right now. It doesn't know how to reach the rest of the internet. So what we're going to do is we are going to configure a static default route, and it goes something like this. We'll go into the details of router 1, our virtual router by clicking on it. And then on the left, we'll click on Static Routes. And what we'll do is we'll create a new IPv4 static route by clicking on Add and we'll call this Default_Via_ISPSA because that's what it's going to be. And here's the syntax for a default route, 0.0.0.0-0.

3:20So we can either just put it in here or we can make an address object that represents that. Let me go ahead and just leave it like that. And the interface we want to use is the one going out through service provider A. Let's take a peek at that real quick. So that is this interface right here, 1/1.23, and it's got a next hop address, that's the ISPA's next hop address of .1 on the 23.1.2 network. So with that in mind, let's go back to the interface on the firewall. So from the dropdown, we go to Interface. we're going to use 1/1.23, and the next hop IP address is what we want to use and that next hop IP address is 23.1.2.1.

3:56And then for the IP address, we can actually put in the IP address here or we can create an address object that represents that. In fact, let's do that. Let's call it ISPA_Next_Hop. And then for the IP address, it's going to be 23.1.2.1, and then we'll click on OK. And then we'll click on OK. So now we have a default route or at least we will once we commit this. So we'll go ahead and click on OK, and then we'll click on Commit, and commit one more time. Now, before we leave this video, let me go ahead and let that commit happen in the background. We want to test and verify that the default route on the data plane is actually working.

4:27Now one option that we could do is we could go to Device, and then on the left, we can go down to Troubleshooting. And with troubleshooting selected-- so here for our test configuration we could say let's do a ping. And for the source, let's specify 23.1.2.18, that's our IP address over on our ethernet1/1.23 interface. And for the destination, let's go ahead and ping 8.8.8.8. And we'll click on Execute. So it says running test. And if we click on the result, it is successful. Now, the reason it's important to source it from this interface is because if we didn't source it from the actual data plane interface, it would by default try to source this from its management interface.

5:08And so you want to make sure that when we're testing our connectivity, if you're trying to test the data plane default route, make sure you're sourcing it from a data plane interface. Another option would be right here at the command line with a ping and a question mark. And I'm going to put in a source and a question mark. And we can put in 23.1.2.18, and then host 8.8.8.8, and press Enter. And also we can see that is succeeding Another cool option to confirm is using a traceroute. So if we do a traceroute and we've got a new traceroute host 8.8.8.8 and press Enter.

5:39By default here, it's using the management interface and the next hop is the default gateway associated with the management interface. That's not using the data plane. But we did the traceroute again and we go ahead and add the source. So do the source 23.1.2.18 with the host of 8.8.8.8 as the destination, press Enter. Now we can see the first hop is 23.1.2.1, which is going through service provider A, and then it's back calling to my home network and then off to my real ISP and onto the rest of the internet. So just be aware, when you're testing the default route on the data plane, make sure you're testing it from the data plane and not from your management interface, which is the default.

6:14So let's do a quick review of what we've configured. We've configured our Layer 3 interfaces or subinterfaces. And as part of that, we set up our zones and our virtual routing. Also, included as part of that is a default route so we get a more runtime stats and forwarding table. There's our default route right there. We also set up our policies, including our security policy to allow that initial flow of traffic in and out. We also set up a basic NAT policy for source NAT for that same flow of traffic. And our last step, I suppose, is just to assume it all works. Or we could bring up a client or two on those subnets and actually verify that they can get traffic out to the internet and get responses back, which is exactly what you and I get to do in the very next video.

6:54So I'll see you there in just a moment. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] In this video, we're going to do a basic test of our infrastructure for our lab by bringing up a couple of clients, one in VLAN-10 and one VLAN-20, and verifying that they can access resources out on the internet. So in my lab environment, I've got on my ESXi VMware host. I've got a couple of VMs or a few VMs in VLAN-10 and VLAN-20. Let's go pick one from each of those VLANs and bring them up so we can test connectivity out to the internet going through our newly configured firewall.

0:32So here's the graphical user interface for directly connecting to an ESXi host. And let's go down to Networking. And let me go to VLAN IDs. And let me pick on VLAN-10. And we just see who's connected there. So here on VLAN-10, let's go ahead and grab this guy right here, Linux for Palo Alto. I'll click on it. And it is in VLAN-10, the source network interface card is. And let's go and power that on. And while that power is on, let's go down to Networking once again. And let's go down to VLAN-20. And let's pick a machine from there. So here, I have a machine called Windows 11 VLAN-20 in Domain.

1:06Let's go ahead and click on that. Confirm it's really in VLAN-20. It is. And we'll power that on, as well. So this represents a Linux machine here on VLAN-10 on the 10.10 network, and a Windows computer here on VLAN-20, which is running the 10.20 address space. And the Palo Alto firewall is acting as a DHCP server. So each of those clients should be able to get an IP address via DHCP from the Palo Alto. So back at the firewall, if we go to the Network tab on top and we go down on the left to DHCP, for both of these interfaces for VLAN 10 and 20, respectively, if we click here on View Allocation, this shows that the Linux machine has an IP address at dot 56.

1:43Fantastic. We'll close that. And for the other interface, we'll click on View Allocation right here. And this one does not. That's my Windows machine. It could be that Windows machine is taking a little bit longer to boot up. So let's go ahead and start with the Linux computer, which got its IP address via DHCP already. So this represents that Linux computer right here. And just to confirm, let's bring up a command prompt. And let's do an ifconfig on this Linux computer. Sure enough, 10.10.0.56. And let's just try a ping out to the internet at 8.8.8.8.

2:15I just get a chuckle when it works the first time. There's a few moving parts here, and that seems to be working. Let's go ahead and close that. And let's open up a browser here on this little computer right here. So let's make a road trip out to YouTube. And YouTube seems to be working great. All right. So we've just verified that a computer sitting here on the 10.10 subnetwork can access the internet successfully, going through the firewall. And let's do the same thing by testing the computer over here on VLAN-20. And so for the Windows computer on VLAN-20, let me bring it in and 10.20.0.105.

2:48That's our range. Oh, I believe this is statically configured. Let's take a quick peek. So I'm going to open up the Network Control Panel, and we'll right-click and go to Properties. We've got IPv4. Oh, yeah, sure enough. So it has a statically configured IP address 10.20.0.105. And it has a default gateway of dot 18, which is back here at the firewall. So it looks OK. So we'll go ahead and close that and close that. And let's bring up a command prompt and do some testing. So we'll do a ping out to 8.8.8.8. And that seems to be working great. And let's open up a browser.

3:20So we'll open up a browser. Again, this is from a client over here on the 10.20 subnet. And let's go to fast.com. That's from Netflix. And that seems to be doing pretty well. And that's traffic from this little Windows computer going through the firewall, through a few layers of net here out to the internet. And it shows 650 megabits per second internet speed that's for download. Not bad. So the last thing I want to do here is take all this beautiful work that we've done, and I want to save it. So I'm going to click here on Device. On the left, we'll go over to Setup.

3:51And then we'll go to Operations. And I want to save a named configuration snapshot. So we'll click here and save name configuration snapshot. And I'm going to call this Base_LAB_0201 because that's the date today. And then I'll go ahead and click on OK. That way, if we ever need to restore back to this point, we can. So click on Close. Also on here, I'm going to download that to my local computer by clicking on Export named configuration snapshot. And from the dropdown, choosing that snapshot we just made. And then clicking OK to download that to my local management computer.

4:21So in this set of videos, we've done two basic things. Number 1, we've gone through a lot of the fundamentals regarding the configuration of the basic elements of a Palo Alto firewall. And secondly, we've put together a beautiful foundation on which we can build upon as we start working with the more advanced features of the Palo Alto firewall. So thanks again for joining me in this set of videos, and I'll see you, my friend, in another set very, very soon. Until then. I hope this has been informative, and I'd like to thank you for viewing.