Using Firezone as 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. In this example the protected resource and Firezone are in separate VPC regions.
This arrangement is commonly done in place of maintaining an IP whitelist for multiple end users, which may become labor intensive to manage as the access list grows.
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, 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
In this example, the protected resource is a self-hosted web app. Access to the web app is restricted to only requests from
184.108.40.206. 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
By default all traffic from users will be routed through the VPN server, and will originate from the static IP set in Step 1 (in this case
220.127.116.11). However, if split tunneling has been enabled, configuration may be required to ensure the destination IP of the protected resource is included in the