This feature can allow users to only access specific domains by whitelisting and/or blacklisting FQDNs. In many high-security environments, outgoing traffic is filtered using the Distributed firewall. When you want to access an external service, you usually create IP-based firewall rules. In some cases, you don’t know which IP addresses hide behind a domain. This is where domain filters come in handy.
Because NSX-T Data Center uses DNS Snooping to obtain a mapping between the IP address and the FQDN, you must set up a DNS rule first, and then the FQDN allowlist or denylist rule below it.
SpoofGuard should be enabled across the switch on all logical ports to protect against the risk of DNS spoofing attacks. A DNS spoofing attack is when a malicious VM can inject spoofed DNS responses to redirect traffic to malicious endpoints or bypass the firewall
You can define specific FQDNs that are allowed and apply them to DFW policies. Conversely, you can define specific FQDNs that are denied access to applications in the SDDC. The DFW maintains the context of VMs when they migrate. You can then increasingly rely on application profiling and FQDN filtering to reduce the attack surface of their applications to designated protocols and destinations.
Configuring DFW with FQDN filtering
In this section, I will show you how to setup a FQDN Context Profile, and a Firewall policy to limit access to specific URLs from VMs.
Creating a FQDN Context Profile.
First thing first ! Let’s create the context Profile.
Under Networking and Security, in the Inventory section, click Context Profile.
Click FQDNs Tab
Click ACTIONS –> Add FQDN
Enter the Domain: *.yahoo.com, and then Click SAVE.
Create a second FQDN with *.google.com.
Click the Context Profile Tab, and Click ADD CONTEXT PROFILE
Give it a Name: Allowed FQDNs, Click Set
Click ADD ATTRIBUTE –> Domain(FQDN) Name
Select the following domains: *.yahoo.com, *.office.com, *.google.com and Click ADD.
Click APPLY, Click SAVE. We now have a Context Profile setup.
Creating a Firewall rule and a Policy
I have created a Group called MyDesktops which includes a segment with my Windows VMs.
Now I am going to setup a Firewall Policy including this Context Profile. I will limit my VM in the MyDesktops group to access to the Allowed FQDNs. Also I limit access from this Group of VMs to specific DNS servers (18.104.22.168, 22.214.171.124).
I also add a Drop rule at the end to limit access to only the FQDNs that were whitelisted.
Now I am allowed to access google.com and Yahoo.com but I can’t connect anymore to the vmware.com site.
VMware Cloud on AWS already offers a robust sets of networking and security capabilities that enable customers to run production applications securely in the cloud.
The release of the M16 version is introducing new Advanced Firewall Features as an Add-on.
This includes the following new security capabilities:
L7 Distributed (Context Aware) Firewall with application ID – With L7 (Context-aware) firewall you can go beyond simple IP/ port level layer 4 security to complete stateful layer 7 controls and filtering.
L7 Distributed Firewall with FQDN Filtering – Applications that communicate outside the SDDC also gain layer 7 protection using Distributed Firewall FQDN filtering capability. Customers can define specific FQDNs you can define specific FQDNs that are denied access to applications in the SDDC. The DFW maintains the context of VMs when they migrate. Customers increasingly rely on application profiling and FQDN filtering to reduce the attack surface of their applications to designated protocols and destinations.
User Identity Firewall – You can create groups based on User ID and define DFW rules to control access to virtual desktops and applications in the SDDC. Per user/ user session access control limits the amount of time and exposure users have to desktops or applications. Integration with Active Directory / LDAP enables the DFW to continuously curate user access to applications. User ID based rules are enforced by the DFW at the source, delivering pervasive, intrinsic security throughout the SDDC.
Distributed IDS/IPS – With NSX Distributed IDS/ IPS, customers gain protection against attempts to exploit vulnerabilities in workloads on VMware Cloud on AWS. Distributed IDS/ IPS is an application-aware deep packet inspection engine that can examine and protect traffic inside the SDDC.
Let’s try them to see how it works!
Enabling the NSX Advanced Firewall Add-On
The NSX Advanced Firewall Add-on adds Layer-7 Firewall protection, Identity Firewalling, Distributed IDS/IPS and FQDN Filtering to the VMC on AWS SDDC. This Feature is an Add-on featured and priced in addition to the Standard VMC on AWS subscription.
Before any of these features can be used, you must first enable the add-on onto your SDDC. In the following section, I am going to walk you through the steps of enabling the NSX Advanced Firewall functionality onto your SDDC.
On your SDDC tile, click View Details
Click the Add-Ons tab
In the NSX Advanced Firewall Tile, click Activate
Click OPEN NSX ADVANCED FIREWALL (This will take you to the Networking & Security Tab)
At this step, the NSX Advanced Firewall Add–on has been enabled. To make use of the functionality it provides, you must configure them individually.
In the upcoming sections, we will configure and test each of these features.
Configuring L7 Distributed Context Aware Firewall
With L7 (Context-aware) firewall, it’s possible to go beyond simple IP/ port level layer 4 security to complete stateful layer 7 controls and filtering. This will avoid for instance someone from changing Port number to bypass a firewall rule.
Extremely powerful !
Deep packet inspection (DPI) built into the Distributed Firewall enables you to allow only the intended application / protocols to run, while denying all other traffic at the source. This enables you to isolate sensitive applications by creating virtual zones within the SDDC.
Distributed Firewall (DFW) layer 7 policies are enforced at the hypervisor (vNIC) level and can migrate with the VM when they move from host to host in the SDDC, ensuring there are no gaps in enforcement.
Let’s see how to configure and use the feature.
Configuring a standard L4 FW rule
In my example, I have two VMs (webserver01, webserver02) running in my SDDC which are part of a group called Web Tier.
Here are the IPs of the VMS:
They can communicate together over any protocol as this is the default settings in the Distributed Firewall as we can see here:
First let’s create a traditional L4 firewall rule to block SSH traffic between the two VMS.
Now if I want to ssh from webserver01 to webserver02 it’s blocked:
What if SSH was listening on another port, however? What if some nefarious person (knowing SSH on port 22 is being blocked) changed the port the server listens on and attempts to SSH to the server against this new port, what happens then?
To do that I have edited the sshd_config on the webserver02 VM and changed the port to 2222:
I have then restarted the ssh service on the VM:
We can see the ssh server is now running on port 2222:
Let see what happens when we apply context awareness to the firewall rule.
now if I try to connect back but on port 2222, it works!
Unfortunately, the L4 DFW doesn’t block it. As mentioned earlier the firewall is looking for SSH on port 22, not port 2222, so I was able to bypass the firewall policy.
Configuring Context Aware Firewall rule
NSX Context-Aware Firewall Rule (L7) enhances visibility at the application level and helps to override the problem of application permeability. Visibility at the application layer helps you to monitor the workloads better from a resource, compliance, and security point of view.
In order to switch to the Context Aware firewall, I just have to remove the SSH in the Service field from the DFW rule and need to add SSH in the Context Profile field:
The rule is now changed:
Let’s try to connect again to port 2222:
Now the attempt to connect to the modified port is block. That’s much better! This is because the DFW now assesses the packet at layer 7 and identifies the heuristics of the packet to be ssh and does not allow the traffic through.
With Context-Aware Firewalling you can enable enforcement of security protocol versions/ciphers reduce attacks by only allowing traffic matching APP Fingerprint, and enforce port-independent rules.
In the next post I will introduce you to the L7 Distributed Firewall with FQDN Filtering. Stay tune!
The latest M12 releaseof SDDC (version 1.12) came with a lot of interesting storage features including vSAN compression for i3en, TRIM/UNMap (I will cover it in a future post) as well as new networking features like SDDC Groups, VMWare Transit Connect, Time-based Scheduling of DFW rules and many more.
One that typically stands out for me is the Multi-Edge SDDC capabilities.
Multi-Edge SDDC (or Edge Scaleout)
By default, any SDDC is deployed with a single default Edge (actually this a pair of VMs) which size is based on the SDDC sizing (Medium size by default). This edge can be resized to Large when needed.
Each Edge has three logical connections to the outside world: Internet (IGW), Intranet (TGW or DX Private VIF), Provider (Connected VPC). These connections share the same host Elastic Network Adapter – ENA and it’s limits.
In the latest M12 version of VMC on AWS, VMC is adding Multi-Edge capability to the SDDC. This gives the customer the ability to add additional capacity for North-South network trafic by simply adding additional Edges.
The goal of this feature is to allow multiple Edge appliances to be deployed, therefore removing some of the scale limitations by:
Using multiple host ENAs to spread network load for traffic in/out of the SDDC,
Using multiple Edge VMs to spread the CPU/Memory load.
In order to be able to enable the feature, additional network interfaces (ENA) are going to be provisioned in the AWS network and additional compute capacity are created.
It’s important to mention that you do need additional hosts in the management clusters of the SDDC to be able to support it. So this feature is coming with an additional cost.
Multi-Edge SDDC – Use Cases
The deployment of additional Edges allow for an higher network bandwidth for the following use cases:
SDDC to SDDC connectivity
SDDC to natives VPCs
SDDC to on-premises via Direct Connect
SDDC to the Connected VPC
Keep in mind that for the first three, VMWare Transit Connect is mandatory to allow the increased network capacity by deploying those multiple Edges. As a reminder, Transit Connect is a high-bandwidth, low latency and resilient connectivity option for SDDC to SDDC communication in an SDDC groups. It also enables an high bandwidth connectivity to SDDCs from natives VPCs. If you need more information on it, my colleague Gilles Chekroun has an excellent blog post here.
Multiple Edges permits to steer certain traffic sets by leveraging Traffic Groups.
Traffic Groups is a new concept which is similar in a way to the source Based Routing. Source based routing allow to select which route (next hop) to follow based on the source IP addresses. This can be an individual IP or complete subnet.
With this new capability customer can now choose to steer certain traffic sets to a specific Edge.
At the time you will create a traffic group, an additional active edge (with a standby edge) is going to be deployed on a separate host. All Edge appliances are deployed with an anti-affinity rule to ensure only one Edge per host. So there need to be 2N+2 hosts in the cluster (where N=number of traffic groups).
Each additional Edge will then handles traffic for its associated network prefixes. All remaining traffic is going to be handled by the Default Edge.
Source base routing is configured with prefixes defined in prefix lists than can be setup directly in the VMC on AWS Console.
To ensure proper ingress routing from AWS VPC to the right Edge, the shadow VPC route tables are also updated with the prefixes.
Multi-Edge SDDC requirements
The following requirements must be met in order to leverage the feature:
SDDC M12 version is required
Transit Connect for SDDC to SDDC or VPC or SDDC to on-prem
SDDC resized to Large
Enough capacity in the management cluster
A Large SDDC means that management appliances and Edge are scaled out from Medium to Large. This is now a customer driven option that doesn’t involve technical Support anymore as it’s possible to upsize an SDDC directly from the Cloud Console.
Large SDDC means an higher number of vCPUs and memory for management components (vCenter, NSX Manager and Edges) and there is a minimal 1 hour downtime for the upscaling operations to finish, so it has to be planned during a Maintenance Window.
Enabling a Multi-Edge SDDC
This follow a three step process.
First of all, we must define a Traffic Group that is going to create the new Edges (in pair). Each Traffic group creates an additional active/standby edge. Remember also the “Traffic Group” Edges are always Large form-factor.
Immediately you will see that 2 additional edge Nodes are going to be deployed. The New Edges have a suffix name with tg in it.
Next step you have to define a prefix list with specific prefixes and associate a Prefix List. It will contain the source IP adresses of SDDC virtual machines that will use the newly deployed Edge.
After some minutes, you can confirm that the Traffic groups is ready:
NB: NSX-T configures source based Routing with the prefix you define in the prefix list on the CGW as well as the Edge routers to ensure symmetric routing within the SDDC.
You just need to click on Set to enter the prefix list. Enter the CIDR range, it could a /32 if you just want to use a single VM as a source IP.
NB: Up to 64 prefixes can be created in a Prefix List.
When you done entering the subnets in the prefix list, Click Apply and Save the Prefix List to create it.
Last step is to associate the Prefix List to the Traffic Group with Association Map. To do so click on Edit.
Basically we now need to tell what prefix list to use for the traffic group. Click on ADD IP PREFIX ASSOCIATION MAP:
Then we need to enter the Prefix List and give a name to the Association Map.
Going forward any traffic that matches that prefix list will be utilising the newly deployed Edge.
Monitoring a Multi-Edge SDDC
Edge nodes cannot be monitored on VMC Console but you can always visualise the Network Rate and consumption through the vCenter web console.
When we look at the vCenter list of Edges, the default Edge has no “-tg” in its name. So basically the NSX-Edge-0 is the default. As long as we add the new traffic group, the traffic is going to manage the additional traffic and liberate the load on this default Edge.
The NSX-Edge-0-tg-xxx is the new one and we can see an increase on this new Edge in the traffic consumption on it now because of the new traffic going to flow over it:
What happened also after the new scale edge is deployed, is that the prefix list is using the new Edge as its next-hop going forward. This is also propagated to the internal route tables from Default Edge as well as CGW route table.
All of these feature is exposed over the API Explorer, for the traffic Groups definition in the NSX AWS VMC integration API. Over the NSX VMC Policy API for the prefix list definition perspective.
In conclusion, remember that Multi Edge SDDC doesn’t increase Internet capacity nor VPN or NAT capacity. Also that there is a cost associated to it because of the additional hardware requirements.
In the previous posts of this series on Configuring a VPN connection from WatchGuard TM Firebox to VMC, I have showed you how to setup the Firebox and how to establish a VPN with a native VPC.
In this last post, I will attach the SDDC to the WatchGuard Firebox instance with a IPSEC route-based VPN leveraging BGP to allow for dynamic routes exchange.
With this configuration, any compute and management segments created inside the SDDC will be the advertised into the BGP session established with the Firebox in the transit VPC.
Firebox to SDDC IPSec VPN configuration
Phase 1 – VPN’s VPC configuration
First of all I need to collect the public IP address of my SDDC. This is possible by logging to the VMC Console and going to the Networking and Security tab, and Selecting the Overview window:
N.B.: You can also request additional public IP addresses to assign to workload VMs to allow access to these VMs from the internet. VMware Cloud on AWS provisions the IP address from AWS.
Next I’ll collect the BGPlocal ASN number of the SDDC. Just like IP addresses, ASNs (Autonomous System Numbers) have to be unique on the Internet and the SDDC utilises two numbers: one for the route-based VPN and one for Direct Connect.
To do that I Click on Edit Local ASN option in the VPN window:
Clicking EDIT LOCAL ASN displays the Local ASN of the SDDC as shown here:
The local ASN of any brand new SDDC is by default at 65000. You can change it to a value in the range 64521 to 65535 (or 4200000000 to 4294967294).
N.B.: Keep in mind that the remote BGP ASN number need to be different.
Now it’s time to create a new Customer Gateway and map it to the SDDC settings.
Create a New Customer Gateway
For that I need to go back to the AWS console and Go to the VPC Dashboard and Select Customer Gateways under VIRTUAL PRIVATE NETWORK Menu on the left.
I Click Create Customer Gateway and choose Dynamic as a routing option, and add the public Elastic-IP address of the SDDC public IP.
I also need to specify the BGP ASN to the SDDC value (65000 by default). Note that it has to be different from the BGP ASN of the Firebox in the transit VPC.
Phase 2 – FireBox’s VPN Configuration
Now I have to setup the VPN configuration on the Firebox itself. For this, I connect back to the Fireware Web UI:
Open a web browser and go to the public IP address for your instance of Firebox Cloud at: https://<eth0_public_IP>:8080
Log in with the admin user account. Make sure to specify the passphrase you set in the Firebox Cloud Setup Wizard.
Select VPN, BOVPN Virtual Interfaces on the left and click the lock to open the settings window.
Enter a name for the interface (eg. BoSddc) and switch the Remote Endpoint Type to Cloud VPN or Third-Party Gateway.
In the Gateway Settings-> Credential Method, Enter a Use Pre-Shared Key (note the key as you will have to use it in the SDDC setup):
In the Gateway Settings–>Gateway Endpoint–>Click ADD.
Select Local Gateway–>Interface: Select Physical: External
Specify the gateway ID for tunnel authentication: Select By IP address:34.210.196.xxx (this is the public Elastic-IP of the Watchguard Firebox)
Select Remote Gateway–>Specify the remote gateway IP address for a tunnel: a the Static IP Address has to be set to the Public IP address of the SDDC:
Next Step, Select Advanced tab and Click OK
Configure Phase 1 of IPSEC Proposal
Check ‘Start Phase1 tunnel when it is inactive‘ and Keep the ‘Add this tunnel to the BOVPN-Allow policies‘ checked.
The Phase 1 Settings should be as follow: 1. Version: IKEv1 2. Mode: Main 3. Uncheck NAT Traversal
N.B.: NAT Traversal is enabled by default but if your WatchGuard device is not behind a NAT/PAT device, please deselect NAT Traversal.
Dead Peer Detection: a. Traffic idle timeout: 10 b. Max retries: 3
Transform Settings–>Click ADD:
1. Authentication: SHA1 2. Encryption: AES(128-bit) 3. SA Life: 8 hours 4. Key Group: Diffie-Hellman Group 2
Remove any pre-existing Phase 1 Transform Settings eg. SHA1-3DES.
VMC on AWS allows to create up to 4 IPSEC route-based VPN tunnels to be established between Firebox/VPC and your SDDC. To create the VPN on the SDDC side, you first have to Connect to the SDDC console.
Then you need to Go to the Networking & Security tab.
Select Network -> VPN and Click on the Route Based tab.
Click ADD VPN.
Next, you have to enter the following configuration settings:
First give a name to the IPSec VPN (eg. TOFirebox).
Select Local Public IP1 of the SDDC: this is the public IP address of the SDDC. As the Remote Public IP, Select the Elastic IP that was assigned to the public interface of the Watchguard Firebox FW. The Remote private IP is automatically entered.
For the BGP Local IP/Prefix Length, choose the following: 169.254.85.185/30.
The BGP Remote IP is the Local IP configured previously in the VPN Routes of the BOVPN Virtual interfaces: 169.254.85.186.
BGP Neighbor ASN has to be he remote ASN of the WatchGuard Firebox: 65001.
Tunnel Encryption: AES128
Digest Algorithm: SHA-1
Diffie-Hellman: Group 2
IKE Encryption: AES128
IKE Digest: SHA-1
IKE Type: V1
After a few seconds, we can see that the VPN is up!
In this Part, I will show you how to configure an IPsec VPN from the “spoke” native VPC to the Firebox instance deployed in the transit VPC. This permits to leverage the Watchguard Firewall instance in the transit VPC as a filtering device from any trafic coming outside (SDDC, spoke VPC, on-prem).
Phase 1 – VPC’s VPN Configuration
In order to configure the VPN in the VPC, I need to do some preparation in the native VPC which consists in creating a Customer Gateway, a Virtual Private Gateway and attach them together.
To do so, let’s first Connect to the AWS console again!
Go to VPN–>BOVPN Virtual Interfaces–>Select vpn-054bfd003f8ac9d2d-1–>Click EDIT
In the Interface window, keep ‘Assign virtual interface IP addresses‘ option checked:
Go to Network–>Dynamic Routing
Check ‘Enable Dynamic Routing’
Click on ‘BGP’ tab:
Add the BGP dynamic routing configuration commands in the box as seen above.
We have to add the line: router bgp 65001 but only once at the beginning of the BGP config.
Phase 4 – Check tunnel is established
Go back to AWS Console to check VPN are established:
AWS allows the creation of a second tunnel to be established between the spoke VPC and the Firebox instance. To create the second VPN session, create a second tunnel by following the same instruction as above with the parameters described in the configuration file downloaded earlier.
That concludes the Part 3 of this post. In the next final Part, I will show you how to establish a VPN from SDDC to the Firebox instance in the transit VPC.
In Part 1 of this blog post, we have deployed a new transit VPC with two subnets and a route table configured accordingly.
Now it’s time to deploy a WatchGuard FW cloud EC2 instance in the transit VPC. This is possible from the EC2 dashboard:
After logging on the AWS Console with my personal AWS account, I have selected Services > EC2.
In the EC2 Dashboard, I can easily launch a new instance by Clicking on Launch instance (easy :=)),
I have selected AWS Marketplace and type ‘firebox’ in the search window and have decided to pick the Watchguard Firebox Cloud (Hourly) AMI.
You will get the pricing details and Click Continue
Select the smallest available instance with free tier t2.micro instance type and click Next: Configure Instance details
The configure Instance Details step opens.
From the Network drop-down list, select your transit VPC :
From the Subnet drop-down list, select the public subnet to use for eth0. The subnet you select appears in the Network Interfaces section for eth0.
To add a second interface, in the Network interfaces section, click Add Device. Eth1 is added to the list of network interfaces.
Click Next: Add Storage
Use the default storage size (5 GB).
Click Next: Add Tags
Click Next: Configure Security Group. By default, the instance uses a security group that functions as a basic firewall. This security group restricts following ports: HTTPS (TCP 8080), SSH, TCP 4118 (WatchGuard Firewalls may allow remote management using WSM (WatchGuard System Manager) over ports 4117, 4118 TCP).
Click Review and Launch. The configured information for your instance appears.
Click Launch. The key pair settings dialog box opens.
Phase 3 – Finish configuring the instance of the Firebox
In this phase we will finish configuring the EC2 instance of our Firebox.
Once the firewall is deployed, from the EC2Dashboard, Click on the instance option, the new instance should appear as here:
Disable Source/Destination Checks
By default, each EC2 instance completes source/destination checks. For the networks on your VPC to successfully use your instance of Firebox Cloud for NAT, you must disable the source/destination check for the network interfaces assigned to the Firebox Cloud instance.
Disabling source/destination checks for the public interface is quite simple:
From the EC2 Management Console, select Instances > Instances.
Select the instance of Firebox Cloud.
Select Actions > Networking > Change Source/Dest. Check. The confirmation message includes the public interface for this instance.
Click Yes, Disable. The source and destination checks are disabled for the public & private interface.
Assignan Elastic IP Address to the External Interface
You must assign an Elastic IP (EIP) address to the eth0 interface for the instance of Firebox Cloud. You can use any available EIP address. To make sure you assign it to the correct interface, find and copy the eth0interface ID of your instance of Firebox Cloud.
To find the eth0 interface ID for your instance of Firebox Cloud:
From the EC2 Management Console, select Instances.
Select the instance of Firebox Cloud. The instance details appear.
Click the eth0 network interface. More information about the network interface appears.
Copy the Interface ID value.
To associate the Elastic IP address with the eth0 interface:
From the EC2 Management Console, select Network & Security > Elastic IPs.
Select an available Elastic IP address.
Select Actions > Associate Elastic IP Address. The Associate Elastic IP Address page opens.
If you have created 2 sub-interfaces, You can associate two different publics IPs to the interface:
Run the Firebox Cloud Setup Wizard
After you deploy the Firebox Cloud instance, you can connect to Fireware Web UI through the public IP address to run the Firebox Cloud Setup Wizard. You use the wizard to set the administrative passphrases for Firebox Cloud.
Connect to Fireware Web UI for your Firebox Cloud with the public IP address: https://<eth0_public_IP>:8080
Log in with the default Administrator account user name and passphrase:
User name — admin
Passphrase — The Firebox Cloud Instance ID
The Firebox Cloud Setup Wizard welcome page opens.
Click Next. The setup wizard starts.
Review and accept the End-User License Agreement. Click Next.
Specify new passphrases for the built-in status and admin user accounts.
Click Next. The configuration is saved to Firebox Cloud and the wizard is complete.
This is the end of Part 2, in Part 3 we are going to configure the IPSEC route based VPN between the Firebox instance and both a native VPC and a VMC on AWSSDDC.
When I look back I realise I have been working at VMware for about 9 months and I have spent a tremendous amount of time dealing with a high number of requests, questions and issues with my customers.
One that particularly stands out is around integrating VMC on AWS with a Firewall hosted in a transit VPC for security purpose.
One of my customer recently was asking me if it was possible to create a VPN from VMC to a WatchguardTM Firebox Cloud Firewall. So I decided I would give it a try.
In this guide, I will first show you how to set up a route-based VPN from the WatchguardTM firewall to an AWS VGW in a native VPC.
In the last part, I will show how to configure an IPSEC route-based VPN from VMC on AWS to the same instance of WatchguardTM firewall hosted in a transit VPC.
Network Architecture diagram
AWS Deployment phase
Phase 1 -Configure an AWS transit VPC
Let me give first some definition: A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.
First, I need to configure an AWS VPC with at least two subnets. It’s possible to use the VPC Wizard to create a VPC with public and private subnets or create it manually.
If you choose the wizard, you will have to terminate the NAT instance that was automatically created for the VPC by the VPC Wizard because the instance of Firebox Cloud will provide NAT functions for subnets in this VPC.
I will be using the manual method:
Create a new VPC
When I create a VPC, I must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block. I decided to choose a CIDR block for my VPC of 172.30.0.0/16.
Now I will have to Create a public subnet with a CIDR block equivalent to a subset of the VPC CIDR range:
Choose a CIDR block for your public subnet like 172.30.11.0/24.
CREATE A PRIvate Subnet
Next step is to Create a private subnet from the VPC CIDR range in the same zone as the public subnet (CIDR block of private subnet cannot overlap with public subnet):
Choose a CIDR block for your private subnet like 172.30.20.0/24.
Create an Internet Gateway
We will now deploy an AWS Internet Gateway(IGW) from the VPC Dashboard. From the VPC Dashboard, Click Internet Gateways menu on the left:
Attach the new IGW to the transit VPC by clicking on the attach to VPC button and from the Actions drop-down menu, select the transit VPC and Click Attach.
The IGW is seen as attached to the VPC that was created:
Create a Route Table
Next, we will create a route table for the Transit VPC: from the VPC Dashboard, select Route Tables menu and Create Route table as shown:
The route table must be associated with the transit VPC as highlighted above. Once you provide a name for the route table and select the Transit VPC from drop-down menu, Click Create.
Next step is to create a default route for the new transit VPC route table. Select the Routes tab and Click Edit.
Add a 0.0.0.0/0 destination that point to the IGW previously created.
Next, from the same window, select the subnet associations tab and select the Edit Button and Select the public subnet created earlier. Once done, click Save.
Next you are going to Create a native “spoke” VPC (this is a VPC attach to the firebox through a VPN where we will run some EC2 instances to test access to the SDDC):
This is the end of this Part 1.
In Part 2 we are going to deploy the Watchguard VM in the transit VPC.