NAT

The NAT view presents the scaffolds that configure settings to modify the network address translation mechanisms of the rXg.

NAT

Entries in the NAT scaffold configure network address translation between LAN subnets and WAN addresses.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The addresses and static routes field specify the source LAN subnets for which network address translation will be enabled by this record.

The uplinks field specifies the destination WAN address(es) to which the selected LAN will be network address translated.

The Reverse NAT field specifies that traffic sent via selected Uplink is to be NATd to the first IP of the selected Addresses. This option is primarily used when the upstream ISP routes a block of public IPs to the rXg's primary uplink IP (often assigned via DHCP), and those IPs are assigned to a LAN interface for distribution to clients, but there is a need for outbound traffic from the rXg to always be sourced from the routed block of IPs rather than the DHCP uplink IP.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

If no records are present in the NAT scaffold, the rXg will automatically enable NAT from subnets that are configured with RFC 1918 specified private addresses.

Static IPs

An entry in the Static IPs scaffold creates a one-to-one mapping between an IP address within a span associated with an uplink and a private IP address on the LAN . This feature is typically used to give public access to a resource that is configured on a private IP address such as a web server.

The Source IP field determines the destination of the translation of traffic originating from the Public IP.

The Public IP field specifies the IP address within a span of addresses associated with an uplink that will be translated to the Source IP.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Dynamic BiNAT Pools

An entry in the Dynamic BiNAT Pools scaffold specifies a range of IP addresses that may be dynamically assigned to devices whose account has a Max BiNATs value of 1 or greater, and whose policy is enabled for this Dynamic BiNAT Pool. This feature is typically used to give public access to a resource that is configured on a private IP address such as a web server or a gaming device which requires open incoming firewall ports for proper operation.

The end-user may subscribe to a usage plan which allows Dynamic BiNAT, and may enable BiNAT functionality for specific device(s) by accessing the manage devices page of the portal. The operator may also change the active BiNAT device(s) by editing the account's device list. Care must be given to ensure that the range of addresses configured here is large enough to accomodate the number of devices that are configured for Dynamic BiNAT.

The Start IP field determines the first IP address of the range of uplink addresses that will be used as the Dynamic BiNAT IP for eligible devices. The IP should fall within a span of addresses associated with an uplink that is associated with the device's link control.

The End IP field specifies the last IP address in the range of uplink addresses that will be used as the Dynamic BiNAT IP for eligible devices. The IP should fall within a span of addresses associated with an uplink that is associated with the device's link control.

The Policies field specifies policies that may utilize this BiNAT Pool. When an associated Policy contains Accounts, a number of IP's specified in the Max BiNATs field of the Account will be assigned to that Account. The end user will be able to configure up to that many DMZ devices through the manage devices page in the captive portal. When an associated Policy contains devices that do not belong to an account, such as from an IP group or MAC group, a BiNAT will be assigned to each device currently connected that belongs to the associated Policy. If no policies are associated with this BiNAT pool, the pool is effectively disabled, and the addresses will be available for regular NAT.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Example BiNAT Deployments

Below are 3 BiNAT deployment examples.

Example 1: Dynamic BiNATs

In this example the operator has configured the rXg to have a block of public IP address that are used for CGNAT and another pool that users can dynamically be assigned a public IP address from that can used as NAT for the account. This IP can be assigned to a specific device (DMZ), and can also be used for UPNP.

First a block of public IP address must be assigned to an interface.

Next we need to configure a BiNAT pool by going to Network::NAT , in this case half the public IP addresses will be used for BiNAT's. The Operator can control which accounts/clients can be assigned a BiNAT by selecting the Policies that can use the pool. In this case only users in the Residents-Premium policy will be able to draw from the pool.

Being in the Residents-Premium policy is not all that is required the account must also be set to allow the use of BiNAT IP address. This is controlled by the Usage Plan the user has purchased. This can be set by going to Billing::Plans. Edit the appropriate Usage Plan and look at the Sessions section of the account. Here the Operator can set the number of Max dedicated IPs , in this example it is set to 1. UPnP has also been selected in this case.

Now users who purchase the Residents-Premium plan will have a BiNAT assigned to their account that all the traffic from their devices will NAT through and their devices can create UPnP port forwads automatically.

Example 2: Static Dedicated BiNATs

In this example the rXg has been configured so that each account gets assigned a BiNAT that is static. First a block of public IP addresses must be configured.

Next the BiNAT pool must be configured to consume the entire block of public IP address, and the appropriate policies must be allowed access to the BiNAT pool. Network::NAT.

The account must also be set to allow the use of BiNAT IP address. This is controlled by the Usage Plan the user has purchased. This can be set by going to Billing::Plans. Edit the appropriate Usage Plan and look at the Sessions section of the account. Here the Operator can set the number of Max dedicated IPs , in this example it is set to 1. By checking the Static dedicated IPs box the NAT IP or IPs are reserved and remain staic for the lifetime of the account. UPnP has also been selected in this case.

In this example each account is assigned a BiNAT address when created, and the IP assigned will remain for the lifetime of the account. This is the equivalent of having a static public IP address.

Example 3: BroadBand On Demand

In this example the rXg has been configured so that each account selects the number of Dedicated IP's (BiNAT addresses) that will be assigned to the account at time of purchase. A block of Public IP address must be configured via Network::WAN.

Next the BiNAT pool must be configured to determine which IP address can be used for dedicated IPs, and the appropriate policies must be allowed access to the BiNAT pool. Network::NAT.

The Usage Plans for this example must be configured to allow the user to pick the number of Dedicated IPs by using the Plan Addons scaffold via Billing::Plans. Here two Plan Addons have been created allowing the user to purchase additional Dedicated Ips and allows them to make them static by purchasing the static IP option.

The above configuration allows the user when purchasing a plan to select how many dedicated IP's they want and can purchase the ability to make them static as well.

NAT Reversal example

Video Configuration Guide and Demonstration

In this example a NAT rule will be created for NAT Reversal, it will be assumed here that the ISP is handing out a private IP address and routing a static block of public IP addresses to the private IP address. Traffic that originates from the WAN IP address of the rXg will be NAT'ted to the first IP address of the public static block on the LAN. What this means is that if a client device were to go to whatismyipaddress it would report the first IP address of the static block on the LAN and not the WAN IP address. Inbound traffic from the Internet destined to the first IP address of the public static block on the LAN is now redirected to the WAN IP address of the rXg. This means that if the operator were to put in their browser the first Public IP address from the static LAN block, they would be getting to the WAN of the system.

To configure this there needs to be a WAN uplink that would usually be a static IP address however it could be DHCP that assigns a static IP, and there needs to be a block of static Public IP addresses routed to the uplink IP. Below is an example Uplink configuration that receives a WAN IP via DHCP.

To configure this with an assigned static WAN IP address, create a new Uplink or edit an existing one. Select the interface. Make sure the DHCP box is unchecked, and enter the gateway IP address. Create or update the uplink.

Next create a new Network Address and assign the IP address to the uplink. Give the Network Address a name, and select the interface, the interface should match the interface of the Uplink. Enter the address to be assigned to the uplink and click create.

Next the Static Block of Public IP address will be created. Create a new Network Address. Give the record a name, select the interface that matches the uplink in this case it is vmx1. Enter the IP address in cidr notation. Only a single IP address is needed here however we can assign more to the system by adjusting the span if needed. Setting the span to 2 in this example would assign the .2 and .3 address to the system. Click Create.

Next navigate to Network::NAT and create a new NATs rule.

Give the record a name, select the Uplink and check the Reverse NAT box. Next select the Network Address created in the previous step and click Create.

With this configuration in place, a device on the LAN that goes to whatismyipaddress.com would report that it's IP address was 192.170.0.1. A device going to https://192.170.0.1/admin would get the Admin GUI of the system, even though the uplinks IP is a private address.