Lab 6 - FIRENET

Lab 6 - FIRENET#

1. Objective#

The objective of this lab is to learn how to deploy Palo Alto Networks (aka PAN) VM-series firewalls in the Transit VNet and inspect traffic between the two Spoke VNets using firewall policies.

2. FireNet Overview (Firewall Nework)#

Aviatrix Firewall Network (aka FireNet) is a turnkey solution to deploy and manage firewall instances in the cloud, as shown in the topology below. Firewall Network significantly simplifies virtual firewall deployment and allows the firewall to inspect VPC/VNet/VCN to VPC/VNet/VCN (East West) traffic, VPC/VNet/VCN to Internet (Egress) traffic, and VPC/VNet/VCN to on-prem including partners and branches (North South) traffic.

In addition, Firewall Network allows you to scale firewall deployment to multi AZ and multi instances/VMs in maximum throughput active/active state without the SNAT requirement.

3. Topology#

Up until now, in Azure you have only worked on azure-west-us-spoke1.

This lab will introduce finally azure-west-us-spoke2 GW, that is a gateway in the top-right corner of this topology that is already deployed (hence it is red), although its attachment has not been deployed yet!

../_images/lab7-topology.png

Fig. 188 Lab 7 Initial Topology#

4. Configuration#

4.1. Azure Transit to Spoke Peering#

First, you will need to configure the grey Aviatrix Spoke-Transit connection in the topology between azure-west-us-spoke2 and azure-west-us-transit.

Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways and edit the Spoke Gateway azure-west-us-spoke2, clicking on the pencil icon:

../_images/lab7-spoke.png

Fig. 189 Edit Spoke GW#

Attach azure-west-us-spoke2 (pre-configured VNet) to azure-west-us-transit as shown below. Do not forget to click on Save.

../_images/lab7-attachment.png

Fig. 190 Attachment#

Important

The azure-west-us-transit is already enabled for FireNet functionality.

4.2. PAN Firewall Deployment#

In this step you will be deploying a PAN firewall from the Aviatrix CoPilot with a Bootstrap package.

The bootstrap package will take care of the following pre-provisioning on the Firewall:

  • Interfaces mapping

  • Policies creation

  • Logging

Specifically, you will be deploying a firewall image called Palo Alto Networks VM-Series Next-Generation Firewall Bundle 1.

Aviatrix has already taken care of the subscription from the Azure Marketplace.

Go to CoPilot > Security > FireNet > Firewall, then click on the "+ Firewall" button.

../_images/lab7-firenetbutton.png

Fig. 191 FireNet#

Deploy a Firewall by entering these settings within the Deploy Firewall window:

  • FireNet Instance: azure-west-us-transit

  • Name: azure-west-us-pan

  • Firewall Image: Palo Alto Networks VM-Series Next-Generation Firewall Bundle 1

Warning

When you click on the Firewall Image drop-down window, you will see a "Loading" message. The message means that the Controller is in the middle of contacting the Marketplace through the API calls, therefore, be patient and wait for about 3 minutes!

../_images/lab7-marketplace.png

Fig. 192 Marketplace contact under loading#

  • Firewall Image Version: 9.1.0

  • Firewall instance Size: Standard_D3_v2

  • Management Interface Subnet: azure-west-us-transit-Public-gateway-and-firewall-mgmt-1 [Note: Make sure you do not select the subnets that begin with az-1, az-2, or az-3]

  • Egress Interface Subnet: azure-west-us-transit-Public-FW-ingress-egress-1 [Note: Make sure you do not select the subnets that begin with az-1, az-2, or az-3]

  • Authentication: Password

  • Username: avxadmin [Note: username admin is not permitted in Azure]

  • Password: [choose a strong password and remember it]

  • Bootstrap Configuration: turn ON the knob

  • Storage: Retrieve this from your pod info (Lab7 section)

  • Storage Access Key: Retrieve this from your pod info (Lab7 section)

  • File-Shared Folder: Retrieve this from your pod info (Lab7 section)

Then click on Deploy.

../_images/lab7-newone.png

Fig. 193 POD Portal: lab 7 section#

../_images/lab7-firenetcfg.png

Fig. 194 Firenet Deployment Template#

Warning

Please be patient - firewall deployment can take a long time, up to 20 minutes, due to the slow responsiveness of Azure API calls to prepare the firewall. Even after the firewall is created and is assigned a Public IP address, it doesn’t mean it can be accessed immediately. If you try accessing it too early, your experience may vary.

../_images/lab7-inprogress.png

Fig. 195 Deployment in progress#

At this time, the interface mapping, security policy configuration, and RFC1918 static route creation are all being handled. The Aviatrix Controller does a lot of magic in orchestrating and manipulating route tables.

You will know the Firewall is created when you see the corresponding entry like this (refresh the page after roughly 10-15 minutes):

../_images/lab7-url.png

Fig. 196 Deployment completed#

Even after that message, it doesn’t mean you can access the firewall (i.e. URL). Within 5-10 minutes after you receive confirmation about the firewall being created, you should be able to access it.

Now try to click on the hyperlink of the firewall. You should be able to see the page where entering the credentials (refer to you POD portal).

4.3. Firewall Configuration#

Once you access the firewall in your web browser via HTTPS, you might get a warning about an invalid certification based on your browser settings. This is just because it has a self-signed certificate. Navigate past that to get to the login prompt. Sign in as avxadmin as the username and the password you entered earlier.

../_images/lab7-paloalto.png

Fig. 197 PaloAlto Welcome page#

Dismiss the Welcome splash screen. This is an indication that the firewall is ready.

Do not end the firewall’s HTTPS session yet. You will return to this web interface later.

4.4. Firewall Vendor Integration#

Go to CoPilot > Security > FireNet > FireNet Gateways, click on the "three dots" symbol on the right-hand side of the azure-west-us-transit row, and then click on Vendor Integration.

../_images/lab7-vendor.png

Fig. 198 Vendor Integration#

Insert the following paramenters in the "Vendor Integration" pop-up window.

  • Management IP Address: Auto populated

  • Vendor: Palo Alto Networks VM-Series

  • Username: avxadmin

  • Password: [the password you entered earlier]

Then click on Save.

../_images/lab7-vendor2.png

Fig. 199 Vendor Integration template#

Note

Wait for some seconds for the Vendor Integration to complete.

If you see an error message related to the ethernet1/2, wait some additional minutes before clicking again on Save.

../_images/lab7-message.png

Fig. 200 Possible error message#

../_images/lab7-vendor3.png

Fig. 201 Vendor Integration accomplished successfully#

Go to CoPilot > Security > FireNet > Firewall and click on the azure-west-us-pan firewall

../_images/lab7-vendor4.png

Fig. 202 Click on the Firewall#

You will see the RFC 1918 routes that the Controller automatically programmed on the Firewall, through the "Vendor Integration". Notice how each RFC1918 route has a prefix of "AVX-" to show that it is programmed by Aviatrix.

../_images/lab7-vendor5.png

Fig. 203 Vendor Integration outcome#

Caution

IP address 168.63.129.16 is a virtual public IP address that is used to facilitate a communication channel to Azure platform resources. Customers can define any address space for their private virtual network in Azure. Therefore, the Azure platform resources must be presented as a unique public IP address.

4.5. Verify Routes Installed on Firewall#

Verify the same RFC 1918 routes exist on the PAN Firewall.

Back on the PAN Firewall, navigate to Network tab > Virtual Routers > click on default.

../_images/lab7-palo1.png

Fig. 204 PaloAlto dashboard#

Click on "Static Routes" tab. You should be able to see the same RFC 1918 routes with "AVX-" prefixes that were programmed by the Aviatrix Controller.

../_images/lab7-palo2.png

Fig. 205 Static Routes (RFC1918 routes)#

Caution

Do not end the firewall’s HTTPS session yet. You will return to this web interface later.

4.6. FireNet Policy#

Go to CoPilot > Security > FireNet > FireNet Gateways, click on the azure-west-us-transit Transit FireNet GW and then choose the "Policy" tab.

../_images/lab7-inspection2.png

Fig. 206 Policy tab#

Then select each Azure spoke gateway one by one, click on "Actions" and choose "Add" in order to add a specific VPC inside the Inspection Policy.

../_images/lab7-inspection3.png

Fig. 207 Inspection Policy assignment#

../_images/lab7-inspection4.png

Fig. 208 Inspection Policy accomplished#

5. Verification#

Verify the traffic flows within Azure and from Azure to GCP as shown below, by following steps 5.1 - 5.2:

../_images/lab7-topology2.png

Fig. 209 Lab 7 Topology with FW deployed and the Inspection Policy applied!#

5.1. Inside Azure#

Before we can verify connectivity, we need to associate azure-west-us-spoke2 to the Green Network Domain.

Go to CoPilot > Networking > Network Segmentation > Network Domains

Click the pencil icon to edit the Green network domain.

../_images/lab7-editnd.png

Fig. 210 Edit Green#

Select the gateway azure-west-us-spoke2 from the drop-down window, selecting the "Associations" field.

Then click Save:

../_images/lab7-nd2.png

Fig. 211 Association#

After this step, this is how the topology should look like:

../_images/lab7-finaltopology.png

Fig. 212 Lab 7 Final Topology#

Warning

On Lab 6 (Egress), the DCF functionality was enabled. The current permitted rules are the "Inspect-DNS", that is only allowing traffic towards UDP port 53, and the "allow-domains" , that is only allowing http/https traffic towards two domains. Any other kind of traffic is denied because of the presence of the "Explicit-Deny-Rule".

Before launching any connectivity tests, you need to move the Greenfield-Rule on the top of the list of the DCF rules!

../_images/lab7-dcfrule.png

Fig. 213 DCF rules#

  • Modify the Greenfield-Rule’s Priority

Tip

Go to CoPilot > Security > Distributed Cloud Firewall > Rules (default), click on the the "two arrows" icon on the righ-hand side of the Greenfield-Rule and choose "Move Rule" at the very Top. Then click on Save in Draft.

../_images/lab7-top.png

Fig. 214 Move at the Top#

Do not forget to click on Commit.

../_images/lab7-edit.png

Fig. 215 Commit your changes#

  • Apply the “Logging” option to the Greenfield-Rule

Tip

Click on the pencil icon beside the Greenfield-Rule row, then turn on the toggle for Logging and click on Save in Drafts.

Once again do not forget to click on Commit.

../_images/lab7-newone2.png

Fig. 216 Edit the Greenfield-Rule#

../_images/lab7-newone3.png

Fig. 217 Editing the Greenfield-Rule#

../_images/lab7-newone4.png

Fig. 218 Commit#

5.1.1 Launch connectivity test#

SSH into azure-west-us-spoke1-test1 and from there, ping azure-west-us-spoke2-test1 on its private IP.

../_images/lab7-ping.png

Fig. 219 Ping is successful#

Note

Pings are passing because the Allow-all rule on the Firewall is permitting traffic from any zone to any zone to pass.

Back on the PAN firewall, click on the Monitor tab. Then paste this string in the filter bar and hit Enter, which will apply the filter:

(addr in 192.168.1.10)
../_images/lab7-monitor2.png

Fig. 220 Monitor on the PaloAlto#

Traffic is passing through firewall because azure-west-us-spoke1 and azure-west-us-spoke2 both are in the Inspection Policy.

Tip

Click on the refresh button to see the logs almost in continuous stream.

../_images/lab7-smallrefresh.png

Fig. 221 Ping GCP#

5.2. Azure to GCP#

While on azure-west-us-spoke1-test1, ping gcp-us-central1-spoke1-test1.

../_images/lab7-pinggcp.png

Fig. 222 Ping GCP#

This still matches the Allow-all firewall rule. Moreover, it works because of the Connection Policy we had configured in the Network Segmentation Lab.

Back on the PAN firewall, click the refresh button in the top-right corner to see the log entries for pinging the GCP spoke test VM.

../_images/lab7-finalmonitor.png

Fig. 223 Monitoring traffic towards GCP#

After completing this Lab, the overall topology would look like this:

../_images/lab7-finaltopology2.png

Fig. 224 Final Topology for Lab 6#

  • Explore the logs on the Monitor section of the Distributed Cloud Firewall. Filter out based on protocol ICMP.

Tip

Go to CoPilot > Security > Distributed Cloud Firewall > Monitor

../_images/lab7-newlog.png

Fig. 225 Filter based on ICMP#

../_images/lab7-last.png

Fig. 226 Logs on DCF Monitor section#

Important

The same policy is present on both the PaloAlto firewall and on the Spoke Gateway…

Maybe it’s time to finally embrace the full-blown "Distributed Cloud Firewall" solution, and getting rid of the NGFW!