GCP Quick Start

You can be up and running HTTPS/TLS egress filtering for your Google Cloud Platform VPC Network in no-time! Just follow these steps:


  1. Think about the egress filtering that you need to apply. Put together the fully qualified domain names (FQDNs) if possible for all target destinations. Note that subdomains are not implicitly included, e.g. example.com will not include www.example.com . The asterisk (*) wildcard is supported so you could use that in places where the subdomains targeted under a particular domain are not known, e.g. *.example.net .
  2. All the target destination hostnames then need to be put together in a comma separated format, e.g. example.com,www.example.com,*.example.net
  3. If you are planning to deploy a new VPC Network secured by egress filtering, think about the IP Address ranges you would like to deploy. A good place to start is the Virtual Private Cloud (VPC) network overview page over at GCP documentation. You can even deploy in the default VPC network and the default Subnetwork.


  1. Proceed to our Google Cloud Platform Marketplace page and click the Launch on Compute Engine button.

    GCP Marketplace Page
  2. At the Deployment Configuration page, the defaults should suffice for a non-Production environment. The parameters are explained below for help with multiple deployments and considerations for Production environments.

    Deployment Configuration
    1. Deployment name: This is a unique identifier for the deployment and will form the prefix to Metadata configuration keys, as we will see later. In the case of this example, we have chosen the name xyz-nat-firewall .
    2. Number of Instances: This many number of instances will spread evenly over all Zones in the selected Region. A number of 1 should suffice for non-critical environments such as those for Test & Development purposes. For Production, a number of at least 2 will provide rapid High Availability. A number equal to the number of Zones in the selected Region will provide a nice, even spread of the instances in all Zones and sufficient headroom for Production throughput in case of an incident.
    3. Machine Type: We recommend that you start with something low and small. You will need more CPUs to handle concurrent clients, and larger types of instances for more bandwidth. It is worth mentioning this firewall is not a memory intensive application. You can read more about Machine Types on GCP here.
    4. Zone: The Zone is only used to infer the Region for this deployment.
    5. Network: This is the VPC Network for this deployment. The VM Instances that you wish to protect (filter the egress traffic of) would have to be a part of this VPC Network.
    6. Subnetwork: This is the Subetwork for this deployment. The VM Instances that you wish to protect (filter the egress traffic of) would have to be a part of this Subnetwork.
    7. Just hit Deploy and the firewall instance(s) will be ready in a few minutes!

      Deployment In Progress
  3. After a successful deployment, the Deployment for the chosen name will reveal some useful information that will come in handy at the time of configuring this firewall.

    Deployment Information
    1. Whitelist Metadata Key: In the given example it is set to xyz-nat-firewall-whitelist . It is always constructed as <deployment name>-whitelist . Therefore, a different deployment would point to its own, unique whitelist Metadata key.
    2. Permissive Metadata Key: In the given example it is set to xyz-nat-firewall-permissive . It is always constructed as <deployment name>-permissive . Therefore, a different deployment would point to its own, unique permissive Metadata key.
    3. Log Filter for Configuration Changes: This string is useful to directly filter for logs that reveal any changes to the firewall configuration. It is always constructed as logName="projects/<gcp project name>/logs/discriminat-config" .
    4. Log Filter for Data Flow: This string is useful to directly filter for logs that reveal traffic metadata for all accepted and rejected connections through the firewall. It is always constructed as logName="projects/<gcp project name>/logs/discriminat-flow" .
  4. Let's now configure the firewall rules. Browse to Compute Engine -> Metadata and create the keys noted from the previous step.
    1. <deployment name>-whitelist : In our example, this resolves to xyz-nat-firewall-whitelist . We set the value to registry.npmjs.org,*.maven.org,auth.docker.io,registry-1.docker.io,index.docker.io for the time being.
    2. <deployment name>-permissive : In our example, this resolves to xyz-nat-firewall-permissive . We set the value to no . Caution: Setting this value to yes effectively disables the enforcement action of the firewall, turning it to a logging only bump-in-the-wire.

    Firewall Configuration
    • These Metadata keys can also be set using GCP REST API's SetCommonInstanceMetadata method.
    • The keys can be set at any time, even before launching the deployment, and afterwards at any time. Any changes made take about a minute to propagate through the firewall instances. Any changes to firewall configuration will be logged, as we will see in the next step.
  5. Let's now look at the configuration logs. Browse to Logging -> Logs Viewer and paste the Log Filter for Configuration Changes from the Deployments page, which in the case of our example is logName="projects/<gcp project name>/logs/discriminat-config" and hit Run Query. You will see each instance of the firewall picking up the changes with a little note on each hostname's validity.

    Structured Configuration Logs

    Logs are structured (JSON) so filtering them in any way you like should be a walk in the park!

The deployment is now complete. Any Instances now spun up in the chosen Subnetwork would have egress filtering applied to their access to the Internet. See the GCP Quick Start Testing page for a taster.

Health Checks

The discrimiNAT firewall exposes an HTTP Health Check at TCP port 911. A status code of 200 implies all critical services to the functioning of the firewall to be operational. The Managed Instance Group is configured to test this for health. To see for yourself, browse to Network Services -> Load Balancing and look for the white check-mark in a green circle against a Load Balancer by the name of <deployment name>-backend .

Health Check

Note: You may have to press the Refresh button anyway.


SSHing into a firewall VM Instance is quite straightforward. Just browse to Compute Engine -> VM Instances to grab the Internal IP or External IP Address of the VM Instance you are interested in. These VM Instances will be marked as In Use By <deployment name>-mig .

IP Address for SSH

You will most likely need to allow yourself through the firewall rules. A rule by the name of <deployment name>-deny-rest with a relatively low priority could prevent your connection. In that case, create a new rule with a priority lower than this rule's priority to allow your connections to TCP port 22.

Firewall Rules for SSH

Open Source

Once in a VM Instance via SSH, you can discover the Open Source Licenses, Notices and Code by issuing the following commands:

$ find /opt -iname "*licen*" | grep -v google-fluentd
$ find /opt -iname "*copy*"  | grep -v google-fluentd
$ find /opt -ipath "*src*"   | grep -v google-fluentd