June 22, 2010
This document explains how to set up multiple iPrisms in a load balancing environment. We thoroughly tested the F5 BigIP FireGuard product. This document includes information about persistence, authentication, reporting and iPrism management apart from other standard features.
The F5 load balancer is specifically designed to load balance outbound connections where persistence based upon client source address is required. The software version originally tested had a bug that caused persistence to not work properly; hence we downgraded the software to version BIG-IP Kernel 4.1.1PTF-03 Build3. This bug may be fixed in future versions of the OS, but we have not verified this.
As shown in the diagram, traffic from users intending to access the Internet is intercepted by the F5 load balancer and load balanced between two iPrisms. More iPrism units can be added to the load balancing pool depending on traffic and network requirements.
F5 can be set for load balancing in either Layer 2 (Bridging) or Layer 3 (Routing) mode. The advantage of setting it in Layer 2 mode is that no network level changes would be required. Both of the F5 interfaces will be in the same logical network. What this means is that you won’t have to modify any IP addressing or change default gateway settings in your network. The F5 will fit transparently into your network. The downside is that the F5 configuration is somewhat difficult to setup in Layer 2 mode as compared to Layer 3.
In Layer 3 mode, the F5 is set up as a router and both of the interfaces are in a different subnet with separate IP addresses. Your internal router will need to be configured to use F5 as its default gateway. Similarly, the Internet router will have the F5 interface as the next hop to reach the corporate network. This will require you to modify some of the settings in your network and you will need another subnet.
Please refer to the F5 installation guide and user manual for more details.
F5 Load Balancer has two interfaces: Internal and External. The external interface is connected to two (or more) iPrisms via a switch. The internal interface connects to the customer’s network from where user traffic is intercepted and load balanced to iPrisms.
A Virtual IP (VIP) with address 0.0.0.0 and port 80 is created in F5. With this, F5 will accept HTTP traffic destined for ANY location and balance the load between iPrisms defined in the load balancing pool. Both of the iPrisms are defined as NODES associated with a POOL in F5 and this POOL is associated with the VIP. There are some special configuration settings which administrators need to be aware of while configuring F5.
Note: In Layer 2 (Bridging) mode, both interfaces of F5 iPrisms, Internal router's ethernet interface, and firewall's Internal interface will be in the same layer 3 subnet.In Layer 3 (Routing) mode, both interfaces of F5 will be in different layer 3 subnets.
In Layer 2 mode, VIP 0.0.0.0:80 should have Address and Port Translation disabled. The pool where iPrism IP addresses are added as members should have Simple Persistence enabled with a Timeout of 86400 seconds (one day). With this setting, users will be load balanced to the same iPrism until the timeout expires. This setting is important in environments where authentication is enabled.
In summary, the steps are:
Create a POOL in F5 with the iPrisms as members of this pool. Associate port 80 to the iPrism IP address while defining it as Node in this pool.
Create VIP 0.0.0.0:80 and disable Address and Port translation.
Associate this VIP with the POOL.
In Pool properties, enable Simple Persistence with timeout of 86400 seconds.
If you are setting up F5 in Layer 3 mode, make sure that IP forwarding is enabled in System properties.
iPrisms are set up in single interface mode. Both of the iPrisms connect to F5’s external interface through a switch. In this configuration setup, iPrism is completely unaware of any Load Balancing environment. All the iPrisms in load balancing mode should be configured with the same access policy. We recommend you configure them in master/slave configuration mode so that configuration changes on the master are automatically replicated to slave iPrisms. It is important that all the iPrisms have the same configuration. Otherwise, users will experience inconsistent Internet access, depending on which iPrism their traffic is sent to.
If F5 is setup in Layer 2 (Bridging) mode, iPrisms should have the default route pointing to the Firewall (or Internet Router) and at the same time have Static Routes for internal networks with the next hop as the Internal Router’s interface.
If F5 is setup in Layer 3 mode, iPrism will have the same settings for default route but should have Static Routes for the internal networks with the next hop as F5’s external IP address.
If you intend to use iPrisms in Direct mode, you can configure your workstation browsers to point to a specific Virtual IP on port 3128 (or as a configured port in iPrism) and associate this VIP to the pool with iPrisms as its members. The F5 Load Balancer can be installed as shown in the diagram. The default route on F5 should point to the Firewall (or Internet Router). In this mode, the browser will send traffic to this VIP on port 3128 (or as configured in the iPrism), which will be accepted by F5 and load balanced between iPrisms. Please refer to the diagram below for details.
Note: The VIP 192.168.1.1 is an example and will depend uponIP addressing of your network. In this setup, all workstationbrowsers will point to this Virtual IP address as their proxy.
In summary, the steps are:
Create a POOL in F5 with the iPrisms as members of this pool. Associate port 3128 to iPrism IP address while defining it as Node in this pool.
Create VIP 192.168.1.1:3128 and enable Address and Port translation. IP address used here is just an example and will depend upon the IP addressing of your network.
Associate this VIP with the POOL.
In Pool properties, enable Simple Persistence with timeout of 86400 sec.
Authentication can be enabled on the iPrisms depending on the customer’s requirements. If authentication is enabled, it is important to have appropriate persistence settings on the F5 so that a user is not prompted for login again.
It is important to understand the need for persistence with reference to authentication. If a user tries to go out to web with authentication enabled on iPrisms, the user will get load balanced to iPrism A and prompted for authentication. After providing user credentials, the user will be able to access the web. It is important thereafter that all subsequent web requests are sent to the same iPrism by F5 for the rest of its session. If they are sent to the second iPrism, the user will be prompted for authentication again. This is where persistence in F5 will be helpful. With persistence enabled, all sessions from a workstation are sent to the same iPrism. Persistence mask can be left as default ( /32 ) or set as required. Please refer to F5 documentation for details.
F5 Load Balancer keeps track of active nodes by transmitting POLL CHECK at regular intervals. This timer is configurable in F5. If a node fails to respond back to F5, due to hardware failure or network problems, F5 declares that node as OUT OF SERVICE. F5 will then send traffic to the active node.
In this scenario, if authentication is enabled, users will have to authenticate again if their traffic was passing through the iPrism which failed. If their traffic gets redirected to an active iPrism, that iPrism is not aware that the user had performed authentication to the inactive iPrism.
In this setup, we tested with the default settings enabled for poll check on F5 (15 seconds). It took about 20 seconds for F5 to detect failure of iPrism and somewhere between 60-90 seconds to actually redirect traffic to the active iPrism.
Reports can be generated by individual iPrism units, or aggregated using ERS or a Syslog host. Note the following:
Each iPrism unit supports a feature rich reporting system based on its own event information, see:
How do I use Reports Manager?
How do I use the Real-Time Monitor?
In addition, multiple iPrism units can be configured to send event information to an Enterprise Reporting Server (ERS) host. ERS provides very high-performance aggregated reporting, providing an enterprise-wide view of filtering activity and therefore security policy enforcement. For an overview with links to more detail, see:
Support for aggregated data collection via Syslog hosts is also provided, see:
How do I configure a Syslog Host for HTTP/IM/P2P Events?
In order to administratively manage iPrisms, separate Virtual IPs should be created for both iPrisms. For each iPrism you want to manage and access, you will first need to create a pool with only one iPrism in it and then associate that pool with the Virtual IP of that iPrism. This Virtual IP should not have any port associated with it. Please note that this VIP will be a unique IP address and cannot be the same IP as that of the iPrism. Also, for these VIPs, Address Translation should be enabled where as Port Translation should be disabled.
You can install two F5 boxes in Fail Over mode if you are concerned about redundancy of F5 load balancer. Please contact F5 for more details.
Overrides - In general, overrides for a given user or IP address will work fine. However, trying to override for an entire network or profile won’t work as desired since the people/computers the override applies to will be spread across multiple iPrisms. iPrism (at this time) does not dynamically share override information with others in load balancing pool.
Triggers - Triggers for individual access will work fine, but triggers defined for groups of users will not behave correctly as all users do not access the same iPrism, and iPrism does not dynamically share trigger information.
Reports - without using Enterprise Reporting Server (ERS) or Syslog each iPrism will have its own reports, but the data will not be aggregated into a single report. For an enterprise-wide view of your filtering activity and security policy, ERS is recommended, see:
Request Access - Requesting access will work only from the master iPrism. Users connected to the slave iPrisms will still generate email, but the master iPrism will not have a record of the visited site. It is possible to grant access for these requests, but the URL will have to be cut and pasted from the email. You can turn off the override/request access link should you not require them.
3rd Party Compatibility Before purchasing any 3rd party product intended to integrate with iPrism, you should first evaluate the product to confirm that it meets your requirements and is compatible with iPrism in your environment.