Forum Discussion

jpeterson6's avatar
Icon for Nimbostratus rankNimbostratus
Aug 06, 2015

Help with configuring F5 load-balancing in between two ASA pairs (full routing)


I'm fairly new to F5s, and from what I've been seeing in my searches it appears as though I've really dived into the deep end for complex F5 setups. I've been spending time researching my issues but so far haven't been able to find the specific answers I need.

Topology Details:

Route Path:
Internet <--> External ASA <--> F5 <--> Nexus 5k <--> Internal ASA <--> Server DMZs

External ASA:
- inside IP is
- Performs Static NAT from public IPs to VS IPs

- external VLAN ( attached to external LACP trunk, tagged
- internal VLAN ( attached to internal LACP trunk, tagged
- default gateway points to    
- internal gateway ( points to
- self-ip (float)
- All VS on
- nodes on multiple 10.x.x.x/24 subnets

- 'outside' IP is
- default gateway points to

Internal ASA:
- default gateway points to Nexus5k
- All load-balanced servers behind ASA on different security zones/interfaces
- No NAT

- Active/Standby HA using an HA VLAN on Internal trunk.
- The gateway of the servers must be the internal ASA.
- The topology cannot be changed.


  1. Will I need any SNATs in this setup? The routing should technically take care of everything so I'm not seeing much purpose in SNATs based on my understanding of how it works.
  2. I already set up an IP forwarding server (source/destination of to allow OUTBOUND (server initiated) routing to pass through the F5; I have enabled loose initiation/close and disabled 'reset on timeout' using an attached custom FastL4 profile. Will I need any special forwarding servers or other virtual servers outside of Standard to make this work for INBOUND connections?
  3. Are there any other details I need to consider that I haven't mentioned here?

5 Replies

    1. since everything appears to be L3 segmented with routes pointing in the "right" direction, I don't think snat is necessary.
    2. If you are routing anything inbound, yes. If you are just serving traffic via specific application virtual servers, no. The outbound virtual will manage return traffic.
    3. Complex because of DMZ, but fairly simple wrt the BIG-IP itself. Note that in DMZs, I always make a habit of disabling auto-lasthop so I am 100% sure I have explicitly allowed traffic to flow instead of BIG-IP getting traffic back to where it came from with or without the routes necessary to do it.
  • Thanks. Something came up as I made changes and I'm hoping I can get assistance for this as well.


    Initially I had set this up so that all the VLANs were on the F5 directly (with their own Self-IP) and would just use Automap to contact the servers, but the customer required all connections (not just outbound) to go through the inside firewall so I had to change that plan to use direct L3 routing.


    I've now set all my Virtual Servers to SNAT 'None' and I'm trying to remove the Self-IPs so I can remove those VLANs, but I'm getting errors that some of my Pools will become unreachable, despite the routing that's in place (they fall into the space).


    Any thoughts on this?


  • I've tried simply removing the pool and removing the Self-IP, but it just finds the next Pool in line on the same subnet to complain that I will lose connectivity if I remove that Self IP.


    I'll try to clarify my current problem:


    A node has the IP of on VLAN 104. VLAN 104 currently resides on the F5, with a Self IP of The internal VLAN still exists on the F5 with a floating SelfIP of


    By redesigning this so that only Routing should direct the load-balanced traffic to the DMZ network (, it should direct any routes destined to to the internal gateway of, yet the F5 is complaining that removing the SelfIP of will make the node unreachable.


    Why is this? Am I perhaps missing some configuration to tell the F5 to use the routing table for referencing load-balance destinations?


    Or am I looking at this all wrong?


    I realize this problem is different than the original, but they are directly related.


  • Yeah, the implied directly connected route trumps the static route and as you've found cannot be deleted because of the 'referenced' object protection, in this case a pool in the same network.


    There is a way round it though, change the subnet mask on the self-ip to /32 and you should be good to delete it.