July 01, 2020 By BlueAlly
By Ali Bidabadi and Praveen Lokesh | July 01, 2020
Last year we announced integration with Microsoft Azure Virtual WAN to offer customers a secure cloud on-ramp from both data centers and branches to the Azure cloud. Fortinet Secure SD-WAN for Azure Virtual WAN offers organizations the ideal combination of automated set-up, ease of use, security, and visibility across their distributed infrastructure. The solution offers secure and automated branch-to-branch connectivity using Azure’s global transit network, as well as connectivity from the branch to the Azure Virtual WAN. Fortinet’s Secure SD-WAN solution integrated with the Azure Virtual WAN allows organizations to accelerate cloud on-ramp to Azure by taking advantage of the dynamic path selection feature when both VPN and ExpressRoute connectivity options are utilized in a hybrid cloud environment.
This week, Microsoft Azure has made new routing capabilities in its Azure Virtual WAN offering publicly available. And Fortinet has become the first vendor to announce integration with these enhancements to enable new security use cases, allowing organizations to further secure their Azure VNet deployments. Specifically, FortiGate-VM can now be deployed in a service VNet to secure traffic in all directions.
Deeper Routing Enhancements to Enable Security Inspection
Fortinet’s FortiGate NGFW has leveraged these Azure Virtual WAN routing enhancements to ensure all traffic going from an organization’s Virtual Network deployments to their branch offices (similarly, traffic flowing from branch networks to Virtual networks) can be inspected by the FortiGate-VM. Additionally, FortiGate can now inspect all East-West (VNet -to-VNet) traffic without requiring VNets to directly connect to Azure Virtual Hubs. Fortinet is the first vendor to integrate with these enhancements and fully validate these new use cases.
These new enhancements allow users to create custom route tables, in addition to the default route table that Azure Virtual WAN creates for each virtual hub. A virtual network connection can then be associated with a single route table. Once a connection to a virtual hub is created, it associates and propagates to the Default route table. However, a connection can be associated to a custom route table to allow the traffic to be sent to the destination indicated as routes in that new route table.
Routes can be dynamically propagated from a connection to one or multiple route tables. Additionally, these new enhancements allow static routes to be configured in a virtual network connection to provide a mechanism to steer traffic through a next-hop IP, which could be a Network Virtual Appliance (NVA) provisioned in a Spoke VNet attached to a virtual hub.
Service VNet Integrated with Azure Virtual WAN
The FortiGate Next Generation Firewall (NGFW) can be deployed in security hub VNets connected to an Azure Virtual Hub to inspect all traffic, including VNet-to-branch and VNet-to-internet traffic. The diagram below illustrates how these recent enhancements enable a hub-spoke topology. Specifically, it shows how VNet-to-branch (and VNet-to-internet) traffic can be steered to FortiGate NGFW (NVA).
Dynamic Cloud Security for Microsoft Azure
In this setup, we have two spoke VNets, Spoke1 and Spoke2, a Service VNet that hosts the FortiGate-VM, and an optional VNet5 which can also host a FortiGate-VM, but for the purpose of inspecting VNet-to-internet traffic. There are two branch office networks that are connected to the Azure Virtual WAN through IPSec and ExpressRoute, respectively. The FortiGate-VM in the Service VNet is deployed with two network interfaces. And all four VNETs are connected to the Virtual WAN Hub in the corresponding region.
Any traffic originating from the Spoke VNets and destined to the branch office is routed through the FortiGate internal interface. This is achieved by using custom route tables that are supported on Azure Virtual WAN. By default, Azure Virtual WAN comes with two route tables: A Default Route Table and a None Route Table. In addition, you would need two route tables to configure the routing correctly. Spoke VNETs will associate to the RT_V2B route table, and the Service VNET hosting the FortiGate-VMs will associate to the RT_Shared route table.
For example, when a resource in Spoke1 needs to communicate with a server in the branch network, the virtual hub looks at the route table t which Spoke1 is associated. In this case, that route table is RT_V2B, which has a static route for the branch network with the next connection hop. Once the traffic is inspected by the FortiGate-VM, it is forwarded back to the virtual hub. This time, the hub makes its routing decision based on the routes in the route table RT_Shared, since the Service VNet connection is associated with that route table.
As shown in the diagram, the VPN connection to the branch network has propagated routes to the RT_Shared table, allowing the route table to have a route to the branch network. This helps hub1 route the traffic to the final destination in the branch. Similarly, internet-bound traffic can be steered to another VNet (VNet5) that hosts FortiGate-VM, as shown in the diagram.
Cloud On-Ramp and Network Security in All Directions with FortiGate Secure SD-WAN
Fortinet FortiGate integrated with Azure Virtual WAN enables organizations to securely on-ramp to the Azure cloud in an automated fashion. While FortiGate Secure SD-WAN deployed in branch offices enables branch-to-branch connectivity, by leveraging the newly-announced routing enhancements in Azure Virtual WAN, a FortiGate-VM can inspect and secure traffic in all directions, including VNet-to-branch, VNet-to-internet, and VNet-to-VNet traffic. This allows organizations to deploy a FortiGate solution in their hybrid cloud environment to address a wide range of connectivity and security use cases, as outlined in this blog.
Don't miss out on our sales events and all our big promotions, subscribe to our email and enjoy exclusive weekly deals from Virtual Graffiti!