Versa Azure vWAN native integration : Versa Support

`Purpose`

The document below describes the VOS native integration in Azure vWAN.

`Introduction`

vWAN doesn't provide advanced security or traffic steering capability. Even though vWAN has Azure firewall functionality but that's very limited.

When we deploy Versa in vWAN, it creates a managed resource group where versa application will be deployed. Versa is deployed as the managed application within vWAN hub similar to Azure firewall within Microsoft.

There will be a Internal load balancer created which will send probes to Versa VOS. VOS is connected in backend pool. ILB will send probes on all NIC's but NVA should respond to only LAN side probes.

There is a cloud init script on Versa which will call home and pull the template from director.

North-South flows

Versa VOS interact with vWAN hub routing service (Virtual Hub router) . So, on-premises prefixes will be exchanged with vWAN routing service (Virtual Hub router) via BGP that propagates it to Spoke VNET. So, spoke VNET will point to vWAN hub ( which is tied to Versa VOS) to reach on-premises subnet.

Return traffic will through Load balancer. Forward traffic doesn't go through ILB. So ILB doesn't have track of the session. ( use SNAT for symmetric forwarding)

Forward traffic ( Branch office. to VNET) not going through ILB because VOS are connected in backend pool in respect to ILB. But, return traffic comes at front end IP on LLB and then forwarded to VOS.

Make sure traffic is SNAT to LAN IP in forward direction to avoid asymmetric routing issue. It is important for UTM functionality.

Other option is to use X-forward header. It is applicable for web based workloads in VNET. It can look at http header. You will still do SNAT but application can see original client source IP in http header.So, all traffic won't look coming from just one SNATTed IP.

Only existing partners can deploy NVA in vWAN hub ex Versa, Cisco, fortinet , barracuda, Vmware.

East-West flows

We want to make sure traffic between VNET flows through VOS.

Traffic hits the ILB front end IP from Spoke-VNET-01 then goes to VOS . VOS sends traffic to Spoke-VNET-02 directly then return traffic hits ILB then to VOS and back to Spoke-VNET-01.

SNAT is not required because ILB is flow aware in this case. So, forward and return traffic hits the same VOS device.

`Topology`

`Configuration`

`Resource Group`	`Region`	`VNET`	`VNET CIDR`	`subnet`	`Subnet CIDR`
`RK-vWAN-NVA-RG`	`East-US`	`SPOKE-VNET-01`	`10.64.0.0/16`	`MGMT`	`10.64.0.0/24`
`RK-vWAN-NVA-RG`	`East-US`	`SPOKE-VNET-02`	`10.66.0.0/16`	`MGMT`	`10.66.0.0/24`
`RK-vWAN-NVA-RG`	`East-US`	`Managed VNET -vWAN`	`10.100.100.0/24`	`LAN`	`10.100.100.224/28`
`RK-vWAN-NVA-RG`	`East-US`	`Managed VNET-vWAN`	`10.100.100.0/24`	`WAN`	`10.100.100.240/28`

`Azure Configuration`

Create vWAN

The virtualWAN resource represents a virtual overlay of your Azure network and is a collection of multiple resources. It contains links to all your virtual hubs that you would like to have within the virtual WAN. Virtual WANs are isolated from each other and can't contain a common hub. Virtual hubs in different virtual WANs don't communicate with each other. vWAN is a global object but still it asks for resource group. Meta data will be stored in RG.

Basic vWAN type is only for site to site connectivity from branches. For other options use standard vWAN type . For ex. Express route , Point to site , Versa within vWAN hub.

Create Virtual Hub

A virtual hub is a Microsoft-managed virtual network. Creating a Hub Can take approx 30 minutes.

You can create site to site , point to site , express route connection to hub.

We will not need site to site VPN to VOS devices (we will have sdwan overlay). Express route will need another interface on VOS.

Attach VNET's to Hub

Attach Spoke-VNET-01 and Spoke-VNET-02 to NYC-Hub.

Create template workflow on Director or Master profile in Concerto. We used Concerto in our case. We created a basic master profile with LAN and WAN interface.

Enable BGP on LAN interface. This is the BGP with vWAN routing service (Virtual Hub router). Microsoft always uses AS 65515. Neighbor IP is vWAN hub router IP. So, there will be a BGP on LAN side with vWAN hub router.

We also need a service template for load balancer probes which will allow VOS to respond to probes on port 8443.

Probes will be originated from ILB IP 168.63.129.16 on port 8443. We enabled explicit web proxy on VOS on port 8443 to open the port for probes.

NOTE: Ensure that only LAN interface is responding to probes from ILB. You can deny probes on WAN interface using a null route for ILB IP address or create a firewall policy to drop probes.

It is observed that VOS is responding to probes even after deny rule or null route in transport VR. If that' the case, add a null route in global routing as well.

sudo route del 168.63.129.16 gw 10.100.100.241

sudo route add -net 168.63.129.16/30 gw 127.0.0.1 lo

Routing table should look like this

NOTE: Make sure there is a static route in LAN-VR to reach vHub Router and ILB (Internal Load balancer). Nexthop will be the first IP in subnet.

Create device workflow on director or deploy device in concerto. Make note of serial number. Serial number will be based on cluster name for Versa SASE NVA managed application.

`Versa NVA Deployment Steps`

On the Azure portal, go to the Azure Marketplace and search for Versa. Select the below offering "Versa SDWAN & NGFW for Azure Virtual WAN" as shown below.

This is a 3 interface offering. One interface is for the Internet WAN with a public IP address, one interface for the LAN. The 3rd interface can be chosen as an out-of-band management address (eth0) with a pubic IP address or an express route WAN interface with only a private IP address.

In the example, the offering with the out-of-band management address (eth0) is selected.

For the deployment with the out-of-band management interface (eth0), use the following cloud init script -Azure_vWAN_NVA_CloudInit_bionic_v1-3NICs-withoutExpressRoute.bash.

For the deployment with express route, use the following cloud init script - Azure_vWAN_NVA_CloudInit_bionic_v1-3NICs-withExpressRoute.bash.

In the script, the following parameters should be modified for your setup.

SSHKey="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyjeoYVyHi5uqAySnDgHu5+/zOHx44k0V0ozPOuo1dgfzgpDy9MkOJ1auUc1UdgD9vJxkvuLMAybH/lXGwusHi7bo40SowtJeLgLA03bwYH9x5cB8oBpYr/eIGODoNLySk4AHfu104+Q0n5TSJDZ4Wk2YV3XnZn42SRqtg4iF0grAxJsuwBE79f/M5D9BW3wsCV8wvMuZ/qsDkHp1FxD9OmYOKxXZHTbwCjFBPU30A1/CZaWTdp1rnZtqU8R7nzCDr4K949YeuDoopU0qiRopHvcLwrOEMUdHzIIaTXuaOotL8RcUfCUaIPKl6maQYsHAM1pATwErDWzdkOjBKmHhz keys@my-pc"
ControllerIP="129.159.34.137"
LocalAuth="SDWAN-Branch@Versa.com"
RemoteAuth="us-poc-controller-1-staging@Versa.com"
DirIP="172.16.100.71"

The SSH keys is to be able to access the NVAs via ssh. The DirIP field is the southbound IP of the primary Director. The serial number can also be edited in the script to override the cluster name field.

Note: The Versa NVA is currently offered in the following scale units and throughput. For each scale unit, Azure will deploy the following number and type of Versa VMs.

4 Scale Units - 2 Gbps - 2x Standard_D3_v2 VMs

10 Scale Units - 5 Gbps - 2x Standard_D4_v2 VMs

20 Scale Units - 10 Gbps - 2x Standard_D16_v5 VMs

40 Scale Units - 15 Gbps - 3x Standard_D16_v5 VMs

Once we click on Create , it will put the VOS NVA's in two different AZ, pass cloud init script and stage it with headend. It takes about 15 minutes and then our NVA's are ready and part of the SD-WAN network.

Routing Intent

Now, how to simplify routing from Spoke VNET's? I want to ensure that my traffic from Spoke VNET goes through VOS in vWAN hub. What's the best way to do this ? It's not feasible to modify UDR in every subnet to point towards VOS NVA specially when I have 100's of VNET connected to vWAN hub.

This can be done easily from routing intent. Routing intent is in preview not ready for production.

You can access routing intent from a special portal under vWAN Hub. Routing intent will program all the VNET's to forward traffic to Load balancer in vWAN hub. So, you don’t have to work manually to route traffic to VOS in vWAN hub.

Send Internet bound traffic to --- means INET traffic from spoke VNET

Send private traffic to -- means VNET to VNEt traffic to go through Versa