I'm trying to integrate a Network Virtual Appliance (NVA) into my existing Azure environment, which currently doesn't have one. Here's a breakdown of my current setup: I have two virtual networks (vnets)—one hub vnet with a subnet for a VPN gateway and a spoke vnet containing three subnets with multiple virtual machines (VMs). These two vnets are peered, allowing for traffic flow between them, and I have a VPN gateway in the hub for site-to-site connectivity to on-premises resources. There's also an Azure Load Balancer for internet egress for the spoke vnet VMs.
My goal with the NVA, which is part of Cato Networks' SASE solution, is to ensure that: 1) All VMs in the spoke vnet route internet traffic through the NVA; 2) Internal communication between subnets in the spoke vnet also goes through the NVA; and 3) The NVA replaces the VPN gateway for site-to-site communication.
I have successfully set up a route table with a default route pointing to the NVA, and I've linked it to the spoke vnet subnets. This setup allows the VMs to egress to the internet via the NVA. However, inter-subnet routing isn't functioning as intended, and I suspect that there are default routes in place that might be overriding my configurations.
I'm looking for advice on how to proceed, specifically regarding managing inter-subnet routing. Do I need to add more specific User Defined Routes (UDRs) for my spoke vnet subnets pointing to the NVA? Should I modify any of the peering settings? I want to maintain flexibility for future resource integration, keeping open the option to route directly from Azure without going through the NVA if needed.
3 Answers
Another approach you might consider is implementing BGP if your NVA supports it. By using Azure Route Server, you can establish a BGP peer, allowing the NVA to automatically learn routes for your peered vnets. However, keep in mind that if your network is small, the cost of around $330/month just for the Route Server might not be justifiable for your setup. If you stick to UDRs, remember that you also need a UDR for traffic returning to the vnets routed back to the subnet where your NVA is.
It sounds like you’re on the right track! You definitely need to set up UDRs for the subnets in the spoke vnet that point to the NVA's LAN IP. The default 0.0.0.0/0 route won’t enforce traffic through the NVA for inter-subnet communication because routing within the same vnet can take precedence. Just make sure you create a UDR for each subnet directing traffic to the NVA, and that should help with routing between them.
If you're mainly concerned about traffic between subnets in the same vnet going through the NVA, try creating a dedicated vnet with just one subnet. This setup can simplify routing and ensure that traffic flows as intended, but it might not be feasible depending on your broader network architecture.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures