none
Forefront UAG SP1 behind Cisco ASA RRS feed

  • Question

  • I have a UAG Array that is load balanced behind a F5.  This array and F5 pair also site behind a Cisco ASA 5500 Firewall.  Unless I do Source Nat on the F5...all the traffic sent to my backend published apps tries to go out their defualt gateway(which bypasses the UAG and goes right to the ASA and Internet, rather than back through the UAG.  I thought by default the UAG will assign a source IP of its internal adapter to traffic it passes to published app servers?

    Friday, August 12, 2011 9:47 PM

Answers

  • Hi Rob,

    there isn't a specific option to "force" this behavior. All you can do is to configure UAGs routing table to make this happen. The UAG access to your backend application have to be forwarded on the internal interface, and the backroute to your UAG have to follow exactly the same path (symetric routing).

    In most of the dual homed and F5 loadbalancing scenarios i've seen so far the symetric routing configuration is a challaging thing and most of the time you'll need a well thought routing infrastructure and also "some" Source NAT in place to make it fully functioning.

    Imaging the following scenario...

     

    INET
    
     | (EXT)
    
    ASA --- DMZ --- F5 (L3 enabled)
    
     | (INT)    |
    
     |    Transit Network
    
     |      | (EXT)
    
     |     UAG
    
     |      | (INT)
    
     Transit Network
    
        |
    
      Core Router --- LAN2
    
        |
    
       LAN1
    

    Using the above layout would require UAG having a route for the internal network set on the internal interface. If this route is missed, then UAG will forward the backend application request over its external interface (default gateway). In addition to that you have to keep an eye on connection from internal clients accessing the F5 virtual server / UAG external IP. If both the ASA and the F5 forwards the original client IP address, then you may run into trouble since UAG would receive "internal" source IP addresses on the external interface (spoofing). So you have to SNAT those specific connection either on your ASA or F5 (iRules can selectively SNAT based on client source addresses). The SNAT will be used as anchor points to remeber the responce path of the packets, so on this way the UAG would know to repond those using the external interface although its an internal client^^

     

    Well, to find your specific problems i would recommend to use pen/paper and create a packet flow network diagram for the releated request and responces. The you have to check your entire configuration if it complies with the diagrams you've created.

    Edith: Damn the forum doesn't allow formated ASCII paintings. The external UAG transit network should be connected to F5.

    -Kai




    • Marked as answer by Erez Benari Friday, August 26, 2011 10:32 PM
    Saturday, August 13, 2011 8:33 AM

All replies

  • Hi Rob,

    UAG do always act as a "full proxy" when publishing web applications. So i belive the asymetric routing issue does have some other reasons.

    But UAG doesn't always assign the internal IP address as source. It strongly depends on the routing table of the local machine. The interface with the best path will be the source IP. Because of that its important to know which IP adress you will see on the backend application (using NETMON or NETSTAT-N will show half-opened sessions).  

    -Kai

    Friday, August 12, 2011 10:24 PM
  • Thanks for your response Kai.  I believe I understand what you are saying.  Without going to much more detail of our config yet...is there a way to force the UAG to always assign its internal IP as the source IP for all requests it sends to internal app server?
    Saturday, August 13, 2011 2:16 AM
  • Hi Rob,

    there isn't a specific option to "force" this behavior. All you can do is to configure UAGs routing table to make this happen. The UAG access to your backend application have to be forwarded on the internal interface, and the backroute to your UAG have to follow exactly the same path (symetric routing).

    In most of the dual homed and F5 loadbalancing scenarios i've seen so far the symetric routing configuration is a challaging thing and most of the time you'll need a well thought routing infrastructure and also "some" Source NAT in place to make it fully functioning.

    Imaging the following scenario...

     

    INET
    
     | (EXT)
    
    ASA --- DMZ --- F5 (L3 enabled)
    
     | (INT)    |
    
     |    Transit Network
    
     |      | (EXT)
    
     |     UAG
    
     |      | (INT)
    
     Transit Network
    
        |
    
      Core Router --- LAN2
    
        |
    
       LAN1
    

    Using the above layout would require UAG having a route for the internal network set on the internal interface. If this route is missed, then UAG will forward the backend application request over its external interface (default gateway). In addition to that you have to keep an eye on connection from internal clients accessing the F5 virtual server / UAG external IP. If both the ASA and the F5 forwards the original client IP address, then you may run into trouble since UAG would receive "internal" source IP addresses on the external interface (spoofing). So you have to SNAT those specific connection either on your ASA or F5 (iRules can selectively SNAT based on client source addresses). The SNAT will be used as anchor points to remeber the responce path of the packets, so on this way the UAG would know to repond those using the external interface although its an internal client^^

     

    Well, to find your specific problems i would recommend to use pen/paper and create a packet flow network diagram for the releated request and responces. The you have to check your entire configuration if it complies with the diagrams you've created.

    Edith: Damn the forum doesn't allow formated ASCII paintings. The external UAG transit network should be connected to F5.

    -Kai




    • Marked as answer by Erez Benari Friday, August 26, 2011 10:32 PM
    Saturday, August 13, 2011 8:33 AM