PART 3: deploying a ngfw virtual appliance
Before virtual security appliances were available in the Azure Marketplace, securing your Azure environment required the use of NSG’s (Network Security Group). NSG’s use the source and destination address and/or port methodology which doesn’t provide application layer visibility and logic. It can also become overly complex to implement and troubleshoot as the environment increases in scale.
With a virtual NGFW security appliance, securing your Azure perimeter feels familiar to that of an on-prem appliance. Offerings are also available through many of the major vendors, which can be deployed using templates available in the Azure marketplace. FortiGate for example can be deployed in a single or HA load balanced configuration and allows for a PAYG (pay as you go) or BYOL (bring your own license) option.
When deploying the virtual appliance, you’ll be required to select which VNET (virtual network) the appliance will associate with. From here, an outside and inside transport subnet will need to be selected from the chosen VNET. The outside subnet will be used for the appliances WAN interface, and inside for the LAN. This will be handed out dynamically by default but can be changed to a static IP configuration later if needed. It’s worth noting that both outside and inside interfaces will be assigned a private IP within their respective IP range. This is due to the fact that the public IP assigned by Azure does not get applied directly to the NGFW, but rather NAT’d 1:1 between the public IP and its outside interface IP.
After the virtual appliance successfully deploys, access will usually be enabled to the public IP by default. If using a FortiGate virtual appliance, management access via the public IP on 443 will be available. Once inside the NGFW management console, basic firewall forwarding rules can be configured for LAN to Internet connectivity.