labtech-uks-platform-firewall-vm01
(AS ALWAYS, PLEASE MAKE SURE TO CREATE A CR FOR ANY WORKS TAKING PLACE ON ANYTHING AZURE RELATED)
This document describes the Azure network security architecture where all Azure Virtual Machines route outbound traffic through a central FortiGate Firewall VM. The FortiGate VM acts as the primary security boundary, with Azure NSGs used for basic packet filtering but all inspection/egress/NAT handled by the firewall. Can be reached via:
https://20.108.138.237:4443/firewall/virtual-ip?view=vip
You should all have user accounts for the above, if you do not remember your password please reach out to [email protected] and if unavailable reach out to [email protected].
As you can see it’s just another VM hosted in our Azure running Forti OS (specified under Operating System). You will see it has 4 Public IP addresses under Networking all tied to its NIC1 Interface.
This is because NIC1 is used for outbound traffic whilst NIC2 is inbound traffic (hence why it has no Public IPs). Therefore, NIC2 is also the next hop for all VMs.
You can see in the above screenshot, there is no Public IP configured for NIC2, and pay attention to it’s Private IP.
0.0.0.0/0 is a catch-all range used for all traffic. This rule catches all traffic leaving the VMs (as per the 0.0.0.0/0) and forwards it to the Next hop IP address on 10.100.2.4. Which is then dealt with by the Fortigate, it would forward said traffic out of its NIC1 interface which holds all the Public IPs.
Now let’s circle back to NIC1 you can see below it has 4 different IP configurations on the same Interface:
Each one of these IPs serves a purpose, as detailed in its name. The main Public IP address for most Virtual machines in our Azure estate is 20.108.138.237, a select few break this rule such as BlueBox VM which has it’s own Public IP NAT’d via the Fortigate on the interface called bluebox-pip, meaning the it does not use ipconfig1’s public IP but rather bluebox-pip. This is because it has a few web pages configured on IIS, which were only meant for internal use, but later decided it would need to be reached externally. Therefore, we decided to provide it with it’s own Public IP but via the Fortigate to retain security. An example of such a web page is:
Example of a NAT configuration:
You can see in the above screenshot, that 10.100.1.7 NAT’d to 10.110.0.4. Remember even though it looks like we’re NATing a Private IP to another Private IP, 10.100.1.7 is actually NATd by Azure to 172.166.190.32, so in essence we’re NATing 172.166.190.32 to 10.110.1.4. (This process is called Virtual IP in Fortigate Terminology, we’re actually performing 1:1 NAT as per Cisco’s terminology)
Here under Firewall Policy in Fortigate’s Web Interface, we can see a Firewall Rule has been created to allow all traffic coming into Port 1 (Port 1 is NIC1) to then be sent to Port 2 (Port 2 is NIC2) and the Destination is the 1:1 NAT rule (VIP we created) with NAT toggled on. This may sound like Port 1 and Port 2 are in the wrong order because previously we said Port 2 is the inbound interface and Port 1 is the outbound interface, but for this rule we’re dictating what is allowed to come in, hence why it is in this order.
However, when you create any Firewall rule in Forti Web Interface, you have to recreate that rule in the NSG of the VM hosting the Fortigate (remember because it’s hosted in a virtual machine, so you need to create the rule in the NSG of said Virtual Machine)
You can see above the rule bbox-https-test, it’s allowed all traffic as long as it’s on port 443 to 0.0.0.0/0 (meaning any interface of the VM but this is the same as specifying 10.100.1.7 (which is the Fortigatge IP on NIC1 used for BlueBox (as per the rules we created)
Again, this rule is recreated on BlueBox VM’s NSG, to allow all traffic from port 443 to “Any” which is the same as specifying the IP of the server, because it’s not a router, so as long as you specify “Any” or it’s Private IP it achieves the same purpose. I covered the name only because it’s a confusing old name.