I’m a cranky on prem guy setting up a solution in Azure.
By default it appears the way this is setup is with a single vnet containing multiple subnets assigned to each FGT interface. Then vnet peerings and UDRs are used to forward traffic to the inside/lan interface for the FGT.
this rubs me the wrong way. first it doesn’t allow for any use of zones for east/west traffic, so my access policies will be gross.
2nd, as Vnets = VRFs and there is no construct that I am aware of that acts as an unrouteable layer 2 segment. I don’t like the idea that I’m a UDR away from allowing traffic to circumvent the FW.
In my feeble on prem brain, I would think I’d want separate vnets for outside/inside/DMZs.
Has anyone set this up/ is this doable? My understanding is that Azure supports 8 interfaces per VM and I don’t see why these couldn’t be individual vnets?
For Azure to support 8 interfaces, you need a 16 vCPU VM size, and a 16 cpu license for your FortiGate-VM. Once Azure supported multi threading, the maximum nics on an instance equaled CPUs / 2 as an Azure limitation.
The UDR really is your best friend, if you leave it alone, you get very close to microsegmentation, at least to the same point as an ISFW on premise.
It does take some learning to wrap your head around throwing out all traditional networking wisdom you have, since there’s little correlation in the cloud that applies. You can do things like dynamic address object groups using Tags once you get the SDN connector up and configured fully to simulate your zones. Sure your policy list will be port2-port2, but still srcaddr DMZ-FrontEndWeb to dstaddr DBServers.
Routing in Azure is a huge pain. Our Azure is setup with a “main” vNet which basically only has our FortiGate VM and everything related to the VPN and “untrust” side of things. We have a “untrust” zone, and “vpn” zone, and a “trust” zone. We have a separate vNET for the actual hosts who’s default UDR points to the FW on the trust zone.
So you can force traffic through the FW in Azure but as you mentioned it’s very easy to routing to not be setup correctly and have asymmetric routes bypassing your FW. By default Azure wants to NAT everything out to the Internet.
Our Azure has so far not gotten past a proof-of-concept so I’m certainly no expert in it.