Automate FGT Deployment

0:00hello and welcome my name is Keith Barker and if you and I were asked to deploy let's say a few hundred forty eights we'd want to have some tools in place that can help us automate that process and in this set of videos we're going to take a look at some of those options including low touch and zero touch provisioning along with templates and scripts that we can use to automatically push out to a device when it comes online so join me in the next video as we take a look at some of our options for automating the deployment of forty e ights and then we'll follow it up with a game plan and then do some demonstrations of doing exactly that so I'll see you my friend in the very next video in just a moment.

0:00In our topology after this point, we've implemented most of these V-doms and devices, except for this one right here, which is going to represent a brand new Fortigate that we want to add to our environment. Now, if we just want to add one Fortigate, it's pretty easy to do. You set up a basic management IP address, you carve out V-doms if you want it, or you use the physical device as a whole, register it with Fort Manager, and away you go. However, if we are rolling out dozens or hundreds of Fortigates, we want to have some options for automating that process. And so some of the options for automating that include LTP and ZTP, which stands for Low Touch Provision ing and Zero Touch Provisioning. And here's the basic idea. Let's imagine this is going to go into a branch environment, we can take the firewall, and without any pre-configuration whatsoever on the firewall itself, ship it out to that site, have them plug it in, and once it plugs in and gets an IP address, it can reach out, connect to Fort Manager, automatically register itself with Fort Manager, and then have all the configuration want pushed to it done automatically. And that's Zero Touch Provisioning. Now, Low Touch Provisioning is very similar to that.

1:03However, the Low Touch involves implementing a few basic commands initially on the Fortigate firewall, and then the rest of it's done with automation after it's registered with Fort Manager. Now, to implement the Zero Touch Provisioning, we'd have to have this device somehow learn where the Fort Manager is so it can connect and register with that Fort Manager on its own. And there's a few options for doing that with Zero Touch Provisioning. One is to use Fort Cloud or Forted Deploy. And without the device would plug in, we'd plug in with an interface that's using DHCP. So depending on the model you have, that may be, for example, the WAN-1 interface or the WAN-2 interface or some other interface that's supporting DHCP, it gets an IP address via DHCP, including a default gateway it can use, and via Forte Cloud it contains the location or the IP address of Fort Manager from Forte Cloud, so it can connect with Forte Manager and get the ball rolling. Another option is to use DHCP services with DHCP options 240 and 241. And by using a DHCP server option, we don't have to involve Forte Cloud or Forte Deploy, because we get out of the DHCP server setup with these options, and part of those options are going to point to the IP address for Forte Manager. So it boots up, it looks at those options, identifies where Forte Manager is, and then they can go ahead based on that information, connect to Forte Manager to get the ball rolling. Another option for Zero Touch Provisioning would be to use a USB drive, where it gets its initial configuration from that USB drive

2:21, including how to connect to the Forte Manager to get the ball rolling. Another option is LTP Low Touch Provisioning, and that means you do have to do something at the Forte Gate initially to get the ball rolling, it doesn't just happen automatically, like ZTP is using one of these above options. So with low touch provisioning, we may have a simple script, for example, it says, "Hey, here's how to get to the Forte Manager," and we apply that to the Forte Gate, and then as a result of our minimal configuration, it can then reach out to the Forte Manager, register with Forte Manager, and then we can push out all the configuration from Forte Manager to that newly deployed firewall.

2:53So let's chat about some options. Once the device does connect to Forte Manager for pushing out configurations to a new 48. One option would be we could go ahead and push scripts to that device. Now with scripts, there's an option for a pre-run script. So a pre-run script, think of it like running a one-time script on a device to get some of the things you want set on that device. We could also set scripts as part of a provisioning template that are associated with that device, which are persistent, meaning that provisioning template, the CLI template, is linked or associated with that device persistently or forever until you remove it. Also with scripts , there's scripts that we can run directly against the device itself. There's also scripts that we can run against the device database in Forte Manager, which would then require an additional push of the device database out to the firewall. So we can run scripts at the device itself, or at the device database in Forte Manager. And one cool thing about a script that you run against the device is that once you issue those script commands, because you issued them from Forte Manager, it doesn't auto update a Forte Manager regarding the new configuration . Very similar to an auto update after the new configuration is been pushed out to the device.

3:58Another option for automating the deployment is we can go ahead and pre-register a Forte Gate based on a password or the Forte Gate serial number so that when it checks in with Forte Manager, we don't have to actually authorize it. It becomes authorized automatically if we prepared Forte Manager that this device is coming online. So in Forte Manager, we can add the device ahead of time. And as part of adding that device, we can also associate with that device scripts that we want to run against that device, or provisioning templates we want to use in conjunction with that device. And there's also another cool option called a device blueprint. And a blueprint can contain a lot of details we want associated with that device. So we could actually add the device and refer to a blueprint or specify all those individual details as part of that device directly in Fort e Manager. Now, another tool that we've talked about in previous sets of videos that we could also leverage here is metadata. So if we have a script or some configuration, we want to push out to new Forte Gates, but there's slightly different interfaces or different zones or other options that vary based on the device. Like for example, a router ID that needs to be unique, we can use metadata and normalized interfaces, normalized zones, and metadata as variables. So we can have a script that uses those variables and then push them out over and over again to new devices as they come up.

5:11And many of these options we've seen in previous sets of videos, including using variables and metadata, including using normalized zones and interfaces, we've run some scripts. But what we haven't done is we haven't told Forte Manager about a device that we have not yet onboarded. So we're going to go ahead and use these options right here. And we can also leverage our other tools as part of the overall automation process. Now, I also want to give you a word of caution, because there are lots of things that we could push out to a new firewall. For example, we could push out new VLAN interfaces. We could create zones and interfaces that belong to those zones, and we could push out firewall policies and we could push out system templates and we could push out, you know, CLI scripts. It's important to not try to push everything all at once to a brand new Fortigate. What we'd want to do in a test environment is make sure individual components work on the model we're going to push to test them individually. And then after we know they work, then go ahead and you can put all of them together. Because with all the variables with scripts and metadata and normalized zones and interfaces, if we try to push out a few hundred changes using all these options to a new Fortigate, if one of those elements fails, it makes it hard to troubleshoot. So I'd encourage you to practice with individual small components as you're rolling on a new Fortigate, test them first. And then once we have a tuned up and ready

6:28to go set up for pulling new Fortigates, and we've tested it and know it works, then we can start rolling that out at scale to multiple firewalls. But again, as you begin with the automating and the rolling out of new Fortigates using zero touch or low touch provisioning, it'd be a great idea to do piece by piece, make sure the individual parts work before you put it all together. All right, so with that in mind, in the next video, let's put a game plan together for how we're going to onboard this brand new 60F firewall. So I'll see you in the next video for the game plan.

0:00Let's put our game plan together for rolling out a new FortiGate. Now, I currently, I used to have, for the edges, I used to have an HA pair, and that was being supported by the 60F1 and 60F2, and I removed that HA configuration, so I had another FortiGate to play with, and I have the new 60F2, which we're going to use to deploy as a new device. What we want to have is this V23, a VLAN 23 interface connected to the service provider here on the 23.1.2 network, and a subnet 10.130.0, supported by VLAN 130, and for this device, I want to use .59 as its last octet, aka the last number of its IPv4 address on those respective networks. I also want to go ahead and have this on a management network of 192.168.1.0 with a 24-bit mask, again, using the .59 for that last octet right there, and that's my management network I'm using across the board here in my lab environment. As far as the game plan, we're going to use 60F-2. We'll do a factory reset on that, so there's nothing there, and then once that factory reset is done in FortiManager, we'll go ahead and create an entry for the new FortiGate that we're about to bring on board with the details of what we want to push out to that device, so I'll say prep for 60F. Now, part of that, when we configure that on FortiManager, we're going to need to tell FortiManager what the serial number

1:18is or we have to specify the passcode, so I'm going to use the serial number for that 60F2. I've got that written down, and we'll use that as we prepare the FortiManager for the new 60F2 here that's going to be coming on board. Now, as I mentioned, we could all at once push policies and push tons of configuration down, but I want to do it piecemeal step-by-step, so if you want to replicate this, you also can do it step-by-step without having 15 different things being pushed all at once, and then at that firewall, the 60F2, I'm going to go ahead and do a little teeny bit of configuration just to tell the firewall where FortiManager is, so I'll refer to that as LTP, Low Touch Provisioning, on 60F, and then once the 60F2 has registered with FortiManager, let's go ahead and run some scripts, and I've got several sets of scripts I want to go ahead and run against the 60F2, so we'll launch all of them from FortiManager. Some will clean up the interfaces that are currently tied up with the internal switch on the 60F2. I've got another script that'll change the IP address on the management interface here to .59 instead of the default of 99. I've got another script that'll create the VLAN interfaces. I've got another script that'll go ahead and create a static default route leading to 23.1.2.1 as the next hop through the service provider, service provider A, and then once we do our scripts, let's go ahead and push out a firewall policy, and there's a few different ways of pushing out a policy to the firewall,

2:36so when we get to that point, we'll go ahead and look at our options, choose one, and then push out a policy list traffic from the internal network here, be routed out to the public internet, including using that, and then once we've done that, we'll go ahead and test it to make sure it all works. We'll put a client on this VLAN, the 1030.0 network, and verify that client can actually go through the firewall and get access to the public internet. So although we're doing this piece by piece here with the scripts and the policies and so forth, once we test everything, we know it all works, we can then combine that into an overall push in one fell swoop that can be done by FortiManager, but again, I'm doing it in smaller chunks so we can see each and every piece. So with this game plan in mind, in the next video, let's begin the configuration that we need to set up in order to do onboarding with low-touch provisioning for this brand new firewall. So I'll see you in the next video in just a moment.

0:00So before we do the 60F reset, let's go ahead over to Ford manager and let's tell it to prepare for this 60F model that's going to be coming online. So let's go to Ford manager and do the prep for onboarding that new 60F2. So we'll log into Ford manager by putting in our credentials and clicking login. We'll go into our eight on where all of our 40 gates currently are. Currently we have green across the board. That's great. So let's go to device manager and let's begin preparing for the new 40 gate that's going to join. And again, we're going to be using 60F-2. So a couple of ways of doing this. Number one, we can click on add device. And then here we just click on add model device right there to add a device that is not yet online. And then we can put in all the details here. So we can put in the name 60F-2. That's the firewall that 's going to be joining us.

0:45I do have the serial number. Let me go ahead and copy paste that in. So there's the serial number. And then we have all these options we could specify, including automatically linked to real device. So once it reports in, we don't have to do an extra step of authorizing it at Florida manager. It's going to be automatically authorized. We could force the specific firmware version. I'm not going to require that. We can enforce device configuration. Now this is a little bit scary because if we are pushing out something like a configuration that's going to cause our 40 gate to lose connectivity with Florida manager, if we say enforced device configuration, any kind of misconfiguration that we have that would cause that loss of connectivity, it's going to be able to go ahead and still be implemented, which means we're going to lose connectivity. So another great reason to make sure that our configurations and our pushes are going to be correct and make sure that the device being managed can still communicate with Florida manager after the configuration is done. So I'm going to go ahead and say, yeah, let's enforce device configuration. If we want to add the device to a group, we could. So if you have groups set up, you can add it. I'm not going to add this one. We could put it in a specific folder. So I'm going to choose, for example, the root folder. We could assign a fabric authorization template. We can launch a pre run CLI template that's going to run initially. So if we have them created, we could go ahead and select one. If you don't have one made, we click on the plus symbol and we could create one right here that we run as a pre run CLI template. So I'll click on cancel. I'm

2:03not going to run a pre CLI template. We can also sign a policy package. If we add a policy package ready and waiting to go for that device, or maybe it's using a policy package that's very similar to the other firewalls you have. So you could go ahead and copy one and assign it here. So if you want to grab a policy package that was appropriate, we could grab it from here. For the demo, I'm going to say no, let's not initially assign a policy package. And then we also can assign provisioning templates. So we played with provisioning templates in the past in previous sets of videos . So if we want to sign a system template, we can pick it, for example, how about change theme to Eclipse. We have also options for assigning an IPsec template. And these are IPsec templates from earlier in the course.

2:39If we have a static route template, we could assign that. Now, one of the things too is that if our static route template in this case is using some variables, we'd want to make sure that our device that we're configuring has those variables set up. So we can also go here to the edit used metadata variables. So currently, the static route template that we just assigned is using these two variables. So we'd want to make sure that we're also going to set up those variables for this new device as well. So to do that, we could go ahead and click on this icon for edit right here and set the mapping or we could click right here on the variable name. And that would take us to the variable itself.

3:14Then we can simply do a create new and add the mapping here as well. And that way, if we're rolling on a new device, we have five or six variables to set, we can easily do it right here. So I'm going to click on cancel. I'm also not going to do the default route right now. And the reason for that is I want to set up some VLAN interfaces, which I don't have set up yet. And we need those before we can actually do the static default route. But that's how we could go ahead and assign the templates. Now, if we didn't want to go ahead and do all the details here, I'm going to go ahead and click on cancel. Another option is to create a blueprint. And then as part of adding device, we can just refer to the blueprint. So to add a blueprint that we want to use as part of adding a new device, we go to this little down arrow key right here. So this is the add device button.

3:53And just to the right, there's a down arrow. And from there, we can do a device blueprint. So there aren't any by default. So we can create a new device blueprint. And let's call it a 60 f dash to blueprint. And then it's going to ask us for the device model. Now here , it's pretty important because not all Fortigate devices have the same type of interfaces and so forth. So we want to choose a 60 f and let me go ahead and grab it right there. And from here, we can now specify a lot of the same details that we did at the device level itself, except it'll be associated with this blueprint. So for example, we go down here to provisioning templates. Let's choose something safe for a system template. Let's go ahead and do change theme to Eclipse.

4:30And once again, we could choose any of the provisioning templates that we wanted to here. But I also want to make sure that they work individually before we start pushing out five or six templates, we need to make sure we have all the variables in place. So as a simple test, I 'm going to do a system template for change theme to Eclipse, and then leave all the others empty, click on okay. And then here we could also in this blueprint, we could send a policy package by selecting one, if we had one ready to go for this new device, we could do a pre run CLI template. And most of the other options that we had, we're configuring that device directly. Now, if we had like 20 or 30 60 Fs to hand out, and we wanted all of them to have this one provisioning template signed home, we could create this blueprint, I'll click on okay to save it. And now that we have it saved, I'll click on close. Now what we could do is we could go to add device. And once again, to add model device, but this time specify that we want to go ahead and use a blueprint. So use device blueprint, we'll go ahead and slide that over, then select the blueprint we want to use. That's when we just created. And then all those values that we just put in are going to be applicable to this new device. So it says that the blueprint platform 48 60 F doesn't match the serial number. That's because they haven't put it in yet. So this is going to be the new 60 F dash two.

5:39And then for the serial number, I'll copy paste that from my notes. There it is right there. And now it's no longer complaining about the serial number. Also right here, I can edit my variable mappings. So I click here on edit, and then currently I'm not using any scripts or any commands that require variables. But if I were, they would show up here, and then I could edit them, or if we want to go ahead and say, all, this is going to show us all the variables. And then once again, we could hear edit each of them and add the variables appropriate for the new 40 gate we're about to push out. So because I'm not using any in any of the scripts that I'm applying with the initial push, I'll go ahead and click on cancel there, and then click on next. So now it says 60 F dash two device is successfully added. So we click on finish there. Here is that 60 F two right there, it's showing that auto link status is enabled, meaning that if everything goes well, and this 60 F connects in with the right serial number, that it's going to be automatically authorized, we don't have to go in manually and manually authorize this new 40 gate. Now currently it's showing that the config status is modified. And let me go ahead and clean up the interface here a little bit so I can see the policy package as well. So I'll click on the gear , and let's remove a few that we don't need SD Wan manager, we don't need. I do want to see provisioning templates.

6:50I do want to see policy package status. I don't need to see upgrades status or firmware version or HA status or description or platform. And let's see how that looks. All right, that looks better. And actually, let me go ahead, and let me just cut you this over a little bit. So we can see over here in the provisioning template that we have a scroll over to the right. So we've got the change theme to eclipse provisioning template assigned to it because that was part of the blueprint. So now that we have 40 manager that's expecting this 60 F two with that serial number to show up the next video, we'll begin the low touch provisioning over at the 40 gate itself.

7:23So I'll see you in the next video in just a moment.

0:00So as far as our game plan goes we have configured Forda Manager to be aware of a new Fortigate that's going to be coming on board. We had some minimal templates we're going to push out to it initially. So now let's go to our 60F2. I've recently done a factory reset, so let's go in and just give it enough information so it knows how to reach Forda Manager. Which would be an example of a low touch provisioning. So the rest of the configuration, once this device checks in and registers with Forda Manager, the rest of the config we can do from Forda Manager itself, including using scripts, and anything else that's already associated to be run when that new Fortigate checks in.

0:34And here we go. So at the CLI I'm connected via the console. I did an execute factory reset, it rebooted, and now I'll go ahead and log in as admin. I'll press enter because there's no password by default. I'll specify a new password, then I'll confirm that password and away we go. So I'm going to use a copy paste option here for my minimal configuration on the Fortigate. Effectively I'm doing config, system, central dash management, set type forda manager, set the IP address for that forda manager, and also I'm specifying what the serial number is for that forda manager. So I'll go ahead and paste that in. And that's done. I 'm also going to go ahead and put on some debugging here, so we can see the play by play as the forda manager interacts with this forda gate. So I'm going to right click here and paste in these commands, which are basically a debug of the forda manager communications. So it is the fact that this is showing up here means that we have communication actively going on between this forda gate and the forda manager. So I'm going to go ahead and minimize this and let's bring back forda manager.

1:37So here's forda manager. So currently here showing modified for the config status. I'm going to go ahead and do a refresh of this page. And so now it shows conflict, but in the background, it is still cranking away. It's forda manager and this new onboard device getting to know each other and sharing information, including pushing this provisioning template change theme to Eclipse. So it looks like it's done. It says synchronized. We didn't push out a policy package. That's why it's showing it's never installed. But if we were to go to 192.168.1 .99, we should see the Eclipse thing being used on that device. So let's do that. Let's test that out real quick.

2:16So I'm going to go ahead and connect in. Now it's using its self sign certificate. I'll click on proceed. And so here just on the login screen is showing us that that's not the default j color scheme. It's the one that we specified as part of the onboarding of this new forda gate . So I just want to verify that the system template that we assigned was actually pushed. And this is visual confirmation of that. So we go back to forda manager. Here we have synchronized for the 60 F 2 and its IP addresses dot 99. And there's the template right there that changed that theme to Eclipse . Also, if we want to remove that, it's pretty easy to do as well. We just go to provisioning templates and we go to our system templates. And currently right here, the 60 F2 is associated with that provisioning template.

2:56So we can go ahead and click on the pencil there, just double click on it to remove it, click OK. And now that's not linked in or latched on to that forda gate anymore . However, the settings that it pushed, including the theme as part of that system template, if we go to the install wizard and we click on next, it's not going to try to push anything else. Not going to try to remove that system template theme change. So I'll click on cancel there. And let's go back to device and groups. So now that we've verified that we've onboarded the 60 F2 and it appears to be responding, we can right click there and do a refresh. And it's looking great. We'll click on finish.

3:27Also knows here because we removed the provisioning template from it that it's not showing here anymore. So in the next video, let's walk through some additional options we have regarding pushing configurations out to this newly onboarded device. So see you in the next video in just a moment.

0:00So, we've prepared forda manager to onboard the new 40gate, we also did the load touch provisioning on the 60F to effectively just tell the 40gate where forda manager was. Then the 60F2 was onboarded, one of the templates we pushed out was the system template with the theme change we verified that it took. And so, next, I'd like to walk through just using some scripts to do additional configuration on the 60F2. Now, when we are using scripts, we could also include these as part of the initial provisioning. But as I mentioned in the overview, it's often wise to do a little piece by piece until we know everything works and then we can put them all together.

0:34So, in this video, I'd like to demonstrate working with some scripts to make several changes to the 60F2, including changing the IP address from .99, where it currently is to .59 for the benefit of managing this firewall. So, back here in forda manager, as we take a look at our policy package status, we've got one there, if we click on the hyperlink, it'll take us over there, where we have a policy package never installed, I'll click on that for a filter, and this is our 60F2 right there. And that's because we didn't assign a policy package when we onboarded it as part of the blueprint or part of the onboarding.

1:06And so, that's why it still shows us not having a policy package yet. But before we do a policy package, let's take care of a couple other little things I want to on this device. And there's a few ways that we could accomplish that. One way is we could go in and go to the device itself, there's a 60F2, go to network and interfaces and specify the details here manually, or we get excited by things by using some scripts. So, what I'd like to do is make some scripts. So, under device manager scripts, let's click on create new and select script from the dropdown. So, for the first script, I want to do some switch cleanup and also specify an IP address.

1:38So, on a 60F, the first five interfaces, internal 1, 2, 3, 4, and 5 are all locked in and associated with an internal switch logically called internal. And I want to remove all that because I want to use some of those interfaces for other purposes. So, we could have some comments here, which are a great idea for yourself. So, in the comments, let's say remove internal 1 through 4 from switch and assign IP address .59. And then the type of script, we have CLI, Arginja. So, if you are a programmer, I want to use a lot of variable things, there's other options besides just CLI. But I'm going to use the CLI script. And then, where do we want to run this?

2:08Do we want to run this script against the actual device database, which would then require us to push out the config to the Fortigate or do you want to go ahead and run it directly against the device via CLI? And that's what I want to do with all these. I want to run them directly against the CLI on that Fortigate. So, with that set, I'll then go ahead and take my script and paste it in here. So, I'll go ahead and do a control V to paste it in and let's take a look at the detail. So, effectively, this is going into the virtual switch, editing internal, and removing ports 1, 2, 3, 4 from that logical internal switch.

2:42Then I'm removing the IP address from the internal interface, the logical internal interface. And then I'm going to internal 1, that physical interface, and setting up the IP address of .59. I'm also allowing Ping, HTTP, HTTPS, SSH, and access by Forte Manager. So, to help us in making sure the script is correct, we can go ahead and select the platform that's going to be run on. So, this is going to be run on a 60F. So, I'll search for 60F, select it. And then, in just a moment here, I'll have the option for Validate show up. So, I'll click on Validate, and that will go through, and it says Script Val idate with no errors.

3:16So, I'll click right here on Format, and that will format it for us to make it just a tiny bit easier to read. So, we'll go ahead and click on OK, and now that's saved. So, we can now use that. In fact, let's run these as we create them. So, I'm going to right-click on this script. We'll go ahead and click on Run Script, and then I'll select the 60F2 to running it. So, currently, it's at .99, and that's going to change once the script is done. So, we'll click on Run Now, it's asking us to confirm, we'll click on OK, and now it's running the script. So, if there's an error with the script, it's going to report it right here. If it runs successfully, that's fantastic.

3:47That's what we're hoping for. But again, if there's a problem or an issue, the logs are going to give you information on what went wrong. So, we'll let that complete, and it's done. So, if we click on View Details, and then click on the log information here, here's what happened, and there was no errors. So, this is the same place we go, by the way, if there were errors, it could show us what went wrong. So, we'll close that, and close that, and now, if we go to Device and Groups, and we go to our 60F2, and go to Network Interfaces, these four interfaces are no longer associated with that logical internal switch, right here.

4:19Also, we look at internal one there, and scroll to the right there, it has the IP address of .59. Fantastic. So, let's continue on with our scripts. Again, these are building blocks that we could employ together for the initial deployment to a brand new 40gate. And to make the same scripts work with lots of devices, we would just incorporate the use of the metadata and the variables. For the next script, I'd like to go ahead and create VLAN interfaces, so if we go back to this firewall, so that a device in groups, 60F2, network interfaces, now currently, it has no VLAN interfaces, but what I want to do is create two of them.

4:51I want a VLAN interface, V23, and a VLAN interface, V130, connected to those respective VLANs, and then have the IP addresses of 23.1.2.59 for this one, and the IP address 10.130.0.59 for this interface, I also want to enable DHCP services on this interface. So let's put a script in place that'll do that for us. So back here for the manager, we'll go back to scripts, and let's click on Create New, Script from the dropdown, and I'll just name this script VLAN interfaces. And in the comments, I'll put VLAN 23, VLAN 130, and DHCP.

5:25I want to be able to run this directly against the CLI of the device, and then I'll go ahead and paste in my script. So I'll go ahead and do a right click and a paste, and then I'm going to go ahead and choose the platform this is going to go on so I can do a test, 60F, and select that. And then in a moment here, I'll have the validate option, so I'll click on validate, and wow, where are my errors starting? So I'm starting right here, and it's because the config there is an uppercase. All right, let me go ahead and do a lowercase C, excuse me, and then let's go ahead and do a validate again, and that was it. So the initial config was uppercase C, it didn't like that.

5:56And this is the script checker here inside of for the manager. So on the physical device, if we're running a config with uppercase C, it may work, but here the validation checking, it didn't like the capital C. All right, so let's click on format here. So if we click on validate one more time, it validated with no errors. And just as a check here, we're creating this new logical interface, this VLAN interface. Here's the IP address, here's the VLAN it's associated with, we scroll down, we 're then creating a VLAN 130 interface supporting VLAN 130, there's the IP address there . We're also on that VLAN 130 interface, enabling DHCP services in this section right here, with the range of dot 101 through dot 254.

6:35And I'm not sure I need this wireless controller with profile delete default, because I'm not using wireless at all on that device, but I'm going to leave it in there. All right, so the big part here is configuring two new VLAN interfaces and configuring a DHCP server. So click on okay, and let's run that as well. So there's our VLAN interface script, we'll right click run script, and we'll double click on 60F2, there it is right there, and the selected entries, and click on run now. So then we're going to go ahead and confirm, we'll click on okay, and away it goes. So if there's a problem or an issue, we'll simply look at the logs, clean it up the way we need to, and then run it again.

7:10So that's really a good idea to make sure that our scripts or any other components that we're pushing out, make sure the individual parts and pieces work. And also, if you're doing a bunch of scripts or a bunch of templates that you 're pushing out all at once, make sure they all work together as well. So this script ran, so click on close, fantastic, and let's go back to device and groups, we're on our 60F2, and now it's got the two VLAN interfaces right there. And if we go into VLAN 130 there, that interface, and we scroll down, we also have DHCP services enabled, fantastic. So even though we ran that script directly on that device, because we ran it from four to manager, it automatically retrieved the updated information and synchronized it.

7:48So also just to help verify that the interfaces are correct in the right VLANs, let me right click, and go to remote access, and let's connect over to 60F2, login as admin, specify the password, click login, and, and, oops, I wonder if I bumbled the password twice when I initially set it up. So let's do this, let's reset the password using for to manager. So we'll go back to for to manager, and for the 60F2, we'll select it here, and then we'll go to system administrators, admin, double click on that, and let's reset the password, and I'll confirm the password, and then click on OK, and then we'll push it out with the install wizard, and next, and next, and install.

8:27If this works, I should be able to log back in to that Fortigate using the password I just set up for that Fortigate. All right, it's about done, survey says, it's a win, yay. All right, we'll click on finish, then we'll right click on the 60F2, and click on remote access, and now that I have a password that'll work, we should be able to log in locally. So we'll put in the username and the password, and click login, and I'm going to log in as read-only, that we don't accidentally make any changes, this is being managed by Fort manager. All right, it says unable to connect to Fortigate servers, that's because this bad boy does not yet have a default route, so that's a big part of the reason for that.

9:02So what I wanted to do is verify I can ping my service provider, and that's going to be at 23.1.2.1, oh fantastic, and also if we try to ping somewhere out on the internet, for example, ping out to 8.8.8 to 8, that's going to fail because we do not have a default route yet. So let's go back to Fort manager and continue our configuration. So let's create another script that will push out a default route, and again, there's lots of options, we have provisioning templates where we could include a static route. So a provisioning templates for static routes, for system templates, for BGP, IPsec, etc., that we could also use an initial deployment of a Fortigate.

9:38So I didn't use these options as we deployed it, but we can do it right now by going to scripts, and let's create a new script, so we'll click on create new script. So I'm going to call this one static default route, and I want to apply this directly to the Fortigate as well, and then we'll go ahead and paste in my syntax there, config router static, edit one, set gateway 23.1.2.1, we just verified we could ping that, and use the egress route by the interface of v2360F-2, and that looks great. So we'll click on OK, and then I'll go ahead and push it out. So we'll right click on the static default route, click on run script, select the 60F2, and then click on run now, and then we'll click on OK, and while that's running , let's go back over here and do a ping again.

10:16So we still can't get there, I pressed enter, but now that it pushed out the default route, we know how our route out to the public internet, and we are now able to get there. So we do an execute tracer out to 8888, it's showing us now the path, and it's taking a little longer because it's trying to do reverse lookups for each hop in the path. Let's want to verify that we have reachability to the outside world, now that we have a default route. So back at Forte Manager, that script completed, we'll click on close, and again these are building blocks and examples of what we can use to automate the process of bringing up the device.

10:47So instead of having to do these manually, once we had perfected our scripts and we perfected our provisioning templates, we could collect them together inside of a blueprint and then push everything all at once out to a device. But again, because each device may have different interfaces or different zones , we'd also want to have the variable setup and the normalized interfaces so that our scripts and our provision templates can be used across multiple devices. So now that we've run some scripts to create our VLAN interfaces and also sign the correct IP address, and also to go ahead and set up a static default route.

11:18In the next video, I'd like to walk through configuring some policy on this firewall so that clients on the 10-130 network can get access to the public internet going through our newly deployed firewall too. So I'll see you in the next video for exactly that.

0:00So it's now our opportunity to push policy out to this device. Now, as part of the preparation for that new 60F, we also could have included the details regarding VLAN interfaces and the default route and the policy in one fell swoop, as we pushed out our configuration to this device. And the benefit of doing this in smaller parts, especially on a brand new deployment, is that we can test each and every part first before we have them all together being pushed out simultaneously, because there's a lot that can go wrong.

0:30So by testing these individually, we can make sure step by step that they are working. And if there's problems, we can troubleshoot them as we go. So let's focus on getting a policy implemented here on the 60F2. So currently here in Device Manager, if we go here, there's a one device that's been auto updated. If we click on that, it'll hyperlink us over to device and groups to the actual FortiGate here, 60F2. And if we click on Manage FortiGates, this is our FortiGate right there. So the policy package has never been installed because we never assigned one. So if we had a policy package that was all set up and perfect for that device, we could have pushed it out when that device came online and registered with FortiManager.

1:07So if we go over to policy and objects and policy packages, currently we don't have a perfect policy package that we could have assigned. That's one of the reasons I didn't. So we have a couple of options. One is we could create a brand new policy package here or find a policy package that is very close to what we need and copy it and then assign it. Or we could just import the existing policy package that the firewall has and then modify it. It doesn't really matter which way we do it at this point. So let's go back to device manager, device and groups. Here is our 60F2.

1:38I'm going to right click on it and I want to go ahead and import the configuration, which will pull in whatever it currently has as its policy package. So click on import configuration and import policy package. It has no AP profiles or force which templates, but I'll check that anyway just so that we can confirm that as we import. We'll click on next. It's going to create a policy package name called 60F2. It's going to put it in the root folder. It's going to import all policies. Here's the normalized interface names based on the type of platform it is. We're also adding mappings for all unused device interfaces as well by leaving that enabled.

2:11And we'll click on next. It's going to do some checks and then we'll go ahead and click on next. So it imported some policies and objects. We'll click on next and it has no access point or force which templates. So there's nothing to select there. We'll click on finish and boom. We now have that policy package that has now been imported. So currently here we have a policy package which has been imported. That's what we did right here on 60F2. And we also have that same device that did an auto update. So now if we go over to policy and objects and policy packages and we go to the correct policy package here for 60F2, here it is, we've had this from internal to WAN1.

2:48We don't need that. I'm going to right click and delete that. Now we have the implicit deny. Now it's funny because it says implicit deny, but there it is. Looks pretty explicit to me. Anyway, let's go ahead and create a firewall policy that we can use. Actually, before we start modifying it, let's go ahead to the install wizard and push out the change that we just made, removing that first rule. So we'll go ahead after the checks are done and click on install and then we'll create our own rule. So we'll click on install and away it goes. We'll let that finish in the background. So let's go ahead and create some rules here for 60F2.

3:20So we'll click on create new and create new rule. And let's call this in to out, meaning traffic coming in on its internal interface as the V130 and going out of the V23 interface. So we want to say accept or permit and the incoming interface. We'll go ahead and let's look for V130. And there I have one right there. That's the V130 60F2 as a mapped interface. We can go and check on that real quick. So that interface name right there maps to this right here. So we can go ahead and use that. That's why I confirmed the mapping was correct.

3:52So we'll go ahead and select that as the incoming interface. And then for the outgoing interface, let's go ahead and look for V23. And there that one is right there. So effectively, this rule may go ahead and check the previous install. Great. That completed. I'll click on finish and close that. So this is the traffic coming in on the V130 interface and being routed out of the V23 interface, go ahead and accept it. Then we can put the criteria here, including the source address, destination address, the layer four protocols and ports. And for the demo, I'm going to leave all this wide open and go ahead and click on OK. I'll add my change note and click on OK.

4:24So then we can go ahead and push this out with the install wizard and click on next. And if we want to install preview, it's not a bad idea just to confirm what's about to be pushed out. So we should have a brand new firewall rule that says into out traffic coming in on the V130 interface and going out of the V23 interface, go ahead and permit it. And there it is right there. It looks great. I'll close that and we'll click on install. And that looks like it is good to go. All right. Status OK. Click on finish. So now if we go back to device manager and take a look at 60F-2 right here, it should show that the device database is synchronized with what the FortiGate has there and also the policy packages shown right here is also synchronized.

5:05So our next step then is to go ahead and test this. And I propose we test it by putting a client right here on this 10.130.0 network in VLAN 130, make sure it gets an IP address and then make sure that device can actually get out to the public Internet using the rules that we set up here on the FortiGate. So we'll do our testing and troubleshooting in the next video. So I'll see you there in just a moment.

0:00For our testing as I mentioned in the previous video, let's put a client right here in v9-130, make it a DHCP client, and make sure that it can get out to the public internet . Because if it can, everything works, that means our configuration is good to go here on the 60F2. If not, if there's a problem, we'll troubleshoot it together. So here is a client that I just powered up. It's a DHCP client that should be on the 10-130 network, and let's just verify it got an IP address, and we can do that with the command on this Linux computer, the command iF config. So we'll open up a command prompt, we'll type in iFconfig, and sure enough, 10.130.0.101, fantastic. We know DHCP is working, let's do a ping out to, how about 8.8.8.8. All right, so a ping out to a resource like 8888 by IP address, and I know that's available because that's an anycast address for Google DNS servers, it's not working. And so the fact that it's not working means that we have some problem or issue with our 4-to-gate right here, which is preventing the client here from getting out. So, using 4-to-manager, let's begin our troubleshooting. We already verified that the client was able to get an IP address, we saw that on the client, so DHCP is working. Also, what we could do is just

1:15verify, and then do a control C here, let's verify that we can ping our default gateway. So our default gateway would be 10.130.0.59. We can verify that with a route, space dash, and which says don't bother doing name resolution. So there's our default gateway 10.130.59. So a ping to 10.130.0.59. And sure enough, we can ping our default gateway. That's a good start. So something in the configuration of 60F2 is not correct, let's troubleshoot. So back to 4-to-manager we go, and what's the first thing we should take a look at. Well, we know that the 60F2 can ping the internet itself.

1:55We also know the client can ping the VLAN 130 interface. So let's take a look at our firewall policy. So we go to policy and objects, policy packages. We'll go to the one that 60F2 is using, so that's this policy right here. And there's our policy into out, let's take a closer look. So traffic coming in on this interface, and being routed out of this interface, regardless of source or destination IP address or protocol, please allow that to go. That's the acceptors right there. If we scroll down, it's flow-based, that's fine. This is a 60F, which has like around two gigs of RAM, so it really can't support proxy-based.

2:29So flow-based is no problem. If we scroll down, I'm using all the defaults here. And what are we missing? Oh, I know. How about this little thing right here? Going back to my discussion about troubleshooting next generation firewalls. It's often based on some issue with wrap. The R is for routing. We already have a default route, so we know the firewall itself can route out to the public internet. Permissions, as far as this firewall policy goes, are wide open, but we don't have address translation because this is currently not enabled. So let's enable address translation as part of this firewall policy rule. Another option is we could go back and configure this to be using centralized source net. And then we could create a separate source net policy.

3:11However, because we're using the net as part of the firewall rules, let's go ahead and simply enable net, take the defaults there and click on OK. So for our change note, we'll say enable net on the firewall policy rule, click on OK, and then we'll go ahead and push it out. So go to install wizard. There's our policy package name, 60F-2. Click on next. It'll do some checks. We can also go ahead and preview before we push out the change, which I think is a good idea occasionally, just to make sure that if we're pushing out incorrect information, we can be aware of that before we do the final install. So here's our preview of what's about to be pushed out. And sure enough, here it is.

3:46That net enabled. Okay. All right, so we'll click on close there and click on install. All right, so as that's being pushed out, let's go back to our client and our client here. If we do a ping out to 8888, this is going to be a continuous ping here. And now they're working because it just kicked in with the net. And the net was at least one of our missing pieces. So do a control C there. Fantastic. And let's open up a browser just as a final test. So open up a browser and let's go out to fast.com, which simulate which simulates Netflix traffic.

4:18Let's go to YouTube. Oh, it can't do it. Why is that? We can get to the internet. Let's go back to the command prompt here real quick and let's do a ping out to 8888. Yep, that's working. And let's do a ping out to www.fordnet.com and that all name resolutions failing. That's a bummer. We can fix it though. Let's also do an NS lookup, www.fordnet.com press center and sure enough, yeah, DNS is failing. So the way that this device is learning about its DNS servers is via DHCP. So let's go back to the configuration here for the 60F2. So back to device manager, device and groups. Let's grab 60F2. And with it selected, let's go to network and the DHCP services are implemented on the VLAN interface. So we'll click on interfaces. There's our V130 interface. We'll double click on it and let's scroll down and take a look at the DHCP. So DHCP is enabled. And that's working. We're getting an IP address. Oh, look at this DNS server. Specify. And so we said same as system DNS. That would work or who had to specify a DNS server. Let's go ahead and do that. Let 's put in a Google server of 8.8.8.8.8. And click on OK. And that we made that slight change. Let 's go ahead and do the install wizard and do device settings only. Click on next. And once

5:36it does its checks, let's also do a preview of the install just to confirm it's going to the DNS server information. And there it is right there. Fantastic. So click on close and we'll click on install and let's bring back our client. So back at our client, let's set the up arrow key for an honest look up still failing. So we'll go ahead and give that a moment more. But once it finally gets pushed out. Oh, also, I might have to tell the client to re get the IP address via DHCP. So let's do that as well. So doing I have config to see the information. So this is the interface ENS 33 on this little VM. So I'm going to do a pseudo I have config for that interface. I'll go ahead and copy and paste that so I don't have a typo space and I'm going to say down. It's going to ask me for my password, which I'll put in. And then I'll go ahead and bring it back up with a pseudo I have config ENS 33 up. And that will renew the IP address as well as any new information regarding a DNS server. So now if we hit the up arrow key a few times, then it 's look up for www.fordnet.com. Sure enough, we're now getting IPv4 information, a records and also quad a records regarding that URL. Fantastic. So now that we have corrected that problem, let 's go back to our browser. I'll close the browser. Nice fresh start. Go ahead and open the browser again.

6:50And let's try going to fast.com. And that seems to be working. And let's test one other side as well. It's got a YouTube and that's working as well. Fantastic. So I go ahead and close that, minimize the client, click on finish there. And so as we push out devices, we have lots of tools that we can use. We can use provisioning templates, which includes static routes, system templates, IP sectanels and more. We could use scripts. And we could also go ahead and use blueprints. So to get to blueprints, again, use that little drop down next to add device blueprint. And then specify the details you want for a new onboarded device, including which templates to use and so forth. Apply that here. And then as we create the new device, for example, add device and add model device. And I'll call this one ZTP or LTP FGT 9, because with zero touch provisioning, it'll automatically find out where Ford manager is through cloud services, or its light touch provisioning. And then from here, we can put in the serial number for that new device, or if when he's a pre shared key, we can do that two, three, four, five, six, seven, eight, nine, just make sure you use that same pre shared key on the device that's being onboarded. And then we could choose that blueprint that we just created. So we say use device blueprint here, then select that blueprint. And hopefully that's the right blueprint that we want to use. And then we get edit the variable mappings as well as part of that to make sure we have variable mappings for

8:06any variables included in any of the scripts or the provisioning templates we 're about to push out. And if we have a specific dashboard that we want to copy over and have for that device, we can grab a dashboard from one of our existing devices and use it there as well. So I'll go ahead and grab that dashboard that's being used here, click on next and then click on finish. And then we have this device right here with this crazy name ZTP or LTP FGT 9 and Ford manager is waiting for that device to show up and check in so it can push out the configuration and settings to that device. So because I don't have that FGT 9 coming in, I'm going to right click and say delete that.

8:40And okay. And now it's removed. And for the 48 that we did do, that was this 40 gate right here, the 60 F dash two, which now has a configuration also has a policy package associated with it. And based on the testing that we just did from the client is able to successfully forward traffic from that client out to the internet and allow that client to get a response.

0:00As we wrap up this set of videos regarding zero and low touch provisioning for a FortiGate firewall, I'd like you to list the following. I'd like you to list the components that can be used at the FortiManager to automatically configure a FortiGate when it does come online and connects to the FortiManager. So take a moment right now, pause the video, think about the various options and components we can use to automatically configure a FortiGate that comes online. Then when you've had a chance to think about that and remember a few of the components, go ahead and click on resume and we'll discuss a few of those components together.

0:32And welcome back. So let's discuss a few of the components that we can use for deploying a FortiGate with a lot of automation. One of those is to use a blueprint. And that blueprint is going to be model specific. So you may have a blueprint, for example, for 60Fs. You may have a blueprint for 100Fs or other models that you're going to roll out. And as part of that blueprint, you can include a lot of details that you want to have set up for a new device. So in our example, we used a 60F for the blueprint. And one of those items that we can include as part of the blueprint is to specify a pre-run CLI template. And think of a pre-run CLI template as one time only. So it runs initially, and then it's no longer linked or associated like other provisioning templates with that firewall. But at the same time, you can have that pre-run CLI template run and anything you want to set, you can run as part of that CLI template. We can also, as part of the blueprint, associate any provisioning templates that we have created.

1:23And as far as provisioning templates go, we've had experience in previous videos with many of those, including IPsec Tunnel and BGP and system templates. In our demo, we used a system template that included changing the actual theme for the interface on the FortiGate. We also have static route templates, there are CLI templates, and more. So any of those that we have set up, we can associate with the blueprint, and then we can tie that blueprint to a new device that's going to be onboarded. So if we have a blueprint, the way we use that is we go into device manager, we click on add device, and then under add device, we choose the option of add model device. And as part of that configuration, we can refer to this blueprint that will pull in all these values that we have specified for the new device that we're adding.

2:05And as you add that new device, we're going to include the serial number of that device, or the other options to use a password. And if we enable auto-link for it, when that device comes up and registers with FortiManager, it'll automatically be authorized, and we won't have to go in separately and manually authorize it if we use that auto-link option. Another component we can use, in addition to CLI templates, is we could also use scripts. And we may have scripts for specific models, like for 60Fs, or for branch offices, and so forth. And that way, if we have our scripts set up, we can include those scripts as part of our deployment, and then use them over and over again. And one of the tools that lets us use a same script over and over again is the option of using metadata and variables. Another option that's going to help us use scripts across multiple devices is normalization. So we can have normalized interfaces and normalized zones. And that way, we can have a script that calls upon a normalized interface or a normalized zone. And then when the actual deployment comes down to that specific device, it'll use the variable there. And then when FortiManager is deploying it, if we're deploying it to firewall X, for example, and we have these values set up with per-device mappings, when it comes out to pushing that device, let's say it's device X, it'll use the per-device mappings for interfaces and zones associated with device X. Also, as part of adding our devices, there's an option for setting those variables right there. So you can go ahead and look at

3:21all the variables and then set those variables that you need to that are specific for this new FortiGate we're pushing out. And one other element, if we have a policy package that's perfect and ready to go for this device right here, we can also push out as part of the onboarding, we can also push out a policy package. And that policy package can be included as part of a blueprint, or we can actually include it as part when we do the add device. But just be aware, if we're pushing out a policy package and we haven't yet configured the interfaces or the zones or other dependencies that that policy package needs, it's going to fail. So we want to make sure that when we're pushing our configurations out, that we are doing it in the correct order. Because it's hard, for example, to set up a static default route with an egress interface of VLAN 23, if we don't yet have the interface VLAN 23 set and configured on that device. And the most direct way of finding out what those orders are, making sure they all work is to do individual pieces, step-by-step in a test environment, making sure that for a certain platform, you have all the pieces you need. And then once it's perfect, quote unquote, you can then set up your variables and start pushing everything out at once to new FortiGates as they come online. So thanks for joining me in this set of videos regarding automating the process of deploying a new FortiGate.

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