Incapsula Load Balancing

Created at:
Avatar
Updated

Load Balancing

Incapsula Load Balancing distributes user requests among your data centers and/or servers, in order to achieve optimal performance and response time, and routes traffic to healthy servers when some servers or data centers are malfunctioning. It includes the following features:

  • Server Load Balancing (SLB) – load balancing among several servers within a data center.

  • Global Server Load Balancing (GSLB) – load balancing among the servers of several data centers. You can also use the GSLB settings to route requests according to the geographical location of the site user.

  • Server Failover – identifying malfunctioning servers and routing their traffic to other, healthy servers.

  • Incapsula Load Balancing – identifying when an entire data center is down and routing its traffic to a designated standby data center.

NOTE:
The Load Balancing and Failover features are only available to Incapsula’s Enterprise customers (and the multiple server and multiple data center topology options are only enabled for these customers).
Note that the Multiple Data Center feature must be purchased separately.

NOTE:
If your site already has one or more load balancers installed, the load balancers’ IP addresses should be entered as server IPs in the Incapsula Load Balancing configuration. Incapsula will treat each load balancer as if it were a single server.

This document describes how to configure the related Server Settings and Monitoring parameters according to your site topology and routing requirements, and your preferences for health tests and alarm notifications.

 

Load Balancing Use Cases

The following sections describe some typical data center topology use cases, and how to configure Incapsula Load Balancing for each case.

These are the use cases described:

 

Use Case I: Single Origin Server

Description: The Single Origin Server topology is the default configuration, and the simplest to configure. When you add your site as an Incapsula user, your server’s IP address is added automatically to the Server Settings. If necessary, you can edit the server’s IP address or CNAME at any time.

Obviously, a single server topology cannot support load balancing or failover features.

How to Configure: See Single Origin Server.

Single Origin Server: Server is Active


Single Origin Server: No Service when Server is Down

  •  Available to Enterprise customers without additional cost. 

Use Case II: Single Data Center with Multiple Origin Servers; All Active

Description: If you have a single data center with multiple servers, select the Multiple Origin Servers (Single Data Center) topology setting. If all servers should be active at all times, select the Active Server setting for each server that you add.

You can configure each server to have a separate, public IP address, or you can configure only one server with a public IP address, and the other servers to be routed traffic with the aid of port forwarding.

If one or more servers are identified as down, traffic is routed to the remaining active servers.

How to Configure: See Multiple Origin Servers (Single Data Center). 

Multiple Active Servers: Load Balancing among All Servers

 

Multiple Active Servers: Some Servers Down; Load Balancing among Functioning Servers

  •  Two Active origin servers are included for Enterprise customers without additional cost. A purchase of the Load Balancing add-on is required for setups of three or more servers.

Use Case III: Single Data Center with Multiple Origin Servers; Two ISPs

Description: The Active and Standby server modes can be used conveniently when you have two Internet Service Providers (ISPs), one of which you use for normal operation, and one of which (often a more expensive one) you use only as a standby provider.

In this case, if all servers have public IP addresses, add each server twice: once as Active Server with an IP address from the primary ISP, and once as Standby Server with an IP address from the “standby” ISP.

If you are using port forwarding, enter the IP address from the primary ISP in the IP Address field, and enter the IP address from the “standby” ISP in the Standby IP Address field.

How to Configure: See Multiple Origin Servers (Single Data Center).

Dual ISPs: Active “Identities” Used when Primary ISP is Active

 

Dual ISPs: Standby “Identities” Used when Primary ISP is Down

  •  Purchase of the Load Balancing add-on is required.

Use Case IV: Single Data Center with Multiple Origin Servers; Active & Standby

Description: You may have a single data center with multiple servers, but you want some of the servers to act as standby servers, only receiving traffic when all active servers are down.

In this case, select the Multiple Origin Servers (Single Data Center) topology setting, and define some servers as Active Server and some as Standby Server. Normally, traffic is load balanced only among the active servers. If all active servers are down, traffic is load balanced among the standby servers. When at least one active server is back up, traffic is again routed only to the active servers.

If all servers have public IP addresses, there are no constraints on the numbers of active and standby servers. In the case of port forwarding, active/standby mode can only be supported if there are equal numbers of active and standby servers.

How to Configure: See Multiple Origin Servers (Single Data Center).

Active and Standby Servers: Standby Servers Not Used Unless All Active are Down

Active and Standby Servers: Standby Servers Used when All Active are Down

  • Purchase of the Load Balancing add-on is required.

 Use Case V: Multiple Data Centers with Standby Data Center

Description: You may maintain one or more active data centers and one standby data center, which should only serve site traffic if all active data centers are down.

If this is your case, select the Multiple Data Centers topology setting. Define each data center in the Incapsula configuration, and enter the standby data center’s name in the Standby DC Name parameter of the Failover Attributes section.

How to Configure: See Multiple Data Centers.

Standby Data Center: Standby Center Not Used Unless All Active Centers are Down

Standby Data Center: Standby Center Used When All Active Centers are Down

  •  Purchase of the Load Balancing add-on is required.

Use Case VI: Multiple Data Centers for Performance Purposes

Description: There can be different reasons for maintaining multiple data centers to serve a single web site. One reason is to provide better performance by serving users from data centers that are geographically close to their location.

If this is your case, select the Multiple Data Centers topology setting, and select the Best Connection Time mode (the default). This will cause the load balancing mechanism to serve each user from the data center that provides the shortest response time to the specific user.

How to Configure: See Multiple Data Centers.

Performance: Users are Served from Data Center Providing Best Connection Time

Performance: If Data Center Down, Users Served from Active Center with Best Time

  • Purchase of the Load Balancing add-on is required.

Use Case VII: Multiple Data Centers for Localized Content

Description: Some web sites provide localized content, depending on the location from which the site is accessed. For instance, users from the West Coast of the U.S.A. might see different articles or advertisements than users from the East Coast.

If this is your case, select the Multiple Data Centers topology setting, and select the Geo-Targeting Preferred mode. This means that the load balancing mechanism will serve users from the data center that is geographically close to them, as long as that data center is active. But if the closest data center is down, user requests will be served from other active data centers, according to the Best Connection Time mode.

To work in Geo-Targeting Preferred mode, you must assign each geographical area to a specific data center. The last area assigned will always be Rest of the World, whose data center will handle requests from all areas not explicitly assigned to another data center.

How to Configure: See Multiple Data Centers.

Geo-Targeting Preferred: Users Served from Targeted Data Center

Geo-Targeting Preferred: If Data Center Down, Users Served from Active Center with Best Time

  • Purchase of the Load Balancing add-on is required.

Use Case VIII: Multiple Data Centers due to Regulation

Description: Some web sites maintain multiple data centers because local laws and regulations stipulate that users from certain areas must only be served locally.

If this is your case, select the Multiple Data Centers topology setting, and select the Geo-Targeting Required mode. This means that the load balancing mechanism will serve users from the data center that is assigned to them, and if that data center is down, they will not receive service. Because of the regulation, a standby data center in another geographical region is not an option.To work in Geo-Targeting Required mode, you must assign each geographical area to a specific data center. The last area assigned will always be Rest of the World, whose data center will handle requests from all areas not explicitly assigned to another data center.

How to Configure: See Multiple Data Centers.

Geo-Targeting Required: Users Served from Targeted Data Center

Geo-Targeting Required: If Data Center Down, No Service for Targeted Area

  • Purchase of the Load Balancing add-on is required.

 

Load Balancing Configuration

The next two sections  - Origin Servers Configuration and Site Monitoring Configuration - describe how to configure the settings for Incapsula Load Balancing and Monitoring features.

Origin Servers Configuration

The Origin Servers page allows you to define your site topology as Single Origin Server, Multiple Origin Servers (Single Data Center) or Multiple Data Centers, and to configure the settings for the selected topology.

 

To view the Origin Servers page:

Click the Origin Servers icon in the left-hand menu.

NOTE:
After all changes to settings, click the  button on the top right.

 

To change the site topology setting:

Click the arrow in the dropdown menu on the top right, and select the value that reflects your site’s topology:

NOTE:
You can only choose a topology that is supported by your current plan. You may wish to upgrade your plan in order to support a different topology, or add more data centers / servers.

 

NOTE: Your servers may be configured to use external CNAMEs (such as Amazon Alias Names) instead of explicit IP addresses. In this case, you can enter CNAMEs in any
IP Address/CNAME field in the Server Settings, but note that you can only enter one CNAME per data center.

 

Single Origin Server

The Single Origin Server topology is the default setting. Select this option if your site runs on a single server.

NOTE:
Load balancing and failover features are not available when the site has only one server.

 
Server IP

The only setting to configure for the Single Origin Server topology is the IP Address attribute. Incapsula will automatically detect your origin server’s IP address and populate this field.

 

To change the origin server’s IP address or CNAME:

Type the origin server’s IP address, CNAME or alias in the IP address/CNAME field.

 

Multiple Origin Servers (Single Data Center)

Select this topology setting if you have multiple origin servers in a single data center. In this case, you can choose one of two ways for Incapsula to access your origin servers:

  • Multiple Public IPs (the default) – each of the origin servers has a public IP address.

  • Single Public IP with Port Offsets – only the site’s router/firewall has a public IP address. Each origin server is assigned with a different port. Load balancing is implemented by updating the routing tables of the router/firewall with the “port-internal IP” allocations (see Appendix: Port Forwarding Configuration for details on configuring some common firewalls to support this option).

Server IPs in “Multiple Public IPs” Mode

Servers in “Multiple Public IPs” mode may be defined as “Active” or “Standby”. Requests will be routed to “Active” servers as long as their status is “up”. Requests will only be routed to “Standby” servers if all active servers are “down”.

NOTE:
If you are using two different Internet Service Providers (ISPs), one as the operational default and one as standby, it is convenient to use the Incapsula Active/Standby configuration for this purpose. In this case, define the server IPs from the default ISP as “Active”, and define the parallel server IPs from the standby ISP as “Standby”.

 

To add an origin server IP address:

  1. Click Add Server. A new row is added to the list of Server IPs.

  2. In the IP Address/CNAME field, type the server’s IP address, CNAME or alias.

NOTE: Only one CNAME / alias can be entered per data center.

     3. In the dropdown, select “Active Server” or “Standby Server”.

 

To edit an origin server’s IP address:

Click  next to the address and type the new IP address.

 

To delete an origin server:

Click next to the server:

 

To switch to the Single Public IP mode:

Click “Use single public IP with port offsets”.

 
Server IP in “Single Public IP and Port Offsets” Mode

 

To configure the Single Public IP access mode:

Enter the following field values:

  • IP Address – the single IP address through which the site will be accessed.

  • Standby IP Address (Optional) – this parameter may be used if you have two different Internet Service Providers (ISPs), one used as the operational default and one as standby. In this case, enter the default ISP’s IP address in the IP Address field, and enter the standby ISP’s IP address in the Standby IP Address field.

  • Number of Servers – the number of the site’s origin servers in the data center.

  • HTTP Port Ranges – the port ranges assigned by Incapsula to your origin servers for HTTP traffic. Each origin server is assigned one of these ports. You must route these port allocations to your origin servers in your router/firewall by configuring the IP tables (see  Appendix: Port Forwarding Configuration).

  • HTTPS Port Ranges – same as HTTP Port Ranges, but for the HTTPS protocol.

To learn more about configuring routers to work in the Port Offsets mode, see Appendix: Port Forwarding Configuration.

 

To switch to the Multiple Public IPs mode:

Click “Back to multiple public IP mode”.

Load Balancing Attributes

You can choose the load balancing algorithm that determines the origin server to which the next request will be routed. The available modes are:

  • Source IP Hash – a hashing function maps the IP address of the request’s source to one of the origin servers, to which the request is routed. Rudimentary, simple and effective. Packets that arrive from a specific source IP are sent to a specific server. Since many servers implement session state independently clients will keep being connected to the same server. On large sites, load is distributed fairly well. Destination IP availability is, of course, being evaluated prior to packet allocation.

  • Random - the next request is routed randomly to one of the origin servers. The most basic algorithms and the ones most used. On large sites load will be distributed pretty well, though on smaller sites load may not be balanced well. As opposed to Source IP Hash clients may be referred to a different server on each request.

  • Least Open Connections - the next request is routed to the origin server with the smallest number of open TCP connections. This algorithm is better in terms of balancing the load between the different destination IPs. As opposed to the previous two algorithms, this algorithm actually takes into account the actual load (in terms of open connections) of the different destination IPs when performing routing decisions. On the downside, clients may be referred to a different server on each request.
  • Least Pending Requests – the next request is routed to the origin server with the smallest number of pending HTTP requests. This algorithm is the best of all four in terms of balancing the load between the different destination IPs. The impact of pending requests on load is much more direct than that of open connections thus it usually serves as a better load balancing algorithm. This algorithm, similarly to the previous two, also does not support “Session Stickiness” and therefore may refer clients to different servers on each request.  

NOTE:
The default (and recommended) load balancing algorithm is Least Pending Requests.

Enterprise customers which have not purchased the Load balancing add-on and use Single Data Center with Multiple Origin Servers; All Active will only be able to use the Least Pending Requests load balancing algorithm. 

 

To configure the load balancing attributes:

  1. In the Mode dropdown, select the load balancing algorithm you want.

  2. Check the Persistence checkbox if you want each user session to be served by a single origin server. Use this option if the session must maintain stateful information. When this option is used, the load balancing algorithm will only be applied to the first request of each user session, and Incapsula maintains user session continuity by setting a dedicated session cookie in the user’s browser.

 

Multiple Data Centers

Select this topology setting if you have multiple origin servers in multiple data centers.

 
Global Server Load Balancing Attributes

The Mode attribute in this section determines how user requests will be routed to data centers.

In the Mode dropdown, select one of the following options:

  • Best Connection Time – the average connection times between each Incapsula PoP and each of the site’s data centers are sampled and updated periodically. When this mode is selected, the PoP will route requests to the data center that currently provides the shortest connection time.

  • Geo-Targeting Required – each geographical location is mapped to a single data center. This mode is useful when local regulation requires that sites be served from a certain location. If one of the geo-targeted data centers is down, requests directed to that data center will not be re-routed and will fail.

  • Geo-Targeting Preferred – Similar to Geo-Targeting Required, except that if one of the geo-targeted data centers is down, an attempt will be made to re-route requests directed to that data center to other active data centers. The alternative data center is chosen by applying the Best Connection Time algorithm. This mode is useful when the site produces different content for different locations.

If one of the Geo-Targeting options is selected, you must map each region to a single data center. Each continent is a region, and the U.S.A is divided into “U.S. East” and “U.S. West”.

 

To map regions to data centers:

  1. Click Add Geography. A new row is added for the new region.

  2. In the Geographic Region dropdown, select the region.

  3. In the Data Center dropdown, select the data center to which the region’s requests will be routed.

  4. Repeat steps (1) to (3) for each region you want to specify. Note that each region can only be mapped to a single data center, and once a region is mapped, it will not be available when adding another mapping.

  5. If not all regions were mapped, select the data center that will handle the requests for the Rest of the World (in the last row of the region table).

NOTE:
If Geo-Targeting is selected, and not all data centers have been assigned a region, when saving the settings you will see the following warning:

 
Failover Attributes

The Failover Attributes section contains attributes that determine when a data center will be considered “down”, which standby data center to activate in this case, and optionally a URL to call in order to activate the standby data center.

The attributes are:

  • Standby DC Name – the name of the standby data center. If this attribute is set to “None”, failover is disabled. If it is set to one of the defined data centers, requests will be routed to the standby DC if all other DCs are “down”.

NOTE:
The standby data center cannot be one of the geo-targeted data centers, and vice versa. In addition, the standby data center must be Enabled. If a disabled data center is chosen as the standby, the Standby DC Name will be changed back the None when the settings are saved.

  • Minimum number of servers for “DC UP” – a data center must have at least this number of active servers for it to be considered “up” (operational).

(See Monitoring to learn more about how a server’s status is determined.)

  • Monitors required to decide on failover – each of Incapsula’s PoPs monitors each data center’s health, according to the rate of errors received from the data center. Each PoP may produce a different assessment, depending on the types of requests it receives (some of which could be invalid). This attribute determines the number of PoPs that must produce a “failed” assessment for the data center, before it is considered “down”. This can be one of the following values:

    • One – only one “failed” assessment is required

    • More than one – more than one “failed” assessment is required

    • Most – the majority of assessments must be “failed”

    • All - all assessments must be “failed”

  • Standby DC Kickstart URL – Optional. If this value is entered, the URL will be called when Incapsula decides to perform a failover. The customer must implement the URL as a “kickstart” function that initializes the standby data center.

  • Credentials for Kickstart URL (if required) – if a user name and password are required in order to call the Kickstart URL, enter them in this field.

Adding a Data Center

When working with multiple data centers, you must configure attributes for each of the data centers serving your site. Each data center can work either in the Multiple Public IPs mode or in the Single Public IP mode.

NOTE:
You can temporarily disable a data center (without deleting its configuration) by unchecking its Enabled checkbox and clicking Save. This is useful, for instance, when you need to perform maintenance activities in the data center.

 NOTE:

There must be at least one Enabled data center per site.

 

To add a data center:

  1. Click the button.

  2. Choose the Multiple Public IPs mode or the Single Public IP mode. A new data center pane is displayed, with fields according to the mode you chose.

  3. In the Name field, enter a name for the data center.

  4. Verify that the Enabled field is checked.

  1. For the Multiple Public IPs mode, click , enter an IP address for the new server, and repeat for each origin server (see Server IPs in “Multiple Public IPs” Mode).

  2. For the Single Public IP mode, enter the public IP and port ranges (see Server IP in “Single Public IP and Port Offsets” Mode).

  3. Set the load balancing Mode and Persistence values (see Load Balancing Attributes).

 

To remove a data center:

Click the  button at the top right of the data center section.

NOTE:
Newly added data centers and changes to data center names must be saved before the new values appear in data-center-related dropdown values (e.g. when defining geo-targeting and standby data centers). On the other hand, deletions of data centers will immediately affect dropdown values.

 

Site Monitoring Configuration

The Site Monitoring page allows you to configure settings for determining when origin servers should be considered “up” or “down” (active or inactive) by the Load Balancing mechanism. It also contains Alarm settings that determine which failure scenarios will produce alarm messages, and how to send them.

To view the Site Monitoring page:

Click the Monitoring icon in the left-hand menu.

 

Monitoring Parameters and Failed Request Criteria

These two sections contain parameters that define rules for determining when an origin server is considered down by the Load Balancing mechanism.

The parameters are:

  • Percentage of failed requests to mark server “Down” – if the percentage of failed requests is above this threshold for a certain period of time, the origin server will be considered “down”. The types of errors that are considered failed requests are defined in the “Failed Request Criteria” section. In addition to the percentage threshold, there must be at least the defined Minimum number of requests, that were sampled during the time period that was defined by the user in the "Mark server as “Down” if failed request percentage is above threshold for at least [X]", for the server to be marked as “down”.

  • Mark server as “Down” if failed request percentage is above threshold for at least [X] – this is the configurable time period during which the percentage of failed requests is measured. The smaller this period is, the more sensitive the system will be to short periods of failure.

  • Request Timeout – if a request times out within this configurable period, it will be counted as a failed request.

  • HTTP response error codes to be treated as down – in this field, you can enter specific HTTP response error codes or patterns that will be counted as request failures. The codes can be specific errors such as “401”, or patterns with wildcards such as “4xx”. The codes and patterns should be separated by commas, or dashes to define ranges. For example: “401, 404, 407, 5xx” or “501-599” (to define all values between 501 and 599).

NOTE:
All TCP connection errors and TCP timeouts are considered failed requests by default.

 

Verify “Down”/”Up”

This section contains parameters for verifying that an origin server is down after failed user requests are identified, and determining when an origin server is back up after a failure.

This includes the following parameters:

  • Use verification checks to mark server as “Down” – by default, only the regular site traffic (generated by users) is monitored for failed requests. If this parameter is checked (the default setting), and Incapsula determines that an origin server is down according to failed request criteria, it will initiate another request and test its response, to verify that the origin server is down. The request is defined by the “URL for Monitoring” parameter, and its expected response is defined by the Expected receive string parameter..

  • URL for monitoring – this is a URL suffix (without the http:// prefix) that refers to your site. If this parameter is left with the default value of “/”, the site’s root will be accessed. Alternatively, you can configure this parameter to refer to a specific URL to be called in order to test an origin server’s health. In both cases, the response is tested for success according to the rule defined in the “Expected receive string” parameter.

NOTE:
You can also add a port number to the URL, e.g.: /index.php:433

  • Expected receive string – if this parameter's value is an empty string, any response  except for the codes defined in the HTTP response error codes to be treated as Down parameter will be considered successful. If the value is non-empty, then the defined value must appear within the response string for the response to be considered successful.

  • Interval for “Up” checks – after an origin server was identified as down, Incapsula will periodically test it to see whether it has recovered, according to the frequency defined in this parameter.

  • Retries for “Up” checks – every time an origin server is tested to see whether it’s back up, the test will be retried this number of times. If all tests are successful, the origin server will be considered “up”.

 

Alarms

The Alarms settings determine which failure scenarios will produce alarm messages, and how the alarm messages will be sent.

The Alarms parameters include:

  • Scenarios – the scenarios that will produce alarm messages:

    • Failover to STBY DC – if checked, an alarm is sent when Incapsula fails over to the standby data center.

    • DC Down - if checked, an alarm is sent when the number of POPs  defined in the Send me alarm if parameter determines that a data center is down, and fails over to another active data center.

    • Server Down - if checked, an alarm is sent when the number of POPs  defined in the Send me alarm if parameter determines that an origin server is down.

  • Monitors required to report server/DC as down – this parameter determines how many Incapsula PoPs must perform a failover for the DC Down and Server Down alarms to be generated. This can be configured to be one PoP, more than one PoP, the majority of PoPs, or all PoPs.

 

Appendix: Port Forwarding Configuration

The Single Public IP with Port Offsets mode in Incapsula load balancing enables your site to use a single public IP address, while routing requests to several servers within your site according to the port specified in the request.

In order to work in Single Public IP with Port Offsets mode, you will need to configure your firewall to work with port forwarding, and add the appropriate access and mapping rules to route requests coming through Incapsula to the correct server within your site. This appendix describes how to do this for several commonly-used firewalls.

 

Configuring Port Forwarding for the FortiGate Firewall

To configure the FortiGate firewall to work in port forwarding mode with Incapsula load balancing, perform the following steps.

To configure virtual IP objects for your internal site servers:

  1. Access the FortiGate firewall configuration application through a browser.

  2. In the Firewall Objects tab, select Virtual IP under the Virtual IP group.

  3. Click Create New. A window opens in which you can enter details for a virtual IP address for an internal site server.

  4. In the Name field, enter a name for the virtual IP object.

  5. In the External Interface field, select the appropriate external interface.

  6. In the External IP Address/Range field, enter the external public IP address.

  7. In the Mapped IP Address/Range, enter the IP address of the internal web server.

  8. Check the Port Forwarding checkbox.

  9. In the Protocol field, select the appropriate protocol (should be TCP).

  10. In the External Service Port field, enter the port to which Incapsula will refer.

  11. In the Map to Port field, enter the internal port to which requests to the specified external port will be routed.

  12. Click OK.

  13. Repeat steps (3)-(12) for each internal server.

NOTE:

If you have not already done so, add an Address object for each internal server in the FortiGate Firewall Objects\Address page.


To add a policy rule that allows Incapsula to access your servers:

  1. Open the FortiGate Policy page and click Create New. A window opens in which you can enter details for the new policy rule.

  2. In the Source Address field, click  to add Incapsula prefixes.

  3. In the Destination Address field, click  to add an IP address for an internal VIP. Repeat for each internal VIP.

  4. In the Schedule field, select always.

  5. In the Service field, select the appropriate protocol (usually HTTP or HTTPS).

  6. In the Action field, select ACCEPT.

  7. Click OK.

 

Configuring Port Forwarding for the Cisco ASA Firewall

You can configure port forwarding for the Cisco ASA firewall using either the ASA Command Line Interface (CLI) or the Adaptive Security Device Manager UI application. In both cases you must perform the following actions:

  • Allow Inside users to access the Internet.
  • Enable the Inside web server to provide HTTP services to the Internet.
  • Allow Outside users to access your web server.

Following are examples of how to configure port forwarding for the Cisco ASA firewall.

NOTE:
Replace the IP addresses and subnets in the examples with values that are appropriate for your network.

 

To configure port forwarding for the Cisco ASA Firewall Using the CLI:

  1. Enter the ASA CLI.

  2. Create objects for your Inside network.

LAB-ASA5505-01# conf t

LAB-ASA5505-01# object network INSIDE-SUBNET

LAB-ASA5505-01# subnet 172.20.10.0 255.255.255.0

LAB-ASA5505-01# exit

  1. Create objects for your web server.

LAB-ASA5505-01# object network WWW-SERVER

LAB-ASA5505-01# host 172.20.10.100

LAB-ASA5505-01# exit

  1. Configure Network Address Translation (NAT) so your Inside users can browse the web.

LAB-ASA5505-01# object network INSIDE-SUBNET

LAB-ASA5505-01# nat (inside,outside) dynamic interface

  1. Create a static NAT entry for your web server to your (single) public IP address and configure static NAT with port forwarding.

LAB-ASA5505-01# object network WWW-SERVER

LAB-ASA5505-01# nat (inside,outside) static interface service tcp 80 80

  1. Configure an access list to allow Outside traffic to visit port 80 (HTTP) as your Outside interface.

LAB-ASA5505-01# access-list Outside_access_in extended permit tcp any object WWW-SERVER eq 80

LAB-ASA5505-01# access-group Outside_access_in in interface Outside

  1. Verify your NAT configuration.

LAB-ASA5505-01# show nat

Auto NAT Policies (Section 2)

1 (Inside) to (Outside) source static WWW-SERVER interface service tcp www www

translate_hits = 0, untranslate_hits = 2

2 (Inside) to (Outside) source dynamic INSIDE-SUBNET interface

translate_hits = 6, untranslate_hits = 0

  1. Examine the hit count in the access list and verify that it is increasing.

LAB-ASA5505-01# sh access-list

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)

alert-interval 300

access-list Outside_access_in; 2 elements; name hash: 0xe796c137

access-list Outside_access_in line 1 extended permit icmp any any echo-reply (hitcnt=0) 0x24ee277f

access-list Outside_access_in line 2 extended permit tcp any object WWW-SERVER eq www (hitcnt=4) 0xb7fcf341

access-list Outside_access_in line 2 extended permit tcp any host 172.20.10.100 eq www (hitcnt=4) 0xb7fcf341

 

To configure port forwarding for the Cisco ASA Firewall Using the ASDM UI application:

  1. Launch the ASDM application.

  1. Click New object to create a new NAT object and click on the NAT dropdown.

  2. Enable Add Automatic Address Translation Rules and select Static as the type. In the Translated Addr dropdown, select Outside.

  3. Click the Advanced button.

  1. Select the Source Interface and the Destination Interface.

  2. In the Service section, in the Protocol dropdown, select tcp.

  3. Enter the Real Port and Mapped Port values (for example, set both values to www, http or 80).

  4. Click OK.

 

Configuring Port Forwarding for the Juniper SRX Firewall

To configuring port forwarding for the Juniper SRX firewall, you must perform a NAT redirect in the Juniper CLI. This section describes how to do this for the following example addresses and ports of two origin servers (the addresses and ports on the left are configured in Incapsula and the addresses and ports on the right are the internal IPs and ports used within your network):

172.16.1.2:22   --> 192.168.1.5:2222

172.16.1.2:3389 --> 192.168.1.6:3389

 

To configure port forwarding for the Juniper SRX firewall:

1. Configure the real addresses of the servers using address-book entries.

set security zones security-zone trust address-book address Server1 192.168.1.5/32
set security zones security-zone trust address-book address Server2 192.168.1.6/32

2. Define the pre-translated ports.

set applications application SSH-DNAT protocol tcp
set applications application SSH-DNAT destination-port 2222
set applications application RDP protocol tcp
set applications application RDP destination-port 3389

3. Define each server and port. (These settings relate to the real IP and port configured on the server.)

set security nat destination pool dnat-192_168_1_5m32 address 192.168.1.5/32
set security nat destination pool dnat-192_168_1_5m32 address port 22
set security nat destination pool dnat-192_168_1_6m32 address 192.168.1.6/32
set security nat destination pool dnat-192_168_1_6m32 address port 3389

4. Configure the NAT policy (specify the NAT pool to which traffic should be translated). This defines both the destination IP and destination port address.

set security nat destination rule-set dst-nat from zone untrust

5. Configure the port forwarding  rule for the first origin server.

set security nat destination rule-set dst-nat rule rule1 match destination-address 172.16.1.2/32
set security nat destination rule-set dst-nat rule rule1 match destination-port 2222
set security nat destination rule-set dst-nat rule rule1 then destination-nat pool dnat-192_168_1_5m32

6. Configure the port forwarding rule for the second origin server.

set security nat destination rule-set dst-nat rule rule2 match destination-address 172.16.1.2/32
set security nat destination rule-set dst-nat rule rule2 match destination-port 3389
set security nat destination rule-set dst-nat rule rule2 then destination-nat pool dnat-192_168_1_6m32

7. Configure the security policy. Note that the internal (real) IP address and port of the server is defined within the policy.

set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match source-address any

set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match destination-address server1

set security policies from-zone untrust to-zone trust policy untrust-to-trust1 match application SSH

set security policies from-zone untrust to-zone trust policy untrust-to-trust1 then permit

set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match source-address any

set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match destination-address server2

set security policies from-zone untrust to-zone trust policy untrust-to-trust2 match application RDP

set security policies from-zone untrust to-zone trust policy untrust-to-trust2 then permit





Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk