Quick Start

Deploy discrimiNAT firewall on GCP in 5 minutes

Table of Contents

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.

Whether something wholly new or the default network, just follow the visual guide below.


i. MARKETPLACE LAUNCH

Proceed to our Google Cloud Platform Marketplace page and click the Launch button.


ii. DEPLOYMENT PARAMETERS

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 name: This is a unique identifier for the deployment. In the case of this example, we have chosen the name plugleak.

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 baseline Production throughput in case of an incident.

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.

Zone: The Zone is only used to infer the Region for this deployment.

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.

Subnetwork: This is the Subnetwork 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.

Just hit Deploy and the firewall instance(s) will be ready in a few minutes!


iii. SMALL WAIT

Shouldn’t be more than a few minutes.


iv. KEY INFORMATION

You’re all set! Let’s review some key information that is now visible:

Manage Firewall Rules: Brief example of what could be specified in the firewall rules now this firewall is deployed. More on that in the next section.

Tag for bypassing firewall: This tag, bypass-discriminat, is what can be added to the network tags of any virtual machines if you would like them to simply side-step this firewall.

Watch the Configuration Logs: This string is useful to directly filter for logs, in StackDriver, that reveal any changes to the firewall configuration. It is always constructed as logName="projects/<gcp project name>/logs/discriminat-config" .

Watch the Flow Logs: 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" .


v. FIREWALL RULES

We encourage you to create firewall rules as you would normally. Tight in scope and tagged in a granular fashion dependent on application requirements. Following are the points to take additional care around for effective use of the discrimiNAT firewall:

  • Add destination protocols and FQDNs to the description field. The format of this text is discrimiNAT:<protocol>:<fqdn>[,<fqdn>] .

    • Valid protocols are ssh and tls only.
    • There can be as many FQDNs as you can fit separated by commas. There cannot be whitespace, though.
    • There can be other text leading and trailing this specification, separated by whitespace or newlines.
    • All of it is case insensitive.
  • Some examples of what can go in the description field:

    • discrimiNAT:TLS:api.foo.example.com,downloads.example.net
    • discrimiNAT:SSH:sftp.txs.example.org,ssh.github.com
    • discriminat:tls:api-v2.example.com discriminat:tls:www.example.org
    • lorem ipsum discriminat:ssh:ssh.github.com,gitlab.com dolor sit amet
    • lorem ipsum
      discriminat:ssh:ssh.github.com
      discriminat:ssh:gitlab.com
      dolor sit amet
  • Direction of traffic must be Egress.

  • Targets must be set to Specified target tags. And then specify the same network tags as on the virtual machines that you’d like this firewall rule to be applied to. Precisely like you would anyway.

  • Destination filter must be set to IP range and the range set to the narrowest you can think of. Now if you don’t have anything narrower than 0.0.0.0/0 that is absolutely fine! The firewall takes care of validating the destination IP address of actual packets in many ways, but the firewall rule at the GCP networking and security level must allow the packet to leave the virtual machine at all. We repeat, 0.0.0.0/0 is a safe choice with the discrimiNAT firewall in the way.

  • Under Protocols and ports, only choose tcp and specify exactly one port number. Ranges, multiple ports, other protocols, and so on are not supported.

  • That’s it!


vi. CONFIGURATION LOG

Let’s now look at the configuration logs. Browse to Logging -> Logs Explorer and paste the log filter for watching the configuration logs from the deployments page, which is constructed as logName="projects/<gcp project name>/logs/discriminat-config" and hit Run Query. You will see each instance of the firewall pick up the changes! Logs are structured (JSON) so filtering them in any way you like should be a walk in the park!


vii. TEST A VIRTUAL MACHINE

Time to test with a virtual machine. Create one as usual, in the same region as the firewall was deployed in. Customise the Management, security, disks, networking, sole tenancy section though.


viii. PRIVATE IP AND TAGS

Under the Networking tab, ensure that:

  • Network tags match any or some firewall rules with the same target tags, as usual.
  • Network and Subnetwork are set to where the firewall was deployed.
  • External IP is set to None. These virtual machines do not need a Public IP address at all and will be NAT’ed if firewall rules permit through the discrimiNAT firewall.

The logs of flow activity from this virtual machine can be viewed in the Log Explorer with a filter that is constructed as logName="projects/<gcp project name>/logs/discriminat-flow".