Building a Fortinet SD-WAN Lab

0:00[AUDIO LOGO] Hello, and welcome. My name is Keith Barker. And the offering of SD-WAN, Software-Defined Wide Area Networking, from Fortinet, leveraging FortiGates, is a fantastic offering. However, to get it set up, we have to have some type of gear, whether it's physical or virtual or a combination of both. So in this set of videos, I'd like to watch you through the basic infrastructure setup for our lab environment.

0:30And then with that in place, in our subsequent sets of videos, we can go through the details of the implementation, verification and troubleshooting when necessary of SD-WAN in a Fortinet environment. So join me in the next video as we take a big-picture look at the world of SD-WAN from Fortinet.

0:00[AUDIO LOGO] It's often helpful to have kind of a big-picture understanding of what a feature or function or technology does. So in this video, you and I get to take just a few moments and chat about the big-picture idea behind SD-WAN in a Fortinet environment. So let's imagine that our company has a location. Let's call this the main site. And this main site could be, for example, our headquarters location. Or it could be the location of our big-data center.

0:30So let me go ahead and make that our site. We'll put a little rectangle there. And at that site, we have some internal networking going on. Maybe this is the 10.10 network here. And then for connectivity to the outside world, in a Fortinet environment, we're going to be using a FortiGate. So I'll put a FortiGate right here. If we wanted some fault tolerance, we could do high availability. And before we put the WAN connectivity in, let's also go ahead and draw a second site. This could be a branch office or a remote site. So I'll label this remote/branch. And at that location, they've also got some networking. So perhaps this is the 10.20 network address space they're using down here.

1:04And for our connectivity to the rest of the world, we'll draw another FortiGate down here at this branch office. So we'll call this up here FortiGate 1. We'll call this down here FortiGate 2. And let's also draw a cloud that represents the internet. And on the internet, there's tons of service providers that can act as ISPs to be the on-ramp or the connectivity point between a location like the main site or the remote site and the internet. So let me go ahead and draw some service providers here. So I'll go ahead and put one in blue here. We'll call this SP-A for Service Provider A. Let's do another one for service provider B.

1:39So there's service provider B. And for good measure, let's also bring in service provider C. So that's service provider C right here. So these three service providers can be options for connectivity from the main site over to the internet and from the branch office to the internet. And in addition to just internet access, we could also purchase some connectivity services from a provider that would lead to the internet or that can have these two sites connected together. So let's imagine that this represents an MPLS cloud. And MPLS stands for Multiprotocol Label Switching. And so service providers can use that and then logically provide circuits between various locations that they both support.

2:16So if the main site and remote site both want to use the service provider and MPLS services, that is yet another way for some wide area network connectivity. So the headquarters site to get to the internet, perhaps we have a FortiGate connected to this service provider, service provider A. And if we want some fault tolerance, we don't want to rely on just one service provider. And we have multiple options. We could also have another connection to another service provider. And assuming we had multiple service providers available and we had a budget for it, we can also use the third one. And for the MPLS connection, we could also have a connection there as well. So at the remote branch office, it's not likely to have all those connections.

2:49For example, they may be using service provider A and then have the MPLS as an alternate path. So let's imagine we have a user down here on this 10.20 network. In fact, let me connect that FortiGate to that network. There we go. And let's also draw a little computer here at the branch office. So with this networking that we've currently drawn with our service providers, including one providing MPLS services, this represents our infrastructure for the wide area connectivity. Through service provider A, I'll go ahead and color code that. Or service provider B, color code that. And service provider C. Or leveraging the connectivity provided via the MPLS.

3:22And we can refer to that connectivity as the infrastructure or the underlay network. And the actual term underlay, if we're not going to do anything else with this, really is kind of a waste of words because it's just the actual network that's forwarding the traffic. However, what we can do on top of this is we can logically overlay a different logical topology. And the reason it's important to bring up the concept of underlay is because we're allowed to take a look at a concept where we're going to put on a different topology on top of this infrastructure. An example would be a set of VPN tunnels using IPsec.

3:55And effectively, what we're doing is we're overlaying on top of our infrastructure. We're overlaying this logical path with the VPNs. So let's take a look at examples of both. Let's imagine that we don't have any VPNs that are currently in use, and we have this client here at PC1 that's going to the internet. That traffic would be forwarded to its default gateway. That firewall would make a routing decision, forward it out to service provider A, who would then forward it out to the internet resource. So that's the path the traffic would take from this PC going to this server. We'll call it server 1. And then when server 1 responds, the response would come back this way through the internet, through the local service provider, and then forwarded down the FortiGate, who would then forward the response back to the client.

4:32However, we could set up the routing and IPsec on top of this so that clients' traffic from PC1 going to the internet server, instead of going directly out through the service provider, logically could go through a tunnel. So I'm going to color code it here. This represents our IPsec tunnel. And then the FortiGate at the main site would go ahead and make a routing decision and forward it out one of the paths going out to the internet and to that server. Perhaps, in this example, we're using service provider C. And then the response will come back up to the FortiGate at the headquarters site. And then the response would be encrypted and sent back down to the FortiGate at the remote branch office, who'd then decrypt it and forward it over to the PC.

5:10So that's an example of an overlay network where we're intentionally putting on top of the existing infrastructure an IPsec VPN tunnel. So the traffic patterns and the logical topology changes based on using the naked or raw infrastructure and the underlay network as a transport network versus using the VPN and IPsec as an overlay. And here's a secret. If we are using our IPsec overlay, behind the scenes, we're still using the infrastructure to actually move the packets. So it's the infrastructure network that's moving the traffic from FortiGate 2 up to FortiGate 1.

5:42And at that point, they would be encrypted IPsec packets. And it's the infrastructure that's supporting the connectivity from FortiGate 1 out to the internet through service provider C. So I'll make a little note here that the overlay network uses the infrastructure or underlay network. And oftentimes, that's referred to also as the transport network. So the transport network is the network that actually forwards the actual packets along their path. So that means that layer 3 is making routing decisions. At layer 2, it's making forwarding decisions based on the layer 2 frames. So whenever you hear the concept of infrastructure or underlay or transport networks, think of like the raw, normal networks that are forwarding packets and frames along their path.

6:21Now, depending on how we implement our WAN connectivity here, sometimes we may have this FortiGate go directly out to the internet, like just using the underlay network and just forwarding it directly without forwarding it up to the headquarters site first. And when that FortiGate is providing direct internet access for its users, that's referred to DIA, Direct Internet Access. The alternative to that would be to go ahead and require traffic for this PC, if it's going to the internet, to actually be sent up to the headquarters site via a tunnel. And then the FortiGate at the headquarters site could go ahead and forward it out to its final destination using the overlay network.

6:54So when the network is configured so that the PC going to the internet has to be tunneled up to the headquarter or main site first before it goes out, that's referred to as Remote Internet Access, or RIA. And when we're doing a remote internet access, that also implies that we're leveraging our overlay or VPN network to go ahead and pull that off. So one of the questions that often comes up is, OK, why? Why are we sending this PC's traffic all the way up to the FortiGate at the headquarters site before we're sending it out? Why not just go ahead and use direct internet access instead of remote internet access?

7:25And the answer is, for security. So perhaps at the main site, we're doing tons of security checks. We have really tough firewall policies and, associated with those policies, security profiles implementing application control, URL filtering, antivirus/antimalware support, intrusion prevention services, data loss prevention. And the list goes on. And that'd be a fantastic reason to forward all the traffic with the remote internet access up to this site first before forwarding it out. And this IPsec VPN tunnel that goes between FortiGate 1 and FortiGate 2 here, it doesn't have to use the ISP A.

7:58We could also do an IPsec tunnel that way using the MPLS network, if the traffic needs to go between FortiGate 1 and FortiGate 2. So it has options. So regarding this PC's traffic that needs to go out to the internet server, we have a few options. One would be to go ahead and use ISP A with direct internet access. Another option would be go ahead and send traffic through the VPN tunnel up to the main site to FortiGate 1, who would then forward it off to the internet. And that would be referred to as RIA, Remote Internet Access. And then a third option could be actually using the MPLS network also with remote internet access.

8:32And in that case, the client's traffic would be forwarded through the MPLS connection between FortiGate 2 and FortiGate 1. And then once again, at FortiGate 1, it would look at the traffic and then make a forwarding decision out to the internet. And for that connectivity from the client out to the server, perhaps we're using software as a service, maybe some mission-critical application that's being hosted in the cloud. The client's simply accessing it via the browser. Maybe it's something from Salesforce. Or maybe it's Office 365 or some other internet service. One of the cool things about software-defined wide area networking is that we can configure rules and performance standards which will dynamically control which path we're going to take-- direct internet access going up through the tunnel or going up through the MPLS network to our headquarters site and then being routed up to the internet.

9:19And by performance, I mean we can look at things such as jitter and delay and packet loss. And in a Fortinet environment, those are referred to as SLAs, for Service-Level Agreements. And then we can have rules that specify, OK, if this user is going out to a specific application or a specific service, we only want to use paths that guarantee a certain level of service between that client going out to the services. So perhaps from FortiGate 2's perspective, our cheapest internet option is ISP A. So perhaps we specify that we want to go ahead and use our VPN over service provider A for our preferred path for that client going to that specific application on the internet.

9:56However, if there's degradation on that path or it's not meeting the service-level agreement, then we can specify in our rules that we want to go ahead and as a second-place winner regarding the SLA being met, we want to use the MPLS. So the traffic would be forwarded over the MPLS network up to the main site who'd then route it out. Now, if there was a problem with the MPLS network or if there's a problem with the headquarters site, we can also specify, in third place, direct internet access. And that way, this FortiGate could go ahead and do direct internet access through the service provider to allow this client to go ahead and access that application on the internet.

10:29Again, that could be Salesforce or Office 365 or some other software as a service that is being used by this customer. And the cool thing about these rules and these SLAs is that they're dynamic. They can monitor the traffic. And they can look at jitter, delay, and loss, and as a result, pick the appropriate path to forward the traffic. So one of the reasons it's called software-defined wide area networking is that we're setting up the rules and the policies. And then based on the conditions, the software that we configured is going to control which path we're going to use through the network-- and in this example, based on service-level agreements being met regarding jitter, delay, and loss.

11:04So with this big-picture overview regarding SD-WAN in mind, in the next video, let's turn our attention to the basic infrastructure that we can use as part of our transport/underlay network that we can then use as part of our lab. So I'll see you in the very next video as we put a lab design together. Until then, I hope this has been informative, and I'd like to thank you for viewing.

0:06In this video, you and I get to put a design plan together for our lab topology. And for this lab design, I want to focus on the underlay network here, which can also be referred to as the transport network. And so for the lab design, I'd like to go ahead and use four locations. And so for the first location let's go ahead and put a FortiGate here, and let's call this DC as in Data Center 10. We'll call that FortiGate DC-10, to remind us that it's at a data center at location 10. And let's also create a second one. We'll call it DC-20.

0:37So there's another little FortiGate right there, and we'll label that DC-20. And let's have a couple of remote sites as well. So let's go ahead and down here let's use site 30, and that way for me it'll be easier just to remember 10, 20, 30, and 40. So let's call this one site-30. And also at one other remote site down here, we'll call this site-40. And each of them have a local network or two attached, so let's just draw this here to represent that on each one of those sites. And while we're at it, let's put in some IP dressing plans as well.

1:09So the data center 10, let's use 10.10 a 24-bit mask, and a site-20, let's use 10.20.00, with a 24-bit mask, and the site-30, we use 10.30.0.0. And any guesses for site-40? You got it 10.40.0.0, with a 24-bit mask. And we'll also put at least one device that we can work with on each of those networks. And in the lab environment, I'm going to need to be able to manage all these. So I'm going to also put each of these devices on a little management network, which I'll just draw right here.

1:42That way, I can locally get to each one of them, and that management network is my home office network, which has the 192.168.1 address space. So let me make a little legend over here for the management network. It's the 192.168.1.0, and on that network I've got my management PC, the one that we're going to be sitting at to manage these devices. And I've also got on that management network a FortiManager that we can also use if we want to do centralized management of these firewalls. And let's also go ahead and put some internet connectivity in here.

2:15So the big cloud represents an internet as a whole, and let's also identify a few service providers. So we'll have service provider A, I'll call it SP.A right there, and service provider B, and service provider C. Let's also imagine for our lab environment, we want to have a separate path using MPLS, Multiple Protocol Label Switching from a service provider. So I'll go ahead and put that here MPLS, and for not having to draw on top of each other, I'll also go ahead and put one over here as well. MPLS. And let's say we're using service provider D for that.

2:47So I'll go ahead and put a D there as well. And I'll put a D there just to realize it's the same service provider. And then for connectivity between the data centers and the remote sites and the service providers and MPLS, I'm going to use a lesson my mom taught me many, many decades ago. And that is you might want to bring a sweater or jacket because you can always take it off. But if you go and you don't have the jacket, you can't put it on. And so we may or may not be using all these service providers and the MPLS from every FortiGate, but what I want to do is configure the FortiGate, so they have those connections ready to go.

3:20So if we need them, we can just enable them and be good to go. So on DC-10, we're going to have A connection out to service provider A. I'll go ahead and color code that and to service provider B, I color code that as well. And service provider C, we'll color code that, and we'll also have a connection going out to our MPLS provider. So all of those wide area network options will be available to DC-10, and we'll do the same thing for DC-20. It'll have an MPLS connection to the MPLS network provided by the service provider, and we'll have an ISP A connection and an ISP B connection and an internet service provider C connection as well.

3:57And at the remote site, site-30 and site-40, it's not likely in a production environment that we're going to have three different ISPs and an MPLS connection. But what I'd like to do in preparation for being able to use any of these services, is I'd like to go ahead and also configure site-30 and site-40 with the same connections. So again, like my mom said, it's not required to use them, but if you have them, then you can use them if you want. So I'll put the connection here for service provider A and service provider B and service provider C, and the same thing here at site-40, service provider A in blue, service provider B in pink, and service provider C in red.

4:34And then the green one represents the connection to the MPLS service. So what we're building here or designing is the underlay or the transport network, and then once it's in place, and then we start working with IPsec and sd-wan and the rules and so forth, we can then steer and control the traffic over this transport network. So let me also share with you a few components that we'll be using to pull all this off. Starting off, we have some physical firewalls. And in my lab, I've got a set of 60 fs running the latest and greatest version as of this recording of the FortiOS.

5:05To provide the virtualized environments for these PCs that are going to be connecting and sending traffic through the Fort gates on the back end, I'm using ESXi, which is the hypervisor from VMware. So my management PC right here is going to be physical, but the FortiManager and these devices hanging off of these respective networks, those are all going to be little VMs running as part of VMware. I also want the ability to go ahead and control the delay and jitter and packet loss through these various internet service provider connections.

5:37In my lab environment, what I used to do that was I used Eve-NG. And instead of Eve-NG, I've got a switch and also a router, and I've got four separate links, one for each of the service providers, and I've also got one for the MPLS network. And so in Eve-NG, there's an option to actually inject jitter and delay and cause one of these circuits to be less desirable quality-wise than another. And that way we can play with that and tweak it, and I'll show you how I set that up as well, as we proceed through this set of videos. So as far as what we need to configure in this topology to get it all up and running on the FortiGate, let's go out and do a factory reset.

6:13And that way we know what we're starting with. Also in these FortiGates, I'd like to use centralized Source NAT. So that way we'll have a separate policy. For Source NAT it won't be integrated as part of the firewall policy. And then on these firewalls, we'll need to carve out the interfaces. So for simplicity, let's use internal 1. That's one of the physical interfaces on each of the FortiGates, and that physical interface is connected to in my lab environment, a switch where it's doing trunking. So on that physical interface, we'll carve that up for management, meaning we'll give it the 192.168.1 address space, and for DC-10, let's just use .10 everywhere.

6:48For DC-20, we use . 20. For site-30, we use .30 and for site-40, we use .40. And then for all the other interfaces, the local area network here and the three service providers and the MPLS connection, on the FortiGate, we'll just create VLAN interfaces for each of those. And just a little note for my self, service provider A is VLAN 23 with the 23.1.2 address space, service provider B is in my lab environment VLAN 24 with the address space of 24.1.2.0 also with a 24-bit mask.

7:20Service provider C is VLAN 25 with an IP address space of 25.1.2.0, and last but not least, I've also set up the MPLS connection in my lab environment, and that's using VLAN 26 and that address space is 26.1.2.0. And so the IP address is for each of these service providers is going to be a .2 on each of these networks. So for example, service provider A would be 23.1.2.2 as the next hop there for that service provider.

7:50So I'll make a note here. This can be .2 for the last octet for each of the interfaces on all the service providers. Also in this underlay or transport network, if we want traffic to flow through the firewalls, we are going to need to have some policies, and because we're using centralized Source NAT, that would include network address translation, and also firewall policies for permission. Another core piece of the infrastructure is to make sure that routing is in place. So in our basic infrastructure here, prior to implementing any type of sd-wan features, let's just use service provider A as the one and only next hop our default static route.

8:24So that means that DC-10, DC-20, site-30 and site-40, just initially, are going to have their next hop as 23.1.2.2 as the next hop for their default route to get out to the internet. And then later as we begin to implement the sd-wan components, we'll set up our sd-wan zones, include the members, we'll change the routing at that point. But for the initial base configuration, we're going to use service provider A as the single service provider for all four sites. So now with our lab design in place, let's go ahead in the next video, and let's tackle DC 10 by starting with a factory reset, and then walking through the steps of setting up its interfaces, the policies, and the routing to get DC 10 in our topology.

9:06So we get to 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[MUSIC PLAYING] In our previous video, we put together a plan for our lab topology. In this video, we're going to start our configuration with DC-10. So as we turn our attention here to DC-10 in our topology, let's also just do a quick recall of what we need to do. So we're going to go to factory reset, enable centralized source NAT, create the interfaces, set up the policies and the routing so this PC can get to the internet. And we're going to leverage service provider a.

0:31So behind me in the rack, I've got a FortiGate model 60F. And I've also got a computer connected to it with a console cable. So from this computer I'm sitting at, let's RDP over to that device, and via the console cable, do a factory reset of this firewall in preparation for setting it up as DC-10. So here's that firewall. A few moments ago, I just did an execute factory reset. I confirmed. And it has wiped the config. And it's rebooting as a brand new firewall ready for us to configure. All right, so go ahead and log in as admin.

1:02There's no password by default. So we'll set one. Press Enter. We'll confirm that password. Press Enter. And we are good to go. So we should also be able to connect on the GUI to the default IP address on this platform, which is .99. So if we wanted to confirm the address, we can do a get system interface. And press Enter. And there's the IP address right here. So this IP address is being used on this logical interface called internal, which, on this platform, includes the first five interfaces: internal 1, 2, 4, and 5, all part of this logical internal network.

1:34So we should be able to connect to it right here, at this IP address of 192.168.1.99. Let's give that a shot. We'll log in as admin with the password as specified. And with that password supplied, we'll click on Login. I'll make this a little bit bigger. I'll click on Begin. We'll go ahead and call this DC-10. So I'll type in DC-10. Click on OK. Now, I plan to use Internal 1, that physical interface, and then on that physical interface, configure the management IP address. And then under that physical interface, set up all the VLAN interfaces as well. So to do that, I need to go to Network right here and click on Interfaces.

2:08And go to this Logical Interface called Internal. And I need to tell it that it doesn't get all these interfaces. So I really just need interface 1 not to be part of that internal logical switch. And in fact, while I'm at it, I'm going to go ahead and say, I don't need any of these. Now, I'm currently connected on internal5. That's physically how I'm currently connected. So I'm going to go ahead and disconnect that. And let me go ahead and just tuck in some interface because it needs some interface there. I'll give it wan2, which I'm not using. Now I'll click on OK. Now, I'm going to lose connectivity here because I was connected on port 5. And that is no longer a part of this logical internal interface with the IP address that I'm currently connected to.

2:42So I'm going to go ahead and close this browser because that's not going to be too helpful. Let's go back to the command line. And let's proceed with some of our initial configuration there. So I'll do a config system interface. And let's go ahead and do a show. And what we want to do is I want to take this interface right here, internal 1, which can now be used as a regular layer 3 routed interface. And I want to put the IP address of 192.168.1.10 with [INAUDIBLE] on this interface. So we'll type in edit internal1. And then we'll do a set ip. I also just realized that if we try to put on the IP address of 192.168.1.10, we've already got an IP address on the logical internal interface on the 192.168.1 network.

3:22So before I do that, let's go back in. With config system interface, let's edit internal. Let's do a quick show. So there's the IP address. And what we'll do is a unset of IP. So now we've just removed the IP address off that logical internal interface. So we do a show. Looks good. We'll type in end. Now we can go to internal1 and put an IP address on that same subnet. And we'll use .10. So we'll do a config system interface. Let's edit internal1. That's the first physical port. Let's do a show-- fantastic, and a set ip.

3:54And we want that to be 192.168.1.19 with a 24-bit mask. And that will be our management interface. And we also should allow some access. So let's do a set, allow access. And let's allow HTTPS and some ping. And in case I try to connect with HTTP, I want that to go ahead and redirect over to [INAUDIBLE],, which it will by default, as long as I allow HTTP. Let's also allow SSH. And we can add more later if we want to. So let's do a show real quick, verify our settings. And we'll type in end. And now we should be able to connect to this device at that management IP address.

4:27So let's verify that. We'll bring up a browser. And I just realized something really important. And that is, there's no connectivity on port1. Currently, I have a cable connected to port5, internal5, on the firewall. And we just configured internal1. So let me walk back to the rack. Let me go ahead and put it in the cable to port1. And then we'll come back here and check it out. All right, so I just plugged that in. So it may take a few seconds on the back end switch for spanning tree to allow forwarding of traffic on that port. And so we'll give that a few moments. And then we'll go ahead and click on Reload. And that looks better.

4:58So even though it's a certificate warning, at least we're connected to that firewall. And it simply because the CA who issued the certificate that the firewall is using by default isn't trusted by my computer-- no worries initially. So we'll click on Advanced. And we'll scroll down and click on Proceed. We'll log in as admin. We'll specify the password that we set. Press Enter. And we are now logged in to DC-10. So actually, let me go ahead and log out here now that we have the basic settings up in place. And I'm going to go ahead and close my remote desktop session. And I'll connect from my PC here, over to 192.168.1.10, which is the physical internal1 interface that we're going to be using for management for DC-10.

5:37So we'll log in from my management PC. All right, so let's get to configuring. A couple of things we wanted to set were, I want to go down to System Settings. And I want to specify that, for this firewall, I want to use Centralized Source NAT. So we'll go ahead and enable that. I also want to change the timeouts on my lab environment, so I don't get logged out all the time. And we'll click on Apply. And let's go to Network and Interfaces. So here I have internal1, which has the management IP address on it. And let's carve out interfaces that we're going to use for the network behind DC-10, the 10-10 network, which we're going to use VLAN 10 for that.

6:10And let's carve out the interfaces for the three service providers as well as our MPLS service provider. So as a reminder, let's take a look at our topology here on DC-10. We're going to have connections to service provider A, B, and C, and also to the MPLS service provider. So those would be VLANs 23, 24, 25, and 26. I color-coded them down here. And those are the appropriate network address spaces. So when we create those sub-interfaces on DC-10, for the last octet, we'll use .10 everywhere on DC-10 for those four network connections.

6:41And for this network up here, north here of DC-10, that will be VLAN 10 in my environment. So it looks like we need to carve out five VLAN interfaces, four for our WAN connectivity going through MPLS and three service providers, and also one to support this VLAN 10 up here. So with that in mind, let's go back to DC-10. And let's make some VLAN interfaces. So we're going to be using internal1 as the physical interface. So we create the VLAN interfaces because internal1 is physically connected to a switch. And that switch is doing trunking for all those other VLANs.

7:12That's what makes this possible. So internal1 will be the physical interface used for management. And the VLAN interfaces will be used for everything else. So we'll click here on Create New. From the dropdown, we'll click on Interface. And let's go ahead and name this VLAN 10. And the parent interface that's supporting this new VLAN interface is internal1. That's where our trunk is. And the VLAN ID is going to be 10. And that is going to be a LAN interface. And the IP address that we're going to use up there is 10.10.0.10 with a 24-bit mask. And we'll allow PING there.

7:42And let's also enable DHCP services for clients who connect there. And let's start at .101 in our pool of addresses. And then I'm going to scroll down in my lab environment. I'm also going to set a really short lease. Now, one of the questions might be, Keith, why in your lab are you sending your lease time to super low value like 300 seconds? And the reason is I may change things. So if I change things up, I don't want to have a lease that was handed out to a client like two days ago still hanging around. I want these devices to actively check and renew their leases frequently, that way if I make changes, those changes will be updated and known about sooner than later on those devices.

8:17That looks great. So we'll click on OK. So now under the internal interface, we have VLAN 10. So now, let's make one for the three service providers, VLANs 23, 24, 25, and also our MPLS service provider. So we'll click on Create New. From the dropdown, we'll click on Interface. And let's call this ISP_A. And then just for my own benefit, I'm going to put VLAN 23. And that way when I see it, I'll remember exactly what it is and where it is. So that's going to be a WAN interface. And the parent interface for that is internal1.

8:48That's carrying the traffic. And for the estimated bandwidth, I'm going to start off with 1,000, and 2,000 for the ISPs, for upstream and downstream kilobits per second. And the IP address for VLAN 23, for the service provider A, is-- let's take a look at our drawing here. It's going to be 23.1.2. And on DC-10, that sub-interface, that VLAN interface, is going to be .10. So here, for the IP address, it will be 23.1.2.10 with a 24-bit mask. And we'll go ahead and allow a PING on that interface.

9:18And that looks good. So we'll go ahead and click on OK. Oh, and I forgot to put the VLAN ID. It says VLAN 23. So we'll add that. Then we'll click OK. And now we have our first service provider. So we'll simply repeat that for our service provider B and C using their respective network address spaces of 24 and 25. So we'll click on Create New. From the dropdown, we'll click on Interface. We'll name this ISP_v24. And the parent interface is internal1. And the VLAN ID is 24.

9:50It's a WAN interface. And its IP address is going to be 24.1.2.10 with a 24-bit mask. And we'll enable PING on that interface-- very good for connectivity testing. And we'll click on OK. All right, let's do the third service provider, service provider c. By clicking on Create New, from the dropdown, clicking on Interface, we'll call this ISP_C_v25. The physical interface is internal1. And the VLAN ID is 25. And that is a WAN interface.

10:21And its IP address is going to be 25.1.2.10 with a 24-bit mask. And we'll allow PING on that as well. And click on OK. So let's check our work. I've got service provider A, B, and C. They're on VLANs 23, 24, 25. And the address space is 23, 24, 25. That all looks great. Let's add one more for the connection to our MPLS service provider. So we'll click here on Create New-- Interface. And let's call this MPLS_vlan26. And the parent interface is internal1.

10:51And the VLAN ID for that in my lab environment is 26. And it also is a WAN interface. And its IP address is going to be 26.1.2.10 here on DC-10 with a 24-bit mask. We'll allow PING there as well. And click on OK. So let me just check our work here real quick. And that looks great. So we have our VLAN interface for our internal network behind DC-10. And we have our three service providers. And we have the MPLS connection as well. So if we take a look at our checklist, what is next on DC-10? So we enabled Centralized Source NAT.

11:23We carved out our interfaces. Next, we need policies for network address translation and also for permissions for traffic from that 1010 network to go out to the internet. So let's set up our NAT and firewall policies next here on DC-10. So to do that, we'll go ahead and collapse Network. Go to Policy and Objects. Let's start with our Centralized Source NAT by clicking here on Central Source NAT. And click on Create New. And the incoming interface is going to be traffic coming in on the VLAN 10 interface. And for the outgoing interface, initially, for our basic config, let's just use Service Provider A.

11:57And then we'll tweak and modify that as we build our [INAUDIBLE] together. So for the moment, it'll be Service Provider A and the source address. Let's lock that down to just VLAN 10 traffic. So here's an address object for that right here. So we'll select that. And for the destination for the NAT policy, they can be going anywhere-- fantastic. And effectively, that's going to do port address translation, mapping clients source IP addresses to whatever it happens to be on that external or egress interface, which is 23.1.2.10 here, through service provider A. So we'll click on OK.

12:27So now we have our NAT policy. Let's go ahead and set up permissions with our firewall policy. Also, what I love to do here in our firewall policy is I like to go ahead to the Implicit Deny. And in my lab environment, I'm going to say Log all IPv4 Violation Traffic. That way, we have nice clean logs of everything that's going on. And that's really helpful for initial troubleshooting. So we'll click on OK. I'm going to take this fun rule right here from internal to Lan1. I'm going to right click and delete that. We don't need that. Click on OK. And let's create another policy that allows traffic from VLAN 10 to go out to the internet.

12:58So we'll click here on Create New. Let's call it VLAN 10 to Outside. And the incoming interface would be our VLAN 10 interface. So we'll select that. The outgoing interface in our current topology is going to be just Service Provider A. The source IP address space is going to be the 10.10.0 network. So there's an address object for that right here. So we'll go ahead and choose that address object. And the destination could be anywhere because the internet's a big place. So we'll say, All There. And regarding what protocols or services they could use, I'm going to leave it wide open there as well.

13:30The action is Accept or Permit. And by default, it's flow-based, which is fine. And the one other change I'd like to make here is I'd like to log in All Sessions. Again, that's helpful in a lab for troubleshooting. And we'll click on OK. All right, so we have our new policy in place. And for the last piece here, we also need to set up routing because unless Firewall 10 believes that it should forward traffic out through Service Provider A, it won't. And so if we want our NAT policy and our firewall policy to be effective and be used, we also need to have routing in place.

14:01So let's set up a static default route here on DC-10 that says, hey, your default route should use the next hop of 23.1.2.2, which is Service Provider A. So back at DC-10, let's go back up to Network. And from the Network section, we'll go to Static Routes right there. And with Static Routes selected, let's add a new default static route that's going to use Service Provider A the next hop address there. So we'll click on Create New. And the Gateway Address is-- on Service Provider A is going to be 23.1.2.2 And if we press Tab, it's automatically going to select the egress interface.

14:36And that's because the next hop address here, 23.1.2.2, is on the same exact subnet as this interface ISP A_v23. And that's why it auto-populated for us. We'll leave everything else, including the administrative distance, at their defaults. And click on OK. So let's make sure we have all the pieces in place here on DC-10. We have the intro one, physical interface, that's connected over to a physical switch with trunking. So that physical interface is being used for our management interface at 192.168.1.10. That's how we're currently connected to DC-10.

15:08And then beneath that, we carved out logical VLAN interfaces for each of these service providers and also one for VLAN 10. We also set up the Source NAT policy and also the firewall policy to allow the traffic from VLAN 10 to go out to the internet through Service Provider A. And we also put the routing in place with a static default route telling DC-10, hey, if you ever need to forward traffic to a route that you don't know about, go ahead and use Service Provider A's next hop address at 23.1.2.2. So with all of that in place, what's left?

15:39Well, we should probably test it. So that's what you and I get to do in the very next video is verify our connectivity and do any troubleshooting if necessary for the basic infrastructure of this underlay network. So I'll see you in the next video in just a moment. Until then, I hope this has been informative. And I'd like to thank you for viewing.

0:00[INTRO MUSIC] Now with DC-10 configured, I want to take a moment in this video just to verify that traffic can actually flow from devices in VLAN-10 out to the internet using service provider A. So in a moment, let's put a client here on this network and test and verify that the client here on 10.10 can actually get out to the internet via service provider A. But even before we bring a client, there's also a test we can do right here at the FortiGate just to verify basic connectivity.

0:32So let's do that first. So here at that DC-10. This is a SSH session I have over to the Management IP address on DC-10 at 192.168.1.10. And so from here, what we could do is we could try to ping each of our service providers. And so just basic connectivity testing would be great. So let's go and do that. Let's do a ping to 23.1.2.2 press Enter. [LAUGHTER] I'm so excited about the ping, I forgot the execute. So execute ping to 23.1.2.2 press Enter.

1:03OK, that works, fantastic. So here from DC-10, we could also execute ping to www.fortinet.com. So what that's going to do, is going to go ahead and use DNS on the outside world. So that alone is verifying connectivity. And if the pings are then successful, that also means our traffic is being forwarded out through service provider A because that's where our default route is. So we'll press Enter. And that is working. Looks great. So we do a get, router, info, routing-table, and let's go ahead and do all and press Enter. There's our default route going through service provider A.

1:35And that's what's providing us connectivity to the outside world. So the final test here would be to bring up a PC here on VLAN 10 and verify that computer, by using the Central Source NAT and firewall policies, also can get access out to the public internet. So here's my ESXi host, which behind the scenes is providing a lot of this virtualization. And let's go down to Networking. And let's go down to my port group for VLAN 10. So as far as which devices, I've actually got a Windows 11 computer that's currently on VLAN 10. Let's use it. It's sitting there.

2:05So we'll go ahead and power it up. And I'll also go ahead and open up a console to that device. So go ahead and open a remote console. And we'll give that about a minute and a half to boot up. And as that power is up, that represents this little computer right here on the 10.10 network. So I'm going to go ahead and bring it over. So here it is let me go ahead and log in. So here on the client list, lets do an IP config just to verify our IP addressing. So we're on the 10.10.0 network. Our host address is 101, assigned via DHCP. In fact, we can confirm that with an IP config. So a dash all or slash all, either way is great.

2:36So the IP ipconfig/all shows us additional details, including our DHCP server address and our DNS servers. So from here, if we did a ping out to www.fortinet.com and press Enter, that looks pretty good. So we have name resolution that's working, fantastic. And we also have four out of four pings that were successful going out to the internet through the firewall. So let me go ahead and minimize our client. So in this video, we verified a path from DC-10 to the internet through service provider A. And then, leveraging the policies, including source NAT and firewall policies.

3:08We also verify that this client has access out to the public internet. So now the DC-10 is all set up. We're going to do the same exact process on DC-20 and also site-30 and site-40 with the exception of changing the last octet for each of their individual IP addresses. But the process of the VLAN interfaces and the NAT policy and the firewall policy is all the same. So I'll do those three in the background to get them ready. So in the next video, let's turn our attention to behind the scenes. What I'm going to be doing that's going to be able to help us influence the traffic flow through the network.

3:42And that's going to leverage on the back end, a little software application to have running called Eve-NG. And we'll take a look at how that's all put together in the next video. 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:06When designing and putting together this lab, I thought to myself, self, wouldn't it be great if we could influence, in our lab environment, if we could influence the links for the various service providers? For example, maybe adding 100 milliseconds of delay through service provider A or adding some packet loss, a little bit, not a whole bunch, but a little bit through service provider B, or setting up additional jitter through service provider C. So to do that, I had to get a little bit creative. And in this video, I'd like to walk you through behind the scenes with exactly what I did. So let me start by drawing out our ESXi hypervisor that I'm using.

0:39So I'm using one of my servers. It's ESXi three. It's a Dell rack server. So I'll label that right here, ESXi. That's from VMware. So I've got a couple of virtual switches that are in play inside of the ESXi hypervisor. So let me go ahead and draw those out right here. There's one of our virtual switches. And let's call that vSwitch A. And we'll call this other one vSwitch B. And think of these virtual switches as just a logical layer two switch with the ability to carve out VLANs. And the mechanism that is used to carve out individual VLANs and then assign VMs to them is the use of port groups.

1:14So I'm going to go ahead and just jot out PG just to remind us that, inside of each of these switches, there is one or more port groups. So on this switch, I made a poor group for VLAN 10. So I'll go ahead and put V10 there. So once we have this port group set up, if we want to spin up a new VM like this one right here that's sitting currently in VLAN 10, to put them in VLAN 10, we take this network interface card for that VM. And we'd associate it with this port group that's in VLAN 10. And poof. That little machine is now in VLAN 10. So I'll go ahead and draw that little VM connected here. And this is a little computer at 10.10.0.0101.

1:48It got the first IP address handed out from the DHCP pool. And then on this virtual switch inside the ESXi host, I also created individual port groups for each of these service provider networks. So that would include a port group for VLAN 23 going through service provider A and a port group for service provider B, which is VLAN 24, and a port group associated with VLAN 25. And I also created a port group to support VLAN 26, which is going to be used for MPLS. And over here on switch B, I have just one port group that is supporting the native VLAN.

2:21It says VLAN one. But there's no tagging involved. It's just like normal native traffic without any 802.1Q tagging at all. And that represents my home network of 192.168.1 with a 24-bit mask. And because there's interaction between the devices in this virtualized switch environment and the physical world, let me also go ahead and share with you a couple of physical switches I have here in my home office. So there's one switch. And here is another switch. And I'll label those as physical switch A and physical switch B.

2:53And the connection between these virtual switches and the physical switches are through physical network interface cards on the ESXi host. And logically, I've got one connection that goes from this virtual switch out to the physical world. And that's using a network interface referred to as a VMNIC in the world of VMware ESXi. And then I've got a separate VMNIC that's supporting any connections from this virtual switch out to this physical switch. So this may be VMNIC 0. And this one may be VMNIC one. And they're connected to ports down here on the physical switches.

3:25And on switch A, this port is configured as a trunk. Meaning it can do 802.1Q tagging as it sends frames for specific VLANs. And it receives frames with 802.1Q tagging. It knows how to process those as well. And then over here on physical switch B, because I'm not using any trunking up here, I'm not doing any trucking down at this physical switch either. So this physical switch and this virtual switch are just carrying the basic VLAN one traffic, nontagged. And also to make this picture complete, I also have a connection between these two physical switches that allows the VLAN one traffic to go ahead and go across.

3:59So it's not trunking all the VLAN traffic from this switch over to this one, but it does allow VLAN one traffic between the two virtual switches based on this physical connection here in the physical world. So let's bring in a FortiGate, a physical FortiGate. This will represent the one that we configured a couple of videos ago. So I'll draw that right here. And that physical FortiGate has a physical connection into a physical switch. And let's go ahead and put it on this port right here on physical switch A. And this port is also configured as a trunk port. And on the FortiGate, I'm using the physical interface internal one.

4:30So on that internal one interface, I have the IP address of 192.168.1. And on DC 10, it would be .10 on my management network. And then leveraging that physical interface, I then created the VLAN interfaces for all the other VLANs, including an interface for VLAN 10 and one for VLAN 23 and one for VLAN 24 and one for VLAN 25 and one for VLAN 26. So the little virtual machine that we plug into this port group for VLAN 10 is logically on the same network as this VLAN 10 interface over here on the FortiGate.

5:04Next, let's chat about we can route on this FortiGate out to the physical world using service provider one. Currently, this FortiGate, DC 10, has a default route with the next hop of 23.1.2.2, which is our ISP's address up here in the service provider network. So where is that next hop address in our topology? Well, that's a little router, a little virtual router right here in my virtualized environment that is connected with one interface to the port group of VLAN 23. So here's our router for internet service provider A.

5:35And Its other interface, I placed here on switch B, which is going to the native VLAN. And then in addition on this router, I set up network address translation. So it takes all the traffic coming in that source from the 23 address space and nets it out on this interface, which has a 192.168 address. And then on my physical network, I've got a router at .1 that is once again also doing network address translation before forwarding that traffic out to the real internet. So all that was well and good until I thought to myself, you know what? I want the ability to go ahead and modify the quality of the service prior links.

6:08So if service provider A or B or C is having like excessive delay or excessive jitter or a whole bunch of packet loss, how do I simulate that? And the answer is to integrate an additional virtual machine. So let me clean up this internet ISP router for a moment. And let me introduce a new virtual machine. And that virtual machine is EVE-NG. EVE-NG is a network emulation tool. And so in EVE-NG, we can run devices like Palo Alto firewalls, checkpoint firewalls, FortiGate firewalls, Juniper firewalls, et cetera.

6:42So inside of this VM called EVE-NG, I have yet another router. And let's go ahead and call this R2. And inside of EVE-NG, which is now running this little virtualized router, I have associated that router with its interfaces here in VLAN 23 and here in VLAN 24 and here in VLAN 25. So it has three logical interfaces. Now, the benefit of doing that is that in EVE-NG, we can go to any one of those links, and we can specify the quality of that link. We can introduce delay or jitter or packet loss real time.

7:14And that's the benefit of adding this additional complexity of adding an EVE-NG machine and associating it with those three networks. And then for routing traffic out to the real internet, it also has a connection here to my 192.168.1 network and that port group on the second virtual switch. And once again, router two is doing network address translation, so that any packets coming in from IP addresses in this source address space of 23, 24, or 25 will be netted out to this IP address on the 192.168.1 network and then forwarded down to the real router, which is a .1, who, once again, is doing network address translation before forwarding that traffic out to the public internet.

7:51So let's take a look at EVE-NG and this little router R2 that's currently running and its connectivity to these three networks and also its connectivity out to the 192.168.1 network. And behind the scenes, this EVE-NG is running as a virtual machine inside the ESXi hypervisor. So here in ESXi, here is the EVE-NG machine. And if we look at its network configuration, it has one interface that's connected to my management network. And then it has four more network interfaces that are connected to the logical port groups representing VLANs 23, 24, 25, and 26.

8:24So for the lab environment, I'm only connecting and using VLANs 23, 24, and 25 from this router that's running inside of EVE-NG. So inside of that VM EVE-NG, this is the graphical user interface connected to that VM. So inside that VM, I'm running this virtual router, R2. And it has three interfaces. And on those three interfaces, I have IP addresses configured for the 23.1.2, 24.1.2, and 25.1.2 networks with .2 being the last octet for each of them.

8:54So that way, our FortiGates, when they're pointing to the ISPs for A, B, or C, if they use the next hop of .2 effectively, they're going to be using this router as their next hop address. And then here, EVE-NG, I've got three clouds that represent those three network interface cards that are directly connected to the port groups representing VLAN 23, VLAN 24, and VLAN 25. So this router is performing network address translation. It also has a static default route going out to the next hop address at 192.168.1.2.

9:25And that router at .1, as I mentioned, is also doing address translation before forwarding that traffic out to the public internet. And the whole reason I added this additional layer was because I want the ability to influence the quality through service provider A, service provider B, and service provider C. So if we bring out a client, so this represents a PC sitting up in VLAN 10. It's a little virtual machine. If we do an IP config, we can confirm its address. It's at 10.10.0.101. So this PC is using DC 10 as its default gateway. And DC 10 currently has a static default route with the next hop of 23.1.2.2, which is R2's interface on gig 0/1 on VLAN 23.

10:05So if we were to do a trace, so we'll do a traceroute -d for don't bother doing name resolution. And let's do a trace out to 8.8.8.8. What we should see is that the first hop in this path should be the FortiGate at 10.10.0.10. And then the next hop should be R2's interface right here, which is at 23.1.2.2. And then the next hop beyond that would be my other internal router here at my home. With an IP address of 192.168.1. And then after that, it goes out through the real service provider network out to the final destination through the internet. So let's give that a test by pressing Enter.

10:37And here we go. So the first hop is the FortiGate DC 10. The next hop is this router at 23.1.2.2. Then it goes out to my other external router here at my home, which is 192.168.1.1. And then it hits the service provider network. And then off to the rest of the internet. So the delay here was all under 20 milliseconds. So what we could do here in EVE-NG is we could take this link, and we could right click on it, and. And the dropdown, we could click right here on edit quality and down here, we could introduce delay and/or jitter and/or loss as part of that connection.

11:10So let's go ahead and, as an easy test, let's add 100 milliseconds of delay. So EVE-NG is going to artificially inject that delay on all traffic that's going over this link between VLAN 23 and the interface here on R2. So let's bring back our client and test it. My hands never left my arms. We'll go ahead and hit the up arrow key, press Enter. And what we should expect to see is that once we start crossing that link now the delay is over 100 milliseconds for each and every one of them.

11:40So we'll let. That complete. And then also as a test, let's go ahead and set it to 50. I just want to see how accurate is. Still, serve me as well. So let's go ahead and click on Apply and bring back the client. So now the delay should be increased by 50. So we'll hit the up arrow key, press Enter. And here, we go there we go 53, 55, 60, 62, et cetera. And that looks great. So the beautiful thing is we can manipulate these values of delay and jitter and loss. And then we can see, in real time, how SDWAN and the rules that we have set up adjusts to the traffic flow based on the rules we have in place.

12:14So my friend, the cat is out of the bag. This is the detail on how we're going to inject delay and jitter and packet loss as part of testing and working with SDWAN. So thanks for joining me in this set of videos as we've set up a basic foundation for an SDWAN lab. And I'll see you, my friend, in the very next set of videos very, very soon. Until then, I hope this has been informative, and I'd like to thank you for viewing.