Source NAT for Application Identification

Overview

The source IP address used by Avi SEs for server back-end connections can be overridden through an explicit user-specified address — the source NAT (SNAT) IP address. The SNAT IP address can be specific as part of the virtual service configuration.

Note: This feature is not supported for IPv6.

Uses for SE SNAT

In some deployments, it is required to identify traffic based on source IP address, to provide differential treatment based on the application. For instance, in DMZ deployments there may be firewall, security, visibility, and other type of solutions that may need to validate clients prior passing their traffic on to an application. Such deployments use the source IP to validate the client. A single SE can host multiple VIPs, so a firewall sitting between the SE and back-end servers would normally see all traffic coming from same SE interface IPs, no matter what VS the traffic belongs to. In contrast, with per-VS SNAT, the firewall will see a source IP it can use to filter traffic based on what application it is coming from (since the firewall knows the VS-SNAT-IP mapping established by the admin).

In the following example, SNAT is used to identify the application type for a VIP’s traffic. Traffic destined to email servers must pass through a SPAM filter and anti-virus checks, while traffic destined for DocShare servers needs to undergo anti-virus and malware filter checks.

snat-iptopo1

(The topology representation is logical rather than physical. For instance, email and DocShare servers could both be running on the same host and be in the same pool. Likewise, the set of email or DocShare servers does not need to be physically connected to the rest of the network through a single segment, and so on.)

One SNAT Address per SE Required

If SNAT is used for a virtual service, the virtual service’s configuration must include a unique SNAT address for each SE that may be used by the virtual service. For instance, if the SE group for the virtual service’s pool can be scaled out to a maximum of 4 SEs, the SNAT list within the virtual service configuration must contain 4 unique SNAT addresses.

Note: Whereas some other load balancing products require an entire pool of SNAT IP addresses per virtual service, even for a single load-balancing appliance, Avi Vantage does not require a whole pool per virtual service. Avi Vantage does not have the limitation of 64k port numbers for a single device. Avi Vantage is designed to allow a single source IP to have more than 64k connections across an application’s back-end servers. Up to 48k open connections can be established to each back-end server.

Configuring SE SNAT

To enable source NAT for a virtual service:

  1. Navigate to Applications > Virtual Services.
    • If you are creating a new virtual service, click on Create > Advanced Setup.
    • If you are adding SNAT to an existing virtual service, click on edit icon in the row where the virtual service is listed.
  2. On the Advanced tab, specify the SNAT IP in the SNAT IP Address field. If the SE group allows scaling out to more than one SE, add a unique SNAT IP for each SE. Use a comma between each IP as a delimiter.
  3. Click on Save.

The following configuration changes are disruptive, i.e., the virtual service will get removed from the existing Service Engines and get added back again.

  • Add snat_ip pool to virtualservice config

  • Remove snat_ip pool from virtualservice

  • Update snat_ip pool to remove a IP which was already being allocated

High Availability Support for Source NAT

Source NAT can be used with either of the high availability (HA) modes, such as, elastic HA or legacy HA. The configuration requirements differ depending on whether the SE and back-end servers are in the same subnet (connected at Layer 2) or in different subnets (connected at Layer 3).

SE-server Connection HA Type Requirements
Layer 2 Elastic HA
(Active/Active)		 SNAT IPs: 1 per SE
Floating IP: Not Required
Legacy HA
(Active/Standby)		 SNAT IPs: 1 per virtual service
Floating IP: Not Required
Layer 3 Dynamic HA using BGP
(Active/Active)		 SNAT IPs: 1 per SE in SE group (to support scale out)
Floating IP: Not Required
Legacy HA
(Active/Standby)		 SNAT IPs: 1 per virtual service
Floating IP: Required

Notes:

  • In Layer 3 HA, the upstream router is used to provide equal-cost multipath (ECMP) load balancing across the virtual service’s SEs.
  • For Layer 3 HA, configuration may be required on the router between the SEs and the back-end servers, to enable return traffic from the server to reach the SEs.
  • In Layer 2 HA, scale out is not possible.

Starting with Avi Vantage release 20.1.1, virtual services can now have SNAT enabled when associated with a Service Engine Group and VRF that have a network service with IP routing enabled. However, on any given virtual service preserve_client_ip will take precedence over SNAT IP.

Layer 2: Cluster HA (A/A)

In Layer 2 cluster HA, one SNAT IP is required per SE at the virtual service configuration level. When an SE initiates the connection to the back-end server, the SNAT IP corresponding to that SE will be used for the connection.

If the default Layer-2 forwarding option is used, the connections from clients would always go to the primary SE and then get distributed using Layer 2 forwarding. Here is an example of a typical Layer 2 cluster HA topology.

snat-iptopo2

In this topology, two virtual services are configured. Each of the virtual services is provisioned with a distinct SNAT IP. Since cluster HA is selected, each virtual service will need to be provisioned with as many SNAT IPs as the number of SEs in the SE group. The Avi Controller will automatically distribute the SNAT IPs to the individual SEs on which the virtual services are enabled.

Here is the SNAT configuration in the web interface for Virtual Service 1 with IPv4 addresses in the example topology.

IPv4 Address

Here is the SNAT configuration in the web interface for Virtual Service 1 with IPv6 addresses in the example topology.

IPv6 Address

Layer 2: Legacy HA (A/S)

Legacy HA mode typically is used when migrating from appliance-based load balancing deployments, which typically support only 1:1 active-standby HA mode. In this case, only a single SNAT IP per virtual service is required, since the standby SE does not carry any traffic. Here is an example of a typical Layer 2 legacy HA topology.

snat-iptopo3

In case of a failover, the newly active SE will take over the traffic as well as ownership of the SNAT IP from the failed SE. Health monitoring is performed only by the active SE.

Here is the SNAT configuration in the web interface for Virtual Service 1 in the example topology.

img2

Layer 3: Elastic HA (A/A)

In Layer 3 dynamic HA, the SNAT IP is advertised dynamically through BGP. BGP support is enabled in the virtual service configuration. Using BGP enables an active/active scale out topology when the SNAT IP is not part of the SE interface’s subnet.

When SNAT is enabled, Avi Vantage user will need to provision as many SNAT IPs as the width of the scale out desired. For instance, to support to a maximum of 4 SEs, 4 unique SNAT IPs are required in the virtual service configuration. If fewer SNAT IPs are configured than the maximum scale out size, scale out is limited to one SE per configured SNAT IP.

Here is an example topology with SNAT enabled in scale out HA mode with BGP enabled.

snat-iptopo4

Here is the SNAT configuration in the web interface for Virtual Service 1 in the example topology.

img3

For details on enabling BGP to advertise SNAT IP addresses, click here.

Layer 3: Legacy HA (A/S)

This mode requires only a single SNAT IP per virtual service, since scale out is not possible. The active SE carries all the traffic and owns the SNAT IP, while the standby SE remains idle. In case of a failover, the standby SE takes over the traffic as well as ownership of the SNAT IP.

A floating interface IP needs to be provisioned in order to provide adjacency to the upstream router, for the SNAT IP.

For more information, click here.

Using the CLI

The following commands add SNAT IP address 10.200.1.1 and 2001::10 to Virtual Service 1:

: > configure virtualservice Virtual Service 1
...

: snat_ip 10.200.1.1
: snat_ip 2001::10
: save