You're viewing documentation for the legacy version of Firezone, now End-of-Life. View the latest docs here.
Static Egress IP with a NAT Gateway
Firezone can be used as NAT gateway in order to provide a single, static egress IP for all of your team's traffic to flow out of. This is commonly used in the following scenarios:
- Consulting engagements: Ask your client to whitelist a single static IP address associated with your engagement instead of your employees' individual device IPs.
- Masking your device IP or proxying your source IP for privacy or security reasons.
This guide will walk through a simple example restricting access for a self-hosted web app to a single whitelisted static IP running Firezone.
This is commonly done in place of maintaining an IP whitelist for multiple team members, which becomes impossible to manage as the access list grows and team members' IP addresses change.
AWS example
Our goal is to configure VPN traffic to the restricted resource to be routed through a Firezone server on an EC2 instance. In this case Firezone is acting as a network proxy or NAT gateway to provide a single public egress IP for all the devices connected to it.
In this example the protected resource and Firezone are in separate VPC regions.
Step 1: Deploy Firezone server
In this example, a Firezone instance has been set up on a tc2.micro
EC2
instance. See the Deployment Guide for details on deploying
Firezone. Specific to AWS, ensure:
- The security group of the Firezone EC2 instance allows outbound traffic to the IP of the protected resource.
- An Elastic IP is associated with the Firezone instance. This will be the
source IP address of traffic routed through the Firezone instance to external
destinations. In this case, the IP is
52.202.88.54
.
Step 2: Restrict access to the protected resource
In this example, the protected resource is a self-hosted web app. Access to the
web app is restricted to only requests from 52.202.88.54
. Depending on the
resource, inbound traffic on different ports and traffic types may need to be
allowed. This is outside the scope of this guide.
If the protected resource is controlled by a 3rd party, please inform the 3rd
party to allow traffic from the static IP set in Step 1 (in this case
52.202.88.54
).
Step 3: Route traffic to the protected resource through the VPN server
By default, all traffic from team members will be routed through Firezone and
will originate from the static IP set in Step 1 (in this case 52.202.88.54
).
However, if split tunneling has been
enabled, configuration may be required to ensure the destination IP of the
protected resource is included in the Allowed IPs
.