This article describes how to deploy the Cato vSocket on a Microsoft Azure environment with multiple Virtual Networks (VNets). It introduces a cost-efficient solution of one vSocket deployment on a single VNet and connect multiple VNets together. The solution allows you to add additional VNets to your Azure environment without deploying any additional instances for the vSockets. It simplifies the management of the network topology and you can manage the multiple VNets as a single site in the Cato Management Application.
The solution of implementing the Cato vSocket in a multi VNets environment, is connecting different VNets using the Azure virtual network peering. The VNet peering allows resources from different VNets to communicate with private IP ranges as if there are in the same network.
The architecture is based on a hub and spokes model. The VNet with the vSocket acts as a central hub and all other VNets act as spokes. The hub and spokes VNets are connected with an Azure virtual network peering. This peering allows resources from different VNets to communicate with private IP ranges as if they’re in the same network.
The following diagram shows an example of 3 VNets environment: VNet1 is the hub VNet, and VNets 2 and 3 are the spokes VNets. The spoke VNets are connected to the hub VNet with VNet peering.
To implement a vSocket in a multi VNet environment you must complete the following steps:
-
Deploy the Azure vSocket to the hub VPC
-
Add a virtual network peering between the spoke VNets and the hub VNet
-
Create the route tables for the spokes VPC
-
Add route to the route table for the spokes VNets
-
Associate the route table to the spoke VNets subnets
-
Configure the network routed ranges in the Cato Management Application
Create the Azure vSocket site in the Cato Management Application and deploy the Azure vSocket in the hub VNet. For more information, see Deploying an Azure vSocket Site Manually.
Create a new VNet peering between each spoke VNet that connects tot eh vSocket hub VNet. This peering provides connectivity between the hub and the spoke VNets and allows them to send traffic from one peering side to another. The peering must be created for both directions (For example, VNet1 to VNet2 and VNet2 to VNet 1). You must enable the Allow forwarded traffic option for both directions. The following screenshot shows a sample of VNet peering configuration between VNet2 (spoke) and VNet1 (hub):
Create a route table for each one of the spokes VNets that allows you to route traffic between them. The following screenshot shows a sample route table configuration for the spoke VNet2.
Add routes to each VNet route table to allow the spoke VNets to route the traffic to the hub VNet. Set the Next hop type to Virtual appliance and set the Next hop address to the IP address of the vSocket LAN interface.
The following screenshot shows a sample route configuration from a spoke VNet to the vSocket LAN IP address of the hub VNet.
Associate the route table to the VNet subnet. Azure allows you to route traffic only if the route table is associated with the VNet route table. The following screenshot shows the spoke VNet route table associated with the subnet.
Configure the LAN ranges of the VNets in the Cato Management Application (Configuration>Azure Site>Networks<LAN) and add a Routed range for each VNet that is connected to the virtual network peering. Use the first IP address of the vSocket LAN native range for the gateway. The following screenshot shows a sample configuration of two spoke VNets with different routed IP ranges. Each range is configured with the gateway IP address of the LAN native range.
Note: Make sure you configure network rules that route traffic to the Azure vSocket site. For more about network rules, see Configuring Network Rules.
After you complete the deployment, you can verify that hosts in the spoke VNet have internet access and can communicate with other sites in your account.
4 comments
The link to Configuring Network Rules is broken.
Mike Prepelica, Ugh - sorry we missed this. Link is fixed
The VNet peering between VNet2 and VNet3 in the architecture view could be removed for this scenario.
Azure screenshots could do with an update, things have changed quite a bit
Please sign in to leave a comment.