Transcript
My name is Brian Martinez and I am a Cloud Security Architect at Fortinet. In this presentation, I'm going to cover the FortiGate integration with Azure VWAN and the new Internet Edge inbound service. During this presentation, I will review the FortiGate VWAN security solutions that are currently GA in the Azure Marketplace. I'll introduce the new Internet Edge inbound service offering and the architecture and show a demo deploying the FortiGate MVAs and how the MVAs integrate with the Internet Edge inbound service. Today, there's a marketplace offering for SD-WAN and next generation firewall deployments that have been GA for a few years now. In this slide, the diagram on the right shows an overview of both solutions. The blue lines represent east and west traffic, which is traffic staying in the cloud environment. The FortiGate MVAs can inspect the traffic as it moves between VNets or across multiple hubs. The green lines represent north-south traffic that traverses from the cloud networks to an on-prem site via an SD-WAN network and vice versa. This traffic can also be inspected by the FortiGate MVAs. The red line represents one-way traffic that is sourced from the cloud environment to the internet, but only in one direction. With the new Internet Edge inbound service, I will cover this scenario in more detail. The FortiGates are both active when deployed and FTSP should be configured to aid in session sync between both FortiGate MVAs. BGP is configured on the FortiGate MVAs with the VWAN hub and on-prem VGB neighbors who share routing information for VNet and on-prem networks. The FortiGate MVAs can be centrally managed by the FortiManager solution and FortiAnalyzer for centralized logging. Both solutions can be licensed using BYOL, Flex, or Pay-As-You-Go options. This slide shows the current marketplace listing on the upper left side for both offerings. On the bottom right, a snippet of the deployment type, image version, and license type that you select during the deployment is shown. I point this out because older versions of FortiOS may not be available. This should be considered if the FortiGate MVAs will be managed by a FortiManager or logs sent to a FortiAnalyzer that are on older versions. If an SD-WAN deployment is being considered, the on-prem FortiGate FortiOS version should also be factored in. Now, let's talk about the new Internet Edge inbound service. The new Internet Edge inbound service provides support for internet access to published services connected to the VWAN and hosted in virtual networks. The traffic destined for the published service can then be inspected by the FortiGate MVAs. Now, one important item I want to point out is on the left side in red. The service is still in public preview from Azure with no official GA date. However, the FortiGate MVAs are GA and fully supported in this offering by Fortinet. Taking a closer look at the diagram, the red line represents traffic between the internet and a VNet resource. Notice that the traffic can now flow in either direction with this new service. The new internet inbound feature also allows two inbound connectivity options. One is direct to the FortiGate MVAs and the other is direct to the Azure External Load Balancer. A scenario using these two options include terminating SD-WAN or IPsec traffic directly to the FortiGate MVAs or connecting FortiManager or FortiAnalyzer services directly. Internet traffic destined to your VNet published service would route directly to the Azure External Load Balancer via the advertised public IP managed by the External Load Balancer and then flow to the FortiGate MVAs for inspection. On the diagram, note the www client accessing the VNet published web service via the External Azure Load Balancer and the on-prem branch office or data center locations connecting directly to the FortiGate MVA or one public IP. The internet inbound service allows for the flexibility deploying SD-WAN, IPsec, SSLV, PNNVIP type services. Both FortiGates are deployed as active units. BGP is still supported and implemented as part of the solution. The FortiManager and FortiAnalyzer can still be integrated for management and logging and all three licensing options are still available. New services and integrations have been included with the new internet inbound offering. The Azure External Load Balancer is a new service and provides load balancing and hosts public IP addresses. The External Load Balancer is a managed service and cannot be directly accessed. Health checks against the FortiGate MVAs port one provide information on which FortiGate MVA is available for routing inbound traffic. API support provides the ability to update the rules on the External Load Balancer from the FortiGate CLI. New portal views provide status on the External Load Balancer rules and public IPs can also be viewed. On the left side, the internet edge inbound offering is deployed using the Azure Marketplace listing. On the right side, the feature is enabled in the FortiGate in virtual LAN specific parameters section of the deployment template. Now, let's take a look at the demo. In the demo, I'll deploy an Azure VWAN, a virtual hub and a pair of FortiGate MVAs. I will show the protected VNet, the Linux VM hosting the public services and cover the virtual network connections and routing intent configurations needed to route traffic. Next, I will show the routing configurations on the FortiGate MVAs, the FTSP config and adding the FortiGate policies and External Load Balancer rules to allow access to the Linux VM published services. Finally, I will test access from the internet and confirm reachability to the hosted services. This diagram represents a demo environment and key elements that will be deployed. I will reference this diagram from time to time as I move through the demo. Next, I'll log in the portal to get the deployment started. I have logged into the Azure portal and created a resource group to manage the virtual LAN related resources. The first resource to create is the virtual LAN. I select Create and get directed to the Azure Marketplace. In the search field, I enter the virtual LAN and select the first dropdown labeled virtual LAN. I confirm the correct offering is titled virtual LAN for Microsoft and select Create to start the deployment process. In the Basics tab, I confirm that my subscription, resource group and region fields are correct, enter the name of my virtual LAN and keep standard for the virtual LAN type. After confirming my entries on the Review and Create tab, I select Create. The next page shows that my deployment is in progress. This usually takes a few minutes to complete. Be sure to wait until the virtual LAN deployment is complete before moving on to the next step in deploying the virtual hub. After the virtual LAN resource has been deployed, you'll need to create a virtual hub. From the Assigned Resource Group, select the virtual LAN resource. On the next page, select Hubs on the left and on the next page at the top, select New Hub. Under the Basics tab, enter the relevant information for the new virtual hub. The hub private address space will be learned by the FortiGate MBAs when setting up the BGP configuration on the FortiGates. Also, the virtual hub capacity entry should be given careful consideration. The FortiGate MBA scale units should be aligned with the virtual hub capacity units to ensure proper performance expectations. The site-to-site, point-to-site and express route services can be skipped and added later. On the Review and Create tab, confirm the information is accurate before selecting Create. Note the Information section at the bottom. It could take up to 30 minutes to create the virtual hub. Select Create and on the next page, confirm the deployment is in progress with no errors listed. Once the virtual hub deployment is complete, return to the Virtual LAN Resource and Hubs page to check on the status of the virtual hub deployment. To confirm the status of the virtual hub deployment, navigate to the Virtual LAN Overview page and select Hubs on the left. Your new virtual hub will be listed. Confirm Succeeded under the Hub Status tab. Select the Hub Name to view the Hub Overview page. Note the Hub Status is listed as Succeeded but the Routing Status is listed as Provisioning. Do not continue until the Routing Status shows Provisioning. This will help in successfully deploying the FortiGate MBAs and configuring routing, which are the next steps. From the Virtual Hub Overview page, when the Routing Status shows Provision, the FortiGate MBAs are ready to be deployed. Navigate to Network Virtual Appliance and select Create. On the right-hand side, hit the down arrow and select Fortinet SD-WAN and NextGen Firewall. Select Create. Confirm to leave the page and you'll be directed to the Azure Marketplace. Once on the Azure Marketplace, confirm the Azure Virtual LAN secured by FortiGate plan is selected and then select Create. Select Yes to continue to begin the deployment. From the Basics tab, enter the relevant information for your environment. I have gone ahead and entered the relevant information for the demo environment. Most of the fields are self-explanatory, however, I want to review a few fields. I have selected PAYGO for the FortiGate license type for the demo. However, bring your own license and FortiFlex are also available. I point this out because if the FortiGate MBAs are deployed using PAYGO and there is a need to move to BYOL or FortiFlex licensing in the future, the FortiGate MBAs have to be redeployed. The FortiGate image version has two options listed. At the time of this presentation, 7.4.5 and 7.4.4 are being offered. If there are plans to connect existing Fortinet hardware, such as FortiGates for SD-WAN or IPSec connectivity or FortiManager and FortiAnalyzer solutions, be sure to confirm compatibility with the two MBA image versions being offered. The Azure VWAN deployment type selected is the SD-WAN and next-gen firewall. The other option is NGFW. If you remember from the presentation, the hybrid deployment allows for both east-west traffic flow and inspection and north-south traffic flow and inspection. The NGFW deployment is for east-west traffic flow and inspection. Finally, since the FortiGate MBAs will be deployed as a managed application, the application name and managed resource group entries are required. Under the FortiGate and Virtual WAN specific parameters tab, I have filled out the required fields for the demo. A few fields to note begin with the skill units field. Make sure this entry matches as close as possible to the virtual hub capacity that was selected during the virtual hub deployment to ensure expected performance. More information on this selection can be found under the Fortinet VWAN deployment guide found under the docs.fortinet.com site. The FortiGate BGP ASN value will be pre-configured in the FortiGate during deployment and used to establish BGP routing with the virtual hub as one of the first steps after deployment. The ASN number can be customized if needed. Azure has a prerequisite that manufacturers with the VWAN and VA solution must use their respective management solutions. In the FortiManager fields, enter the FortiManager IP and serial number that will be managing the FortiGate MVAs. The FortiGate MVAs are programmed to reach out and establish connectivity automatically to the FortiManager after deployment. The Internet Edge Inbound section has a few fields to point out. The first is the note regarding the Internet Edge Inbound feature that is currently in preview by Microsoft. As mentioned in the presentation earlier, FortiGate MVAs are in GA and fully supported by Fortinet, but the managed service is still in public preview for Microsoft. After selecting the Enable Internet Edge Inbound feature, the public IP address and DNS prefix entries are presented. I have already entered the custom name for the first public IP address to the inbound server load balancer and the DNS prefix for the first SLB public IP address. Under the Public Verification tab, the template will verify that the public IP SKU selected in the previous tab is typed standard before you can proceed. The Manage Application Settings tab is a new requirement for Microsoft. It will mandate the use of the User Assigned Managed Identity in order to deploy the managed MBA application. More information on User Assigned Managed Identities and what permissions are needed can be found in these two notice sections. I've already created a UAMI and will assign it to this field. If tags are required for your deployment, enter them here. On the Review and Create tab, scroll towards the bottom and confirm your entries are correct. Select the I agree to the Terms and Conditions box and select Create. Confirm the deployment is in progress without any errors. Once the deployment is complete, return to the Assigned Resource group to confirm the managed application is listed. While the FortiGate MBAs were being deployed, I went ahead and created a virtual network and a Linux virtual machine. The Linux VM was assigned to the new virtual network. I also created a virtual network connection between the new virtual network and the virtual hub. Let's take a look at these resources now. This is the name of the new VNet, but I'll use VNet1 for short. Here you can see the assigned address space of 192.168.1.0.24, and the default subnet consists of the entire network for simplicity. The Linux name is listed here, but I will call this Linux VM for short. Here you can see the assigned virtual network, which is VNet1, and the IP address space that is assigned to the Linux VM of 192.168.1.4. The Linux VM has SSH and web services installed to test connectivity from the internet. The virtual network connections page can be found under the virtual hub overview page. Navigate to the virtual network connections to set up a VNC with VNet1. I have set up a virtual network connection between the virtual hub and VNet1. To create another VNC for another VNet, simply select add connections from the top. Let's take a look at where things are so far using the diagram for the presentation. So far, the VWAN and the VHUB have been created. The FortiGate MVAs with the new internet edge and bound service have been deployed. VNet1 and the Linux VM hosting the web services have been deployed. And finally, a VNC between the virtual hub and VNet1 has been established. The next three steps are to enable routing intent in the virtual hub, authorize the FortiGate MVAs in the FortiManager, and configure routing in the FortiGate MVAs. In the next three steps, I'm going to enable routing intent in the virtual hub, authorize the FortiGate MVAs in FortiManager, and finish setting up routing between the FortiGate MVAs and the virtual hub. First, let's review the deployed FortiGate MVAs and their assigned private and public IP addresses. From the virtual hub overview page, navigate to the network virtual appliance and select. On this page, the managed network virtual appliance name is listed along with the provisioning state. Make sure succeeded is displayed before moving forward with the routing configuration. Under instance info, the MVAs public and private IP assignments are listed. Both MVAs have a private and public interface and the public interfaces have their respective assigned public IPs. Take note of the assigned public IPs to verify when authorizing the MVAs from the FortiManager. Next, to enable routing intent, start from the virtual hub overview page and navigate to routing intent and routing policies on the left. For internet traffic, select network virtual appliance and for next hop resource, select the name of the managed FortiGate MVA. The same settings apply for private traffic. Select save at the top to apply the changes. This process will take several minutes to complete. Next, let's move on to the FortiManager and authorizing FortiGate MVAs. Here's the dashboard of the FortiManager VM I'm running with firmware version 7.4.5. I'm in the root ADOM and can see both FortiGate MVAs listed as unauthorized devices with their source public IPs addresses listed as well. I select both devices and authorize. I'm assigning both MVAs to a specific ADOM I created earlier. Once the authorization is completed, the assigned ADOM shows all FortiGate MVAs listed. The next step consists of setting up static routes on the FortiGate MVAs so BGP can be established between the hub and the FortiGate MVAs. The IP address of port two of both MVAs are in a slash 28 subnet. And the static route is needed to reach the virtual hub network where the hub BGP neighbors are assigned. Also, the hub BGP neighbors are already set up in the FortiGate MVAs and are assigned IPs in the virtual hub network space. The static route needs to be set up on both MVAs so BGP communication can be established. Based on the network info assigned to port two on the MVAs, the default gateway to the hub network is 10.10.1.225. This is based on Azure networking policy, which assigns the first usable address in a subnet as the gateway. I have set up a static route to the hub network in the FortiManager. Additionally, the FortiGate MVAs need a route to respond to the Azure load balancer probes, which come from IP address 168.63.129.16. Make sure to set the distance to five on the static entry. Once you have both MVAs configured with the static routes, use the install wizard to update both MVAs. A good practice to follow is to confirm the install changes using the install preview tool before selecting install. Use this preview tool to confirm the changes are being pushed or what's expected. For example, if the preview result log shows config changes to VPN configs or UTM profiles and does not list routing config changes, cancel the installation and review. This is a great way to assist with confirming expected config changes in production FortiGates. This preview result log confirms the expected static route entries that will be installed on the FortiGate MVAs. After the install is completed successfully, confirm the routes to the VNet and the hub are listed in the MVAs routing table. You can see here that we now have a route to the virtual hub 10.10.1.0 address space. And we also have a route to the 192.168.1.0 space in the VNet. Listed are the learned routes to the virtual hub network and the VNet1 network. Also listed is the status state with the hub BGP neighbors and the best path learned by BGP. From the virtual hub, the effective routes in the default route table have been updated and lists the FortiGate MVAs as the next hop. Next, I will show setting up the SLB rules and the FortiGate policies to allow internet traffic to the Linux VM hosted services. In the next few steps, I will show programming the rules in the virtual LAN load balancer, creating and installing policies to the FortiGate MVAs and testing access from an internet client to the hosted services on the Linux VM. I'll finish up with showing the traffic traversing a FortiGate MVA and reaching the Linux VM. Referring back to the diagram, port 22 and 80 need to be open to allow access to the hosted services. In order to enable this access, the virtual LAN load balancer and the FortiGate MVAs need rules configured to allow access to the Linux VM. The first step is to select one of the FortiGate MVAs to be active. This ensures that of the two FortiGate MVAs, the FortiGate selected as active will be responsible to push the rule changes to the virtual LAN load balancer. Note the pop-up screen after selecting okay and proving the changes. The change is dynamic and nothing needs to be pushed from the FortiManager. Refresh the status of the FortiGate MVAs and confirm the Azure VWAN SLB mode is active under the correct MVA. Next, add rules to the virtual LAN load balancer as the first step in allowing access to the hosted services. First, copy the name of the Azure VWAN public IP. This is the public IP the rules will apply to. In this case, it is the name I entered for the public IP when deploying the FortiGate MVA template and is shown here under the active MVA. Right-click on the active MVA and select Azure VWAN SLB to add a rule. Under permanent security rules, make sure to set the status to enable. Under rules, I will add one for SSH access and one for HTTP access. Note, the applies on field refers to the VWAN public IP the rule applies to, and then I copied from the active MVA. Next, using the install wizard, push the newly created rules to the VWAN SLB. Note, the FortiManager does not push the changes directly to the VWAN SLB. Note, the FortiManager does not push the changes directly to the VWAN SLB, but pushes the changes to the FortiGate MVAs and the active FortiGate MVA will then push the rule entries to the VWAN SLB. When the install finishes, view the installation log for the active FortiGate MVA. Confirm the entry Azure SLB security rules changed in the log file. Next, I will show adding the policies to the FortiGate MVAs that are needed to finish allowing access to the hosted services. On the FortiManager, I have added a firewall object for the VNet1 network, and a VIP for SSH and HTTP services. Under the virtual IP configs, the entry port one listed in the interface field is port one on the FortiGate MVA. In the external IP address field, the Azure VWAN public IP that is listed under the active FortiGate MVA is entered here. The mapped IP address is a private IP address of the Linux VM hosting the services. Next, I have added the two policies needed to allow access from the internet to the SSH and HTTP hosted services. These inbound policies could also include an IPS profile for deeper internet traffic inspection. The third policy allows the VNet1 network address range access to the internet. This policy allows the Linux VM access to the internet for OS updates, for example, and the outbound traffic can also be inspected by the FortiGate security profiles. To make sure these policies get pushed to the correct FortiGate MVAs, under installation targets, select and apply the correct FortiGate MVA group name. To push the new policies to both FortiGate MVAs, select both MVAs and run the install wizard. Select the install policy package and device settings option. Confirm the correct policies are being installed by viewing the install preview logs. Now that the policies have been successfully installed, let's test access to the hosted services. Using a local browser on the internet and the public IP of the VIP, I will test HTTP access to the Linux VM. Next, using PuTTY and the public IP of the VIP, I will test SSH access to the Linux VM service. If the traffic is not reaching the hosted service, there are tools accessible from the FortiGate CLI for troubleshooting. To access the FortiGate MVA CLI from the FortiManager, highlight one of the FortiGate MVAs to display the dashboard summary page. The CLI access operation is found under the system information widget. Ping the destination host to confirm the path from the FortiGate to the VNet host is available. Run the diag sniffer packet command on one of the interfaces to confirm traffic is reaching the FortiGate. The diag sniffer packet command may need to be run on both FortiGate MVAs to determine which path the traffic is using. So in summary, I was able to set up a virtual WAN with a virtual hub and secure the new internet edge inbound service using FortiGate MVAs. The Azure Load Balancer and the FortiGate MVAs were configured to allow traffic from the internet to services hosted in a virtual network using the FortiManager platform. Reach out to your FortiNet account team for more information, and thank you for watching this video presentation.
