Forum Discussion

Dmetcalfe_13626's avatar
Dmetcalfe_13626
Icon for Nimbostratus rankNimbostratus
Nov 13, 2013

Need to permit public websites to be load balanced internally

Ok, I am very green. I have only ever done labs with the LTM 11.4. Now, I am being asked to take two public facing ips and load balance balance them to the web servers that host them. I have been told that an in-line method is required because due to the way the sites are designed, they require the client ip to be preserved. I have no idea where to start. I don't know how to take requests to those public facing ips and load balance them to one of the two servers, then back out again to the original client. How would I design this? What internal ips would I need? What gateway would I use? Would I use SNAT or would that eliminate the source ip and cause the site to fail? Totally lost.

 

design

2 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 13, 2013

    What are you going to run, VE or physical? HA pair or single?

     

    Why two IPs? As your load balancing we can reduce this to one yes? Are you able to modify the DNS that points to the public IP.

     

    Does a firewall NAT the public IPs to an internal address?

     

    What interfaces does the F5 need? External and internal? Will external be in a public address range?

     

    Can the F5 be the default gateway for the web servers?

     

    The more information you can provide the better please.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Nov 14, 2013

    If I may add, a BIG-IP load balancing configuration can be as simple as a virtual server and a pool. The pool contains the real IP and port of the web servers, and the virtual server (VIP) defines the virtual destination address and port - the address that clients will contact to get to the web application. Create your pool. Create your VIP. And then bind the pool to the VIP. Done. When the client makes a TCP connection with the BIG-IP VIP, the client source address will, by default in a standard virtual server configuration, remain the same, while the destination address will change to the address of the chosen pool member. The web server will receive the request, and depending on routing, send the response back through the BIG-IP. Now, if the server knows of another route to the client that isn't through the BIG-IP (a default gateway perhaps), then you'll find yourself in an "asynchronous routing" problem, where the client will receive a response from an address that it doesn't know (the address of the web server). This is what SNAT is for. With a SNAT profile applied, the client's source address will be changed to an address that is managed by the BIG-IP, which will force the server to return the response through the BIG-IP. The problem with this of course is that you lose the client's true source address. There are at least two ways to manage this issue:

     

    1. If this is HTTP traffic, the BIG-IP can inject an "X-Forwarded-For" header into the request that contains the client's true source address. For other protocols it may be possible to inject the source into other areas of the payload.

       

    2. You can make the BIG-IP's internal self-IP address the default gateway for the web servers. This should guarantee return routing, but may also cause other implications for the web servers. For instance, if they need to be able to talk out to the world, you may need to put a forwarding VIP on the internal VLAN for these web servers.

       

    As far as the virtual server goes, as I said, the simplest configuration can be nothing more than a VIP and a pool. If you need additional services, like persistence, iRules, SSL offload, and others, these are all profiles that are first created, and then bound to the VIP config.