1. Objective
This lab will demonstrate how the Distributed Cloud Firewall work.
2. Distributed Cloud Firewall Overview
The Distributed Cloud Firewall feature allows to create logical containers, called Smart Groups, that encompass instances that present similarities inside a VPC/VNet/VCN, and then it also allows to enforce rules (aka Distributed Firewalling) within a Smart Group (i.e. the intra-rule) or among Smart Groups (i.e. the inter-rule).
Note: At this point in the lab, there is a unique routing domain, due to the connection policy applied in Lab 3, between the Green domain and the Blue domain.
All the Test instances have been deployed with the typical CSP tags. This is the recommended method for classifying instances.
In this lab you are asked to achieve the following requirements among the instances deployed across the three CSPs:
- Create a Smart Group with the name "bu1" leveraging the tag "environment"
- Create a Smart Group with the name "bu2" leveraging the tag "environment"
- Create an intra-rule that allows ICMP traffic within bu1
- Create an intra-rule that allows ICMP traffic within bu2
- Create an inter-rule that allows ICMP traffic only from bu1 towards bu2
3. Smart Group Creation
Create two Smart Groups and classify each Smart Group, leveraging the CSP tag "environment":
- Assign the name "bu1" to the Smart Group #1
- Assign the name "bu2" to the Smart Group #2
3.1. Smart Group “bu1”
Go to CoPilot > SmartGroups and click on "+ SmartGroup".
Ensure these parameters are entered in the pop-up window "Create New SmartGroup":
- Name: bu1
- CSP Tag Key: environment
- CSP Tag Value: bu1
Before clicking on SAVE, discover what instances match the condition, turning the knob "Resource Selection".
The CoPilot shows that there are two instances that perfectly match the condition:
- aws-us-east2-spoke1-test 1 in AWS
- azure-us-west-spoke1-test1 in Azure
3.2. Smart Group “bu2”
Create another Smart Group clicking on the "+ SmartGroup" button.
Ensure these parameters are entered in the pop-up window "Create New SmartGroup":
- Name: bu2
- CSP Tag Key: environment
- CSP Tag Value: bu2
Before clicking on SAVE, discover what instances have matched the condition, turning the knob "Resource Selection".
The CoPilot shows that there are two instances that match the condition:
- azure-us-west-spoke2-test1 in Azure
- gcp-us-central1-spoke1-test1 in GCP
At this point, you have only created logical containers that do not affect the existing routing domain.
Let's verify that everything has been kept unchanged!
3.3. Connectivity verification (ICMP)
Open a terminal window and SSH to the public IP of the instance aws-us-east2-spoke1-test1, and from there ping the private IP of each other instances to verify that the connectivity from AWS to GCP and Azure has not been modified.
Note: Refer to your POD for the private IPs.
3.4. Connectivity verification (SSH)
Verify also from the instance aws-us-east2-spoke1-test1 that you can SSH to the instance in GCP and to the other two instances in Azure.
Note: Refer to your POD for the private IPs.
The previous outcomes confirm undoubtetly that the creation of the Smart Groups has not changed anything in the routing.
4. Rules Creation
4.1. Create an intra-rule that allows ICMP inside bu1
Go to CoPilot > Security > Distributed Cloud Firewall > Rules (default tab) and enable the feature.
Create a rule clicking on the "+ Rule" button.
Ensure these parameters are entered in the pop-up window "Create New Rule":
- Name: intra-icmp-bu1
- Source SmartGroups: bu1
- Destination SmartGroups: bu1
- Protocol: ICMP
- Enforcement: On
- Logging: On
- Action: Permit
- Place Rule: Top
then Click on Save In Drafts.
At this point, there would be one uncommitted rule, as depicted below.
4.2. Create an intra-rule that allows ICMP inside bu2
Create another rule clicking on the "+ Rule" button.
Ensure these parameters are entered in the pop-up window "Create New Rule":
- Name: intra-icmp-bu2
- Source SmartGroups: bu2
- Destination SmartGroups: bu2
- Protocol: ICMP
- Enforcement: On
- Logging: On
- Action: Permit
- Place Rule: Bottom
then Click on Save In Drafts.
At this point, you will have two rules marked in New state, therefore you can proceed and click on the Commit button.
5. Verification
Afte the creation of the previous Smart Groups and Rules, this is how the topology with the permitted protocols should look like:
5.1. Verify SSH traffic from your laptop to bu1
SSH to the Public IP of the instance aws-us-east2-spoke1-test1.
5.2. Verify ICMP traffic within bu1
Ping the following instances from aws-us-east2-spoke1-test1:
- gcp-us-central1-spoke1-test1 in GCP
- azure-us-west-spoke1-test1 in Azure
- azure-us-west-spoke2-test1 in Azure
According to the rules created before, only the ping towards the azure-us-west-spoke1-test1 will work, because this instance belongs to the same Smart Group bu1 as the instance from where you will be launching ICMP packets.
Let's investigate the logs:
Go to CoPilot > Security > Distributed Cloud Firewall > Monitor
5.2. Verify SSH within bu1
SSH to the Private IP of the instance azure-us-west-spoke1-test1 in Azure. Despite the fact that the instance is within the same Smart Group "bu1", the SSH will fail due to the absence of a rule that would permit SSH traffic within the Smart Group.
5.3. Add a rule that allows SSH in bu1
Create another rule clicking on the "+ Rule" button.
Ensure these parameters are entered in the pop-up window "Create New Rule":
- Name: intra-ssh-bu1
- Source SmartGroups: bu1
- Destination SmartGroups: bu1
- Protocol: TCP
- Port: 22
- Action: Permit
- Enforcement: On
- Logging: On
- Action: Permit
- Place Rule: Bottom
then Click on Save In Drafts.
Click on "Commit" to enforce the new rule in the Data Plane.
Try once again to SSH to the Private IP of the instance azure-us-west-spoke1-test1 in Azure.
This time the connection will be established, thanks to the new intra-rule.
Let's investigate the logs once again.
Go to CoPilot > Security > Distributed Cloud Firewall > Monitor
From the log above is quite evident that the intra-ssh-bu1 rule is permitting SSH traffic within the SmartGroup bu1, successfully.
After the creation of the previous intra-rule, this is how the topology with the permitted protocols should look like:
5.4. SSH to VM in bu2
SSH to the Public IP of the instance gcp-us-central1-spoke1-test1:
5.5.Verify ICMP traffic within bu2
Ping the following instances:
- aws-us-east2-spoke1-test1 in AWS
- azure-us-west-spoke1-test1 in Azure
- azure-us-west-spoke2-test1 in Azure
According to the rules created before, only the ping towards the azure-us-west-spoke2-test1 will work, because this instance belongs to the same Smart Group bu2 as the instance from where you will be launching ICMP packets.
Let's investigate the logs once again.
Go to CoPilot > Security > Distributed Cloud Firewall > Monitor
The logs above confirm that the ICMP protocol is permitted within the SmartGroup bu2.
5.6. Inter-rule between bu1 and bu2
Create a new rule that allows ICMP between bu1 and bu2.
Go to CoPilot > Security > Distributed Firewalling > Rules and click on the "+ Rule" button.
Ensure these parameters are entered in the pop-up window "Create New Rule":
- Name: inter-icmp-bu1-bu2
- Source SmartGroups: bu1
- Destination SmartGroups: bu2
- Protocol: ICMP
- Enforcement: On
- Logging: On
- Action: Permit
- Place Rule: Bottom
then Click on Save In Drafts.
Enforce the this new rule in the data plane clicking on the "Commit" button.
SSH to the Public IP of the instance aws-us-east2-spoke1-test1.
Ping the following instances:
- gcp-us-central1-spoke1-test1 in GCP
- azure-us-west-spoke1-test1 in Azure
- azure-us-west-spoke2-test1 in Azure
Thit time all pings will be successful, thanks to the inter-rule applied between bu1 and bu2.
Let's investigate the logs once again.
Go to CoPilot > Security > Distributed Cloud Firewall > Monitor
The logs clearly demonstrate that the inter-rule is successfully permitting ICMP traffic from bu1 to bu2.
After the creation of the previous inter-rule, this is how the topology with all the permitted protocols should look like.
Note: the last inter-rule works smoothly only because the ICMP traffic is generated from the bu1, however, if you SSH to any instances in the Smart Group bu2, the ICMP traffic towards bu1 will fail due to the direction of the inter-rule that was created before: FROM bu1 TO bu2 (please note the direction of the arrow in the drawing).
The inter-rule is Stateful in the sense that it will permit the echo-reply generated from the bu2 to reach the instance in bu1.
6. East-1 and the Multi-Tier Transit
6.1 Activation of the MTT
Let’s now also involve the AWS region US-EAST-1.
This time, you have to allow the ICMP traffic between the Smart Group bu2 and the ec2 instance aws-us-east1-spoke1-test2, solely.
SSH to the Public IP of the instance azure-us-west-spoke2-test1.
Ping the following instance:
- aws-us-east1-spoke1-test2 in AWS
The ping fails, therefore, let’s check the routing table of the Spoke Gateway azure-us-west-spoke2.
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways > select the concerned gateway azure-us-west-spoke2
Then click on the “Gateway Routes” tab and check whether the destination route is present in the routing table or not.
Note: The destination route is not inside the routing table, due to the fact that the Transit Gateway in AWS us-east-1 region has only one peering with the Transit Gateway in us-east-2, therefore the Controller will install the routes that belong to us-east-1 only inside the routing tables of the Gateways in AWS us-east-2, excluding the rest of the Gateways of the MCNA. If you want to distribute the routes from AWS us-east-1 region in the whole MCNA, you have two choices:
- Enabling Full-Mesh on the Transit Gateways in aws-us-east1-transit VPC
OR
- Enabling Multi-Tier Transit
Let’s enable this time the MTT feature!
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways and click on the Transit Gateway aws-us-east1-transit.
Go to Settings tab and expand the “Border Gateway Protocol (BGP)” section and insert the AS number 64512 on the empty field related to the “Local AS Number”, then click on Save.
Repeat the previous action for the remaning Transit Gateways:
- aws-us-east2-transit: ASN 64513
- gcp-us-central1-transit: ASN 64514
- azure-us-west-transit: ASN 64515
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways and click on the Transit Gateway aws-us-east2-transit.
Go to Settings tab and expand the “General” section and activate the Multi-Tier Transit, turning the knob. Then click on Save.
Let’s verify once again the routing table of the Spoke Gateway in azure-us-west-spoke2.
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways > select the concerned gateway azure-us-west-spoke2
This time if you click on the “Gateway Routes” tab, you will be able to see the destination route in aws-us-east1-spoke1 VPC.
SSH to the Public IP of the instance azure-us-west-spoke2-test1.
Ping the following instance:
- aws-us-east1-spoke1-test2 in AWS
Although this time there is a valid route to the destination, thanks to the MTT feature, the pings fails. The reason is that the ec2-instance in aws-us-east1-spoke1 VPC is not allocated to any Smart Groups yet.
6.2 Smart Group “east1”
Let’s create another Smart Group for the test instance in AWS us-east-1 region.
Go to Copilot > SmartGroups and click on "+ SmartGroup" button.
Ensure these parameters are entered in the pop-up window "Create New SmartGroup":
- Name: east1
- CSP Tag Key: Name
- CSP Tag Value: aws-us-east1-spoke1-test2
Before clicking on SAVE, discover what instances have matched the condition, turning the knob "Resource Selection".
The CoPilot shows that there is just one single instance that matches the condition:
- aws-us-east1-spoke1-test2 in AWS
Do not forget to click on Save.
6.3 Create an inter-rule that allows ICMP from bu2 towards east1
Go to CoPilot > Security > Distributed Cloud Firewall > Rules (default tab) and create another rule clicking on the "+ Rule" button.
Ensure these parameters are entered in the pop-up window "Create New Rule":
- Name: inter-icmp-bu2-east1
- Source SmartGroups: bu2
- Destination SmartGroups: east1
- Protocol: ICMP
- Enforcement: On
- Logging: On
- Action: Permit
- Place Rule: Bottom
Then Click on Save in Drafts.
Note: Please note the direction of this new inter-rule: FROM bu2 TO east1:
Proceed with the last commit!
6.4 Verify connectivity between bu2 and east1
SSH to the Public IP of the instance azure-us-west-spoke2-test1 and ping the private IP of the ec2-instance aws-us-east1-spoke1-test2
This time the ping will be successful.
Congratulations, you have deployed the full-blown Aviatrix solution!
