Prepare to Set Up VM-Series Firewalls on Google Public Cloud

Prepare to set up a VM-Series firewall on Google Cloud Platform, configure your Google accounts access (including the SSH key pair), plan VPC networks, and network interfaces for the firewall.
The process to Deploy the VM-Series Firewall from Google Cloud Platform Marketplace requires preparation tasks. Before the deployment, you must create your project networks and subnetworks, and plan networks and IP address assignments for the VM-Series firewall interfaces. During the deployment, you must choose from existing networks and subnetworks.
Refer to the following topics when planning your deployment:

Google Cloud Platform (GCP) Account Planning

Review these requirements to ensure that you have proper accounts and permissions before you deploy the firewall on a Google Compute Engine (GCE) instance.

Accounts and Permissions

  • You must have a GCP user account with a linked email address and you must know the username and password for that email address.
  • You, and any users you allow, must have the following minimal roles or equivalent Identity and Access Management (IAM) permissions to connect to the VM-Series firewall:
    • Compute Viewer—Enables you to get and list compute engine resources without being able to read the data stored on those resources.
    • Storage Object Viewer—Enables you to bootstrap using a Google storage bucket in the same project.
    • Monitoring Metric Writer—Required for Stackdriver.
    Users in your organization might have IAM permissions or predefined roles that are more permissive than required. Ensure that you appropriately restrict VM-Series firewall access.

Available Resources

Your project must have sufficient resources to deploy the VM-Series firewall as a Google Compute Engine instance. If you are deploying a GCP Marketplace solution, determine whether the solution deploys other VMs in addition to the firewall. In the Google Cloud Console, select IAM & adminQuotas to review the resource quotas for your project and the networks and disk space consumed. If you are running out of resources you can ask Google to allocate more for your organization.
gce-quotas.png

Authentication Methods

GCP supports multiple ways to connect to an instance. You can authenticate with a service account or an SSH key pair.
  • Service Accounts—Service Accounts belong to applications or VMs—not to end users. They are commonly used to control access when you use programs or scripts, or when you access the firewall from the gcloud command line. If you are using Google Service Accounts to authenticate instances or applications, you must know the email address for the account(s). Refer to Creating and Managing Service Account Keys.
    Using a service account is necessary if you want to connect to the VM-Series firewall from outside the project. For example, if you want to enable a physical next generation firewall to monitor your VM-Series firewall, you must save the VM-Series firewall service account information to a JSON file. In the physical firewall, you upload the file when you configure the connection.
  • SSH Keys—If you deploy the VM-Series firewall from the Marketplace, you must supply one Open SSH key in RSA format for the Google Compute Engine instance metadata.
    The VM-Series firewall only accepts one key at deployment.
    At deployment time, you paste the public key into the Marketplace deployment. After deployment you use the private key to SSH in to the firewall to configure the administrator account. To add users, see Manage Firewall Administrators.

SSH Key Pair

The VM-Series firewall manages authentication differently than GCE instances. You first log in with the default user admin.
The default user name is only accepted once. After a successful login you set an administrator username and password for the VM-Series web interface; see Deploy the VM-Series Firewall from Google Cloud Platform Marketplace.
You cannot log in to the VM-Series firewall if you do not supply the entire public key, or your key has illegal characters when you paste the key into the Marketplace SSH key field. When you SSH in to the VM-Series firewall for the first time, the public key is transferred to the firewall. If the public key is corrupted, the authentication fails and you must delete the deployment and start over. When you delete a deployment, any networks and subnetworks remain, but the firewall rules must be recreated.
The SSH key field in the Marketplace deployment displays the following placeholder:
admin:ssh-rsa your-SSH-key
admin is the VM-Series firewall Administrator user name required to log in to the firewall for the first time. You add the admin: prefix into the Marketplace field when you deploy the VM-Series firewall.
Create the key according to your key generator documentation. Do not edit the public key file. Editing risks introducing illegal characters.
  1. Create an SSH key pair and store the SSH Key pair in the default location for your operating system mentioned in Locating an SSH key.
    • On Linux or MacOS, use ssh-keygen to create the key pair in your .ssh directory.
    • On Windows, use PuTTYgen to create the key pair.
      The content of the Key comment field does not matter to the VM-Series firewall; you can accept the default (the key creation date) or enter a comment that helps you remember the name of the key pair. Use the Save private key button to store the private key in your .ssh directory.
  2. Select the full public key.
    • Linux or MacOS:
      Open your public key in a text editor and copy the public key.
    • Windows: You must use the PuTTY Key Generator to view the public key. Launch PuTTYgen, click Load, and browse to private key you saved in your .ssh directory.
      In PuTTYgen, scroll down to ensure you select the entire key, right click, and choose Copy.
      ssh-copy.png
  3. Paste the public key.
    1. In the Marketplace SSH key field, delete the placeholder text, and type:
      admin:
      Make sure there are no extra spaces following the colon.
    2. Insert the cursor after admin: and choose Paste as plain text. The key must be on a single line.
      ssh-after-click.png
  4. After the deployment, and before you attempt to log in to the firewall, view the management instance and check the key:
    ssh-after-deploy.png
    If the key does not look right (it has line feeds, for example) you must replace it.
    1. Click the X to delete the key, then click + Add item. Type in admin: and paste in the key again.
    2. Click Save to deploy the updated deployment.

Virtual Private Cloud (VPC) Network Planning

Make a plan for VPC networks (referred to as networks), subnetworks (also called subnets), and Google firewall rules. You must create networks and subnetworks before you start Deploy the VM-Series Firewall from Google Cloud Platform Marketplace.
The Marketplace deployment page displays only networks and subnetworks that exist when you start the deployment. If a network is missing, you must exit the deployment, create the network, and start over.
See VM-Series Firewall Licenses for Public Clouds to determine the number of network interfaces needed based on your VM-Series firewall license. At a minimum, set up the three VPC networks and subnets required to launch the VM-Series firewall.
  • VPC Networks—You must create a custom network specifically for each VM-Series network interface.
    • A GCP project has a default network with preset configurations and firewall rules; you can delete the default network, if unused.
    • By default, there are up to five networks in a project. Your GCP administrator can request additional networks for your project.
    • To connect to the management interface you must create a GCP firewall rules that allows access. You can do this during the deployment if you choose Enable GCP Firewall rule for connections to Management interface then supply a CIDR block for Source IP in GCP Firewall rule for connections to Management Interface.
    Be sure your networks include all instances you want to secure.
  • Subnetworks—A compute engine instance can support up to eight Layer 3 interfaces on a single instance. The Management, Trust, and Untrust interfaces consume three interfaces and you can create up to five additional dataplane interfaces. Typically the dataplane interfaces represent application networks.
  • IP Addresses—You supply IP address ranges when you create interface subnetworks, and you have the option to enable an external address when you deploy a subnetwork.
    • When you create a network subnet, you must specify an IP address range. This range is used for your internal network, so it cannot overlap with other subnets.
    • During deployment, you can choose to enable an external IP address when you create a network interface. By default, you are given an ephemeral IP address. You cannot supply a reserved static IP address during the deployment, but you can promote the ephemeral address to a static IP address after you complete the deployment process (see Promoting an ephemeral external IP address).

Network Interface Planning

When you deploy from Google Cloud Platform Marketplace, the default VM-Series firewall deployment has three interfaces: the Management plane interface and the Untrust and Trust dataplane interfaces. You can define additional dataplane instances, depending on the available compute resources on your VM; see VM-Series Firewall Licenses for Public Clouds.
During the deployment you have the opportunity to name these interfaces.

Interface Order

When you deploy with Marketplace, the order of the network interfaces is predefined. The Management interface maps to eth0, Untrust to eth1, and Trust to eth2. Marketplace uses this order because mapping the Management interface to eth0 and the Untrusted interface to eth1 is a requirement if you need to Swap the Management Interface for load balancing.

Management Interface

The first network interface you add is mapped to eth0 on the firewall and includes the option to enable IP forwarding. You use this network interface to manage the VM-Series firewall. Typically, this interface has an external IP address.
An external IP address is only required if a dataplane interface is attached to the public subnet. At creation time, you can receive an ephemeral IP address and later promote it to a static IP address after you complete the deployment (refer to Promoting an ephemeral external IP address).

Dataplane Interfaces (Untrust, Trust)

When you deploy from Marketplace, the order in which you add interfaces is predetermined.
  • You configure the Untrust interface after the Management interface. This order means that the untrusted interface is mapped to eth1. The Untrust interfaces are typically attached to the public subnet, and have an external IP address.
    An external IP address is only required if a dataplane interface is attached to the public subnet. At creation time, you can receive an ephemeral IP address, then promote it to a static IP address, as discussed in Promoting an ephemeral external IP address.
  • The Trust interface follows the Untrust interface, and it is mapped to eth2. The Trust network often does not have an external IP address. You can add any additional dataplane interfaces after the Trust interface.

Additional Dataplane Interfaces

Plan interfaces for applications you must secure, such as web servers, databases, and other applications in your network. You can create up to five additional dataplane interfaces in addition to the three required to launch your firewall. Ensure that the applications you want to secure are in networks that connect to the VM-Series firewall.

Related Documentation