Forum Discussion

dleija_23325's avatar
dleija_23325
Icon for Nimbostratus rankNimbostratus
Aug 24, 2015

Private VIP Access Control Options

We have an 'Inline BigIP F5' deployment. Our F5 sits in front of our content servers, sitting between the private and public. We use NATs on the public side to distribute traffic to our internal/private web/etc... servers. Using the public side VIPs, if you source traffic from outside everything works fine. There are also servers on the private side that need to communicate with other servers in that same network, but per the AppDev group, that traffic must be loadbalanced. We were unable to connect from private side hosts to the public side VIP pointing to hosts back inside that same private segment. That intuitively makes sense so what we did was create a VIP on the private side of the LB also pointing to those same resource servers. That didn't work until we enabled 'Source Address Translation' using 'Auto Map'. This is a cleaned version of our setup:

    --192.168.10.20-VIP     PUBLIC
  /    [Loadbalancer]  ---------------------
  \   192.168.20.20-VIP     PRIVATE
   \     /
    \   /
      v
192.168.20.21(srver)    192.168.20.51(client)
192.168.20.22(srver)    192.168.20.52(client)

All done right??? Wrong!!! 🙂 Now the AppDev guys are complaining that their application statistics are being masked by the LBs private side IP, which is true, but not a deal breaker really. What is a bit more of a legit concern to us is these particular hosts are configured to only allow certain IPs in the private DMZ to communicate with them. That security policy/rule does not work when all such client requests appear to source from behind the LBs private side IP.

I looked at a couple of options, DSR, adding another network segment for these types of hosts, etc . . . It seems, however, like I should be able to control what IPs are allowed to connect to a VIP. Is there anything along these lines I can do to avoid rearchtecting our DMZ?

TIA!

2 Replies

  • Probably a simple irule/datagroup would do it. This rule will drop any connections from hosts not in the 'allowed-hosts' datagroup,

    cheers

    when CLIENT_ACCEPTED {
      if { not ([class match [IP::client_addr] equals allowed-hosts]) } {
        log local0. "[IP::client_addr] is not permitted to serverpoolXXX"
        drop
      }
    }
    
    ltm data-group internal allowed-hosts {
        records {
            192.168.20.51/32 {
                data "ServerYYYY"
            }
        }
        type ip
    }
    
  • You're pretty much stuck with SNAT as long as all of the clients and servers are on the same subnet. So you really have two options:

     

    1. Move your ACLs to the BIG-IP, as arpydays relates.

       

    2. If this is HTTP traffic you can inject an X-Forwarded-For header with the real client address and configure your servers to look for the XFF HTTP header instead of layer 3 IP addresses.