NAT Examples

The examples in this section describe and demonstrate use cases and packet flows for typical scenarios involving NAT.

AWS NAT Examples

When using TNSR with AWS, it is relatively easy to unintentionally create an asymmetric routing situation. AWS knows about your local networks and will happily egress traffic with NAT for them, when other networking setups would otherwise drop or fail to hand off the traffic.

The examples in this section covers what would happen with a TNSR setup in AWS with two instances: An internal LAN instance with a local “client” system making an outbound request, and an external WAN instance that is intended to handle public-facing traffic. TNSR sits between the WAN and LAN instance to route traffic. In AWS, the VPC routing table is configured such that the LAN instance uses TNSR for its default gateway. The expected flow is that traffic flows from clients, through TNSR, to the Internet and back the same path.

This table lists the networks and addresses used by these examples.

Item

Value

AWS Networks

192.0.2.0/24 (LAN), 198.18.5.0/24 (WAN), 203.0.113.0/24 (External)

AWS Gateways

192.0.2.1 (LAN), 198.18.5.1 (WAN), 203.0.113.1 (External)

TNSR LAN

192.0.2.2/24

TNSR WAN

198.18.5.2

TNSR GW

198.18.5.1 (AWS Gateway)

LAN Client

192.0.2.5/24

LAN Client GW

192.0.2.2 (TNSR LAN)

Server

198.51.100.19/24

Server GW

198.51.100.1

AWS Example without NAT

In this example, TNSR is not configured to perform NAT. This example steps through each portion of a packet and its reply, and then discusses the problems at the end.

../_images/diagram-nat-example-aws-nonat.png

AWS example packet flow without NAT

First, the client initiates a connection using a packet which arrives on the TNSR LAN interface

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

192.0.2.2

TNSR performs a FIB lookup. The destination IP address is not within the the subnets configured on the TNSR instance interfaces, so it matches the default route

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

Default

TNSR forwards the packet out its WAN interface to its default gateway on the WAN. TNSR is not configured for NAT, thus it does not perform any translation.

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

198.18.5.1

The packet reaches the AWS internet gateway connected to the VPC. Its source IP address is still the private IP address of the LAN instance.

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

198.18.5.1

The AWS internet gateway performs NAT. It recognizes the source IP address as belonging to the LAN instance and rewrites it to the public IP address of the LAN instance.

Proto

Source

Destination

Via

TCP

203.0.113.50:40250

198.51.100.19:443

Default

The AWS internet gateway forwards the packet to the internet.

Proto

Source

Destination

Via

TCP

203.0.113.50:40250

198.51.100.19:443

203.0.113.1

The destination host sends a reply to the public IP address of the LAN instance. It arrives at the AWS internet gateway.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

203.0.113.50:40250

198.51.100.1

The AWS internet gateway performs NAT. It recognizes the destination IP address as belonging to LAN instance and rewrites it to the private IP address of the LAN instance.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

192.0.2.5:1025

Direct L2 LAN

The AWS internet gateway knows how to reach the private IP address of the LAN instance directly, so it forwards the reply packet directly to the LAN instance, skipping the TNSR instance.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

192.0.2.5:1025

Direct L2 LAN

The packet arrives at the client.

The return path skipped TNSR, so TNSR is only seeing half the packets for the connection. At best this means the asymmetric routing will bypass any filtering or inspection of the replies (IDS/IPS), and at worst it could mean subsequent packets would be dropped instead of passing through TNSR.

AWS Example with NAT

In this example, TNSR has NAT configured such that its LAN is defined as an inside interface and its WAN is an outside interface. See Outbound NAT for details. Packets leaving the WAN will be translated such that they leave with a source address set to the TNSR WAN interface IP address.

../_images/diagram-nat-example-aws-nat.png

AWS example packet flow with NAT

First, the client initiates a connection using a packet which arrives on the TNSR LAN interface

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

192.0.2.2

TNSR performs a FIB lookup. The destination IP address is not within the the subnets configured on the TNSR instance interfaces, so it matches the default route

Proto

Source

Destination

Via

TCP

192.0.2.5:1025

198.51.100.19:443

Default

TNSR applies NAT and forwards the packet out its WAN interface to its default gateway on the WAN subnet.

Proto

Source

Destination

Via

TCP

198.18.5.2:34567

198.51.100.19:443

198.18.5.1

The packet reaches the AWS internet gateway connected to the VPC. Its source IP address is the private IP address of the TNSR WAN instance.

Proto

Source

Destination

Via

TCP

198.18.5.2:34567

198.51.100.19:443

198.18.5.1

The AWS internet gateway performs NAT. It recognizes the source IP address as belonging to the WAN instance and rewrites it to the public IP address of the WAN instance.

Proto

Source

Destination

Via

TCP

203.0.113.50:40250

198.51.100.19:443

Default

The AWS internet gateway forwards the packet to the internet.

Proto

Source

Destination

Via

TCP

203.0.113.50:40250

198.51.100.19:443

203.0.113.1

The destination host sends a reply to the public IP address of the WAN instance. It arrives at the AWS internet gateway.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

203.0.113.50:40250

198.51.100.1

The AWS internet gateway performs NAT. It recognizes the destination IP address as belonging to WAN instance and rewrites it to the private IP address of the WAN instance. The AWS internet gateway knows how to reach the private IP address of the WAN instance directly, so it forwards the reply packet directly to the WAN instance.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

198.18.5.2:34567

Direct L2 WAN

The packet arrives at the TNSR WAN, which performs NAT. It recognizes the source and destination as matching an existing NAT state belonging to the LAN client and rewrites the destination address to the LAN client. TNSR knows how to reach the client LAN IP address directly, so it forwards the reply packet.

Proto

Source

Destination

Via

TCP

198.51.100.19:443

192.0.2.5:1025

Direct L2 LAN

The packet arrives back at the client.

In this case, the NAT performed on TNSR ensured that the AWS gateway delivered the reply back to TNSR instead of handing it off directly. This allowed the packet and its reply to use the same path outbound and inbound.