There have been quite a few blog posts about third party firewalls or in Azure speak NVA (Network Virtual Appliance) in AVS. Why Azure calls these NVAs and not VNFs (Virtual Network Function) like the rest of the world is a question I’d like to have answered. While the DFW (Distributed Firewall) should be used for anything Layer 2-4 most customers don’t know how to use it and want to continue to use the firewall vendor they are used to. Since service insertion isn’t support in AVS most of posts provide an architecture similar to this:
This architecture will work. There are some inherent limitations with it.
- Limited Interfaces on NVA.
- VMware VMs only support 10 interfaces. 1 for management, 1 for the uplink, 8 for segments
- All inter segment traffic must traverse the NVA.
- Hairpinning, limited throughput, and additional latency, no distributed routing
If these limitations are inline with the requirements then use this one. It’s simple and works. Another way to accomplish this type of network is like this:
With this architecture many more networks are allowed off of a single NVA. NSX-T 3.1 supports up to 1000 interfaces on a T1. Up to 8 T1s can be linked to the NVA before needing another NVA. All north south traffic must still traverse the NVA; however, east west traffic within each zone can utilize distributed routing. If further segmentation is required within each zone the gateway firewall on the T1 or the DFW can be used (yes you should just use the DFW for all of this).
To configure this architecture:
- Create a transit segment connected to the Provider T1
- Connect an NVA to the transit segment
- Create a 0/0 route on the NVA with the next hop the Provider T1 transit interface
- Create static routes on the Provider T1 for all planned segments with the next hop of the NVA transit interface
- Create transit segments for each T1 to be connected to the NVA
- Attach NVA interfaces to these segments
- Create new T1s
- Connect an interface on T1s connected to the transit segment connected to the NVA
- Create 0/0 static routes on the T1s with the next hop of the NVA interface
By using this architecture far fewer NVAs are required. This reduces licensing costs and management overhead. While this may have some drawbacks it is far more scalable than creating an NVA for every 8 segments.
vSkeeBall 
Hello Kenyon,
this was a quite interesting post about 3rd party firewall within the AVS.
I’m interested in the second topology you have drawn. The one with several T1 routers below the NVA.
Have you ever put in place this kind of topology in a lab ?
I am wondering if it works fine, cause i have a similar topology to put in place where i have many segments to filter but as you said, you must mix the NVA feature with the NSX-T distributed firewall.
LikeLike
I’ve seen plenty of customers implement this topology in production and I’ve done it in the lab as well. The DFW is not necessary but complements this strategy for VM to VM traffic on the same segment.
LikeLike
What if i have more than 10 segments, each one linked to its own T1, to filter within the NVA…
Do you think it could be a good alternative to connect many T1’s routers to the same transit segment with the help of a Service Interface enabled into every Tier1 routers ?
In this way shouldn’t i be able to link more than one segment to the same NVA’s interface in order to filter all the traffic inside the NVA, without the needs to use DFW for the exceeded segments ?
I don’t know if have explain myself well.
Thanks.
LikeLike
You can link up to 1000 segments to each T1. Do you mean you need more security zones that you can configure via one NVA? You may be able to use a service interface though i haven’t tested it. I’m not sure what MAC the service interfaces use. You may run the risk of duplicate MACs in this case.
LikeLike
Hello Kenyon,
this is interesting and detailed post about 3rd party firewall within the AVS.
can you pls let us know if the connection from default T1 to NVA and NVA to Isolated T1 is also going to be advertised out like a normal segment.
Secondly can we do a NAT for NVA interface connected to default T1 so that we can deploy client based VPN solution with the same firewall ?
Looking forward to hear from you.
LikeLike
You can configure the advertisement anyway you want. And yes you could use a vpn solution and setups the appropriate routes to make it work.
LikeLike
How can we enable “Promiscuous Mode, MAC Address Changes and Forged Transmits to Accept” for a segment in NSX-T
If the above is not possible can we create a distributed port group directly in vcenter and enable these feature under security.
Does it create any issue interms of NSX-T manage segmetn and these port group inside AVS.
We need this feature enable for paloalto firewall HA deployment.
Is there any other way to deploy paloalto firewall in L3 mode with HA inside AVS
LikeLike