How to configure SD-WAN on Fortigate

sd-wan or software-defined networks for a long time companies relied on hosting applications and services in their own data center this is also called the private cloud and relied on expensive connectivity methods like mpls circuits or dedicated wan circuits to have connectivity to these data center hosted applications but nowadays internet connections are getting much cheaper and much more reliable than ever before and therefore more and more companies are moving into sas or software as a service applications and more cloud services we can even see new startups that have older infrastructure built on public clouds like aws and azure and they have no private cloud whatsoever and therefore having a reliable connection to these services is very important for your employees and your clients i want you to take a look at this traditional network diagram with one endpoint windows pc connected to a 40 gate this 40 gate have redundancy when it comes to internet so it has a primary internet connection and it has a backup internet connection assuming an issue with the primary internet connection cannot reach a specific sas application or a cloud service that your company or work relies on for example if the internet connection cannot reach google suite so your employees can no longer access their email in the cloud but because the fortigate is only blindly looking at the link status for its connection to the primary internet and the pc it has no idea that this service is not reachable and it would still keep sending traffic through the main primary internet connection even though the final destination service is not reachable that's why the concept of software-defined networking was introduced in this case the firewall goes beyond looking blindly in the linked status and it tries to actually send a probe or health check to the final destination service to make sure it's reachable via a meaningful board or service for example dns http or bing and in this case if the 40 is not getting a response from the final destination it would decide to disable this primary internet link and would move all traffic to the secondary internet connection which is a smart decision these health checks are also called performance sla and this is not something new we already seen health checks before in the 40 gate load balancing video and with low balancing firewall would send probes to the back end servers to decide which servers are healthy and are able to process traffic and therefore decide to send traffic to it as a part of a low balancing method so sd1 works in the same way and it does these performance sla as fast as every half a second so this is a very reliable service that will provide advanced reporting and login for all these health checks result and decisions for which links to use based on your preference now once you enable sd-wan all the individual boards that used to be named with numbers like port 1 board 2 will change into an sd1 zone and these ports will be sd1 zone members and therefore you have to update the firewall policy and route table to change from the old board numbers to the new sd1 zone so now let's get into the practical part of things and let's see how we can deploy an sd1 in our network i will be using the vmware workstation version for the fortigate vm to demonstrate the sd1 lab for you so i'm going to start by downloading the fortigate version 7 ovf file and i'm going to start deploying the 48 vm using vmware workstation and there is no more creative name to call our vm than 48-sd1 i'm going to start importing my ovf file and that's the vm that i created for the fortigate sd1 before we turn it on let's update the interfaces usually it comes with 10 interfaces and we don't need that many we just need three boards to be able to exactly replicate the topology i showed you earlier so i'm going to remove all the extra necks and i will keep the first network adapter or board one set to bridge the second network adapter i want to change it from bridge because we cannot have a duplicate subnet so we're going to change one to net which should make it a little bit slower than the bridge network but at least we'll be in different ib networks i'll be able to replicate dual internet connections using these tunics and the third nick would replicate our private zone so we're going to create a lan segment which is very appropriate to create an isolated network inside vmware workstation so we're going to go to lan segment and we're going to say private network so this will be my lan segment and i will join the third interface to this lan segment this way all my interfaces are correct and we can finally power on this vm so now my vm has finally booted i'm going to log in with admin and no password which is the default login and right away it will force me to change the password because right now it's empty so try to make a secure password that is not easy to guess now once you are inside the firewall we're gonna try to get the ip address of the interface so we can access the gui and know which ib addresses we got so i'm gonna go ahead and use the command git system interface physical and this way is the fastest way to get the interface ip so we can see here we got 172.20.0.21 on board one which is the bridge network and this is my bridge network which my pc is connected to we can try to go into the interface to make sure it accepts the management through the gui so we're going to use config system interface and we're going to edit board one let's do a show on this port we see in here it accept bing https ssh and 40 gate 40 manager now as you know the 40 gate trial vm does not allow https which is a major downside but we still have to enable http to access this interface through the gui so i will update the allow access on port 1 interface to allow http ssh and bing we don't need https because it doesn't work in the trial vm and then to update these settings we just need to do next so now port 1 has been updated let's go into board 2 which should be my net network let's also do a show on this one you see in here this interface is not defined doesn't have any configuration so i'm going to go ahead and allow to get a dhcp ib for the net network now if you are not familiar with the net network and vmware the edit menu you will see in here the vmware network editor now these subnets are randomized and generated when you first install vmware so in your case it will be different but i just know that the net network where i join my board 2 will get an ib address from the network 192 168.44 24. so i'm going to go ahead and use the command set mode dhcp and this way it can get the ib address automatically and we'll also allow to get http ssh and bing the same way they do board one so instead of writing the command again i'm just gonna use the up arrow to find the command that i use earlier and i just apply it to this port too then we're going to do next to get to the last port which is board 3 and because port 3 is a lan segment it has no dhcp running by default so we're going to configure it but it should be much easier to do from the gui so for now we're gonna go ahead and end all this interface config let's double verify the interface ips get system interface physical as you see my board 2 already got an ib address from the net network 192 168.44 that 136 and the first network on bridge still have 172.20.0.21 so let's try to access from the go and make sure these fortigate interfaces are reachable so i'm going to go ahead http 172.20.0.21 this is board1 interface ip i'm getting the 40 gate set up so let's give it a host name also now in a dashboard setup i'm going to go ahead with the comprehensive which shows me most of the dashboard pages and i like this option more and as you see this is my board 1 interface i'm able to get into the 40 gate let's also verify the second board 192.168.44.136 and i'm able to log into the second interface as well so now we can use either interface management console to update board 3 which is going to be our lan segment so i'm going to go ahead to the network interfaces and this is my board 3 so i'm going to go ahead and set a manual ip address on this network you can use whatever you want so i'm just going to use 10.20.30.1 25. so this is a small network and we're going to use this to replicate a private network connected to the sd1 we're also going to enable bing ssh as you see there is no http option in here but we do need to have it on all interfaces we already have two ib addresses with http so this is good for us we're just going to enable dhcp server so that computers or clients connected to board 3 can get an ib address from this network you can see in here the best part about using the gui for this is because it automatically detects the possible ivs in this range and it just assign it for us and also assign the netmask and the dns server so everything works out of the box we're just gonna click okay now we have our third interface configured with an ib address and dhcp server now to emulate a client connected to this network i'm gonna go back to my vmware workstation and we're going to choose any random vm that we already have for example i have this windows 11 vm i'm gonna go into this vm settings as you see i deleted all the network adapters i'm gonna start from scratch build a new network adapter this network adapter i want to make sure it's connected to the lan segment private network so this way the traffic can be booted in this land segment to board 3 in the 48 and then it can be sent to the internet through board 1 or board 2. i'm just going to check the ip address using ib config all and you will see in here i got the ib address 10.20.30.2 from the 40 gate so this means the 40 gate has successfully given the ib address to the windows 10 vm via the board 3 dhcp server also when we refresh here we should be able to see that we have one client connected so now let's head into the route table to see how network flow would come from the board 3 or the private network to our dwell when links i'm going to go into dashboard routing monitor and you'll see in here there is two default routes one for board one and one for board two and they both have the same distance so these two default routes are considered ecmp or equal cost multibatch routing and we also have the connected route for both one board two and board three so now let's go into network and start configuring our sd-wan zone there is a default sd1 with the name version one link but we're going to create our own sd1 zone and we're just going to call it when in this case click ok so now we have our zone let's start getting into the members so our first member will be board one which is the main or the primary internet connection we're gonna join this to the when sd1 zone as you see it also allows us to give a specific cost we're just going to enable it with the default cost and then we're going to create our second sd1 member which is the backup internet connection this will be board two and this will join also the one is the one link which is currently up because it has interfaces that are up so you'll see in here both interfaces are part of the sd-wan zone named when so now let's go back to the monitoring for the routing and suddenly our default routes have disappeared that's because board one and board two no longer have their own entity they are now part of the sd1 zone so we have to go into static routes and just create our own static route or default route to go into the sd1 zone so i'm gonna choose the interface sd1 and we'll click ok so now we have added the sd-wan interface as a default route let's verify if the route has appeared in our route table and you will see in here it brought back the gateway ips and the interfaces as part of the sd1 zone so now everything is good we just need to create a firewall policy to allow the private network to have communication with the outside now incoming interface will be board three our private network and the outgoing will be our when is the one zone now for the source for the simplicity i'm just gonna choose all and board three already have the specific network 10.20.30.0.25 so it should allow this slash 25 network only and we're going to allow it access to the internet so all ip addresses and for service we're gonna allow all services so this is a typical internet policy with some protection on it maybe ibs and antivirus and we're gonna log all session and just save so now our internet connection should work for the windows 11 client and the private network we can verify this and we do indeed have internet connectivity from our private network so now we're going to start creating our performance sla this is how we till the firewall which services means something to us and how often to check for it and on which service so from here we're going to go back to the network sd1 and we're going to go into performance sla by default or gate already have some pre-configured slas like connectivity to the aws console the system dns which is in this case configured as the 40 guard services maybe a website for 40 guard gmail google office we're going to create our own specific setup so we're going to create a new filter or performance sla maybe we are depending on google dns in our network and we want to make sure google dns is always reachable for our internal clients so we're going to call this dns we're going to choose the service dns that already exist and we're going to specify which ib address to check for so in this case let's do 8.8.8.8 this is google dns and from here this is the participant or the sd-wan members to choose we're going to choose all sd-wan members to run this performance sla on all boards now we put the optimal numbers we want for the latency jitter and bucket loss to define what is considered healthy in our network so for example the latency since i'm using vmware i'm going to bump this l bit because it will be a little bit slower for example i'm going to put 150 millisecond as the latency threshold for jitter maybe i'm gonna change it to 50 and back at loss of only one percent so if the traffic on either links is not satisfying these numbers it will have a lower chance for traffic to be routed to it and we're gonna keep the check interval to 500 millisecond which is every half a second so this is very sufficient for us and as you see it has an action where the rule is not met update static route automatically and this is the power of sd-wan you're going to save this performance sla as you see right now it has no data but it has board 1 on board 2 and it should be able to perform this sla and report back after a few minutes as you see the first numbers we start to get is that's fine for boil sports you can see board 1 and board 2 are meeting the latency threshold they are at 21 milliseconds so this is much faster and you can see board 2 is also very comparable you can also change the matrix in the top from latency jitter bracket loss to see historical data of these performance sla so now that we have our performance sla ready we still need to assign an sd1 rule to perform this sla check on specific ports or all traffic so this is like a second firewall policy we need to add in here under sd1 rules we're also going to call this rule dns because this is what matters for us in this sd1 rule we're going to define the source address as all the same like the firewall policy and for the destination will also be all so this is exactly the same as the firewall policy but we're going to change the outgoing interface in this case based on the performance sla result so by default this is set to best quality the interface was the best performance is selected which makes the most sense you can also have an interface preference by order in this case our first interface we can see the latency error all the numbers from here and because board one usually performs better than board two so we're gonna choose port one the bridge interface and board two as a second option so this is just the interface preference and the measure sla this is where we define the sla to check for and we're going to choose our custom created dns health trick and we're going to click ok so now we have our first sd1 rule and the traffic should be changed automatically by the sd1 rule to match which link has the better quality so right now we are still in the safe zone there is no traffic hits and there is no issue reaching dns or google dns server from either links so the point here we're going to start to emulate an issue with either links either by disabling the access from one of the boards or by causing a network congestion to force the traffic to be routed to the backup internet connection so you can also go into dashboard sd-wan monitor and this will typically give you which port is being used and what number of session you can see in here some low balancing where board one has more preference as it provides the better performance fortigate has also a built-in sla performance log you can do in the cli using the command diagnose sys sd1 sla-log and then you define what is the name of the performance sla so i'm gonna use dns which is the one i created and then you can define which interface to look for so you can either put one or two because we have two interfaces in our zone i'm going to choose one you will see in here all these recurring chicks it happens so fast for board one this is the reported latency reported generally aborted bracket loss now let's change it to two this will be board two and also the latency generator and packet loss we can see the status of either interface now for some reason fortigate decided to only report the default member under the sd1 rule so you have to move between multiple monitoring screen to be able to find all the information regarding the sd1 performance so in this case our sd1 rules reporting port 1 as being selected for the best performance so now i'm going to head to my original 40 gate which is able to limit the traffic or create a network condition on board one so we can emulate this issue now we know that board one has 172.20.0.21 so we're going to limit the traffic on this board to see what the 40 gate performance will look like now using my primary firewall i'm going to create a traffic shaper which basically limits the network speed on a specific traffic i'm going to create my own traffic shaper i'm gonna call this congestion and just lower the traffic priority to the lowest and just give it a maximum bandwidth of a hundred kilobyte per second so this way the connectivity to the internet will be brutal for any traffic assigned as traffic shaper then i'm going to create a traffic shaming policy for all traffic coming from this port 1 ib address to 100 kilobyte per second so the source in this case will be 172.28.0.21 i happen to have an object already for it in my address store so i'm going to choose this i'm going to choose all ib addresses i'm just going to congest traffic on all boards on all services and this traffic will be limited when accessing the internet so i'm going to choose the wine interface and use the shaper that i previously created congestion and now this should be in place so let's go back to the fortigate sd-wan let's see what happens as you see directly bortu is now the member and we'll see in here the latency and jitter are meeting our sla target they are under 150 milliseconds for latency and the packet loss is only one percent you also want to go into log and report events and see the sd1 events you'll see here all the important logs about interface changes and performance sla issues so for example you will see in here there is a server's priority change which is basically a static route change in this case the sequence 2 1 means board 2 was barrierized on board 1 because of latency metric and 40 gate port 1 has failed the metric for latency at this moment of time after that we're seeing here it reverted back to port one so it's going back and forth based on the link status and the metrics you'll see here it reported back change of sequence again so it's doing this all time so now i'll go back to network sd-wan and we'll see in here the traffic show more going into board two compared to board one because of the congestion we called on the border gate we'll see in here the board 2 has more bandwidth and more traffic through both at this point now on the performance sla reporting i can see that dns performance sla we seen here the hikes that happen when we created the congestion and it's showing every once in a while that's when the firewall automatically change or update the static route based on the performance sla so this is very good because everything is automated now let's try something different and try to block the access to google dns completely for one of the one links to see how sd1 will react first i want to show you how we can track sd-wan probes or performance sla checks that happens over time so for this i will use diagnose sniffer packet any because i'm not going to define any board and i just want to search for traffic for host 8.8.8.8 now as you see in normal scenario traffic coming out of the port 1 on board 2 go into google dns and in all situations google dns is responding back to both ib addresses i stopped it for a second so you can see you'll see in here this is the response to board 1 the bridge network and this is the response to board to the net network so i'm going to create a new firewall policy in my main firewall to block all traffic coming from the sd-148 port 1 172.20.0.21 to the internet or specifically 8.8.8.8 to make sure it fails all the performance sla for the sd1 so the incoming interface should be the bc network this is where 172.20.0.0.24 lives and the outgoing interface will be the internet so it should be my main internet link the source should be 172.20.0.21 which we created before and the destination should be 8.8.8.8 which i have an address for already so we're going to choose this for the service we should block the specific service which in this case is dns we're gonna deny and then we're gonna click ok so now the policy has been created and to make sure it's effective we have to make sure it's both in the correct order we know that internet access is above here and the deny policy comes below it so it will never work so the way we can get this to work is to move it all the way up to make sure it comes before the allow policy now let's go back to the fortigate sd-wan and let's run the sniffer again now in this case you will see the 8.8.8.8 is only responding to the net network is no longer responding to 172.20.0.21 even though the request was sent in here in here so we know for sure the firewall policy is blocking this so now let's go into our sd-wan monitor and we can see in here board was abandoned completely down because it's failing all the performance sla checks and this time it's not gonna go back and forth so quickly because the firewall policy is preventing access to the performance sla completely so this way it will still send performance sla until it sees port 1 is up at certain point and then it will bring it up otherwise all traffic should be sent to board 2. we can also go back to network sd-wan we've seen here in the one we'll see that board two is sending the majority of the traffic and under performance sla we should be able to see that board one is down in latency packet loss and jitter because i completely have no access to the sas service or whatever service we have dependency on on the internet this is the power of sd1 thank you for watching

Channel: ElastiCourse

Views: 584

Keywords: fortigate, sdwan, sd-wan, software defined network, firewall, routing, network security

Id: cl7C6HE1aoA

Length: 28min 40sec (1720 seconds)

Published: Sat Jul 31 2021