AWS Network Firewall no-source-preservation mode

Deployment mode – Network Firewall offers two deployment modes: source-preservation and no-source-preservation. In source-preservation deployment, the firewall receives traffic from the VPC endpoint, filters it, and sends it back to the same VPC endpoint. In no-source-preservation deployment, Network Firewall receives traffic from the VPC endpoint, filters it, and then sends the filtered traffic directly to the destination using its own IP address. You can use the no-source-preservation firewall as an explicit proxy. You choose the deployment mode when you create the firewall and cannot change it afterward.

Source-preservation mode – A deployment mode in which Network Firewall preserves the original source IP address of the traffic it inspects. This is the default mode. Traffic is routed through firewall endpoints using VPC route tables.

No-source-preservation mode – A deployment mode in which Network Firewall terminates client connections and re-establishes them to the destination using the IP address of an attached NAT gateway. In this mode, the firewall supports both transparent firewall and explicit proxy functionality. Applications connect to the firewall through VPC endpoint associations.

Explicit proxy – A mode of operation in which Network Firewall receives HTTP CONNECT requests from clients and establishes connections to destinations on behalf of the client. Clients explicitly configure their environment to send traffic to the proxy, rather than the firewall being transparently inserted in the network path. Available only in no-source-preservation mode.

Firewall FQDN – A fully qualified domain name assigned to a no-source-preservation mode firewall. Clients use this hostname to direct proxy traffic to the firewall. The hostname resolves to the IP address of the local VPC endpoint through automatically created private hosted zones.

Fully qualified domain name (FQDN) – No-source-preservation mode firewalls are assigned a fully qualified domain name that clients use to connect.

Traffic routing – No route table changes needed; clients use proxy environment variables.

No stateless rules – The stateless rules engine does not inspect explicit proxy traffic. Proxy traffic (HTTP CONNECT requests) is processed directly by the stateful rules engine.

Create a firewall policy – Define the firewall policy by specifying its rule groups. You can create custom rule groups, use AWS managed rule groups, or use partner managed rule groups. For information, see Firewall policies.

Create a NAT gateway (if one does not exist) – The firewall attaches to a NAT gateway and uses its IP address to communicate with destinations. If you do not already have a NAT gateway in the VPC and Availability Zone where you want to deploy the firewall, create one. For information about Amazon VPC NAT gateways, see NAT gateways in the Amazon Virtual Private Cloud User Guide.

Create the firewall in no-source-preservation mode – Create a Network Firewall firewall selecting No source preservation as the deployment mode. Attach a NAT gateway (the firewall uses this NAT gateway's IP for egress), and specify a VPC and subnet to deploy the firewall endpoint. Your applications send traffic to the Network Firewall for inspection using this endpoint. You can only create the endpoint in the Availability Zone that your attached NAT gateway resides in. The endpoint subnet must be a different subnet from the NAT gateway subnet. Next, you associate the firewall policy you created in the previous step and optionally configure advanced settings – delete protection, traffic analysis mode, proxy listener ports (defaults to HTTP/3128 and HTTPS/8443), and logging.

Verify the firewall is ready – After creation, the firewall details page displays the deployment mode, the attached NAT gateway ID, and the status. Once the status transitions from PROVISIONING to READY, the proxy FQDN (DnsName) appears in the Endpoints and identity section. This is the hostname your applications use to access the proxy.

Configure your workloads to use the proxy – Point your application's proxy environment variables (for example, http_proxy, https_proxy) to the firewall's DnsName on the configured listener port. An explicit proxy setting does not require any route changes. The applications send traffic to the proxy hostname, which automatically resolves to the firewall endpoint.