Forum Discussion

tiwang's avatar
tiwang
Icon for Nimbostratus rankNimbostratus
Jun 25, 2014

website a is referecing website b - how do I handle this on the ltm

hi out there I have a website published through ltm with a accesspolicy - website.com.dk - this is publishing the website web1.internal.local - in some of the pages there are references to another server - web2.internal.local Thes links can't be displayed - I need a few advises to get started on this problem. We are using a simpel irule to rewrite the URL's from website.com.dk to web1.internal.local (table lookup in a datagroup) best regards /ti

 

6 Replies

  • The first thing I'd ask is if web2 has an external LTM/APM interface? If it doesn't, then it wouldn't matter that the URLs are internal and unreachable. If it does, then you may consider using the same iRule to rewrite links to web2 (to its corresponding external LTM/APM URL). Not sure what your iRule looks like, but this is usually a matter of rewriting HTTP redirect Location headers and (if necessary) applying a STREAM profile on HTTP response traffic to rewrite links in the payload.

     

    An even easier option may be to simply use an APM portal configuration. All access to web1 and any internal references like web2 would be automatically rewritten to flow through the portal.

     

  • tiwang's avatar
    tiwang
    Icon for Nimbostratus rankNimbostratus

    hi kevin it is not published externally on the ltm/apm

     

    hmmm - apm portal solution? This is a special licensed option - isn't it?

     

    the irule we use simple takes and replaces the external with the internal url (uri):

     

    Code for the iRule DK_AE_IP_Based_VirtualHost:

     

    when HTTP_REQUEST { Log debug messages to /var/log/ltm? 1=yes, 0=no. set host_debug 1

     

    Need to force the host header replacement and HTTP:: commands into the clientside context as the HTTP_REQUEST_SEND event is in the serverside context

     

     if {$host_debug}{log local0. "[HTTP::host]: [HTTP::method] request to [HTTP::host][HTTP::uri]"}
    
       Look up the selected server name in the datagroup to get the right pool
      set pool_name_value [class match -value [HTTP::host] equals /dk_dmz/DK_AE_IP_pools_dg]
    
      if {$host_debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Looked up [HTTP::host], found: $pool_name_value."}
    
       Check if the lookup returned a value
      if {$pool_name_value ne ""}{
    
          Replace pool
         pool $pool_name_value
         if {$host_debug}{log local0. "[HTTP::host]: Replaced default pool with $pool_name_value."}
      }

    } Similar with the iRule for DK_AE_HostHEaderRewrite – here is the code:

     

    when HTTP_REQUEST_SEND { Log debug messages to /var/log/ltm? 1=yes, 0=no. set host_debug 1

     

    Need to force the host header replacement and HTTP:: commands into the clientside context as the HTTP_REQUEST_SEND event is in the serverside context clientside {

     

     if {$host_debug}{log local0. "[HTTP::host]: [HTTP::method] request to [HTTP::host][HTTP::uri]"}
    
       Look up the selected server name in the datagroup to get the host header value
      set host_header_value [class match -value [HTTP::host] equals /dk_dmz/DK_AE_host_rewrite_dg]
    
      if {$host_debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Looked up [HTTP::host], found: $host_header_value."}
    
       Check if the lookup returned a value
      if {$host_header_value ne ""}{
    
          Replace the host header value
         HTTP::header replace Host $host_header_value
         if {$host_debug}{log local0. "[HTTP::host]: Replaced Host header with $host_header_value."}
      }

    } }

     

  • Okay, so here's the thing. If web2 does not have an external LTM/APM representation, then it shouldn't matter that the client gets internal links to these URLs, because it couldn't get to it anyway. You'd have to first create an LTM VIP for web2, and then try to rewrite the content passing through.

     

    APM portal does consume a "concurrent" or "CCU" license, so yes, that is technically a special licensed option.

     

    The only thing you appear to be doing is rewriting the Host header on ingress request. Does that work? I was under the assumption here that the internal application was passing internal URLs to the client?

     

  • tiwang's avatar
    tiwang
    Icon for Nimbostratus rankNimbostratus

    hi kevin yes this Works fine - we first apply ip_based_virtual_host irule to assign the pool and then we run the hostheaderewrite irule to - well - rewrite the hostheader in the url now you must be patient with me - I am not that web-neard so I am not so I might not get the question correctly always ;-) Most of the application runs on the client side - it builds in fact a sql statement which is fired and filled into tables etc on the client - it is therefore it is that important for us to have published from the F5 so that we can run it through the ASM module after the SSL.

     

    But you say that if we in fact published it from a APM portal and not just used the apm module to get a logon screen to fetch credentials this would be published correctly - can't you send me a link to this because this could be a way to go instead. How about integration with local office applications on the pc (eg.: permit access to a ms datapump from a ms sql cube - think this is some sort of rpc over https but cannot remember it)

     

  • tiwang's avatar
    tiwang
    Icon for Nimbostratus rankNimbostratus

    ps: regarding the publishing of web2 on the ltm - do we get some variables with which we could use to apply as acl on the fly? it was in fact not the intention that this webserver should be that public avalibly... if we get the ip adresse of the client is it then possibly to define a irule which applies those as acl for the portal so that I could "Lock it Down" and only open dynaically for those client referencing it from web1?

     

    best regards /ti

     

  • First, the APM portal feature is for web-based communications. It's highly unlikely that the RPC-over-HTTPS stuff would work. The main idea with a portal is that it rewrites links. Think of a typical HTTP request and response. The client does a GET or POST to a specific URL, and that URL responds with a bunch of HTTP headers and an HTML document. Inside that document you'll usually find a bunch of external references to other objects (images, CSS, JavaScript, etc.) that the browser client will dutifully fetch before rendering the page to the user. So there are TWO places where a server can implant URLs: HTTP headers and the HTML document. The APM portal will look through all of this data, find these URLs, and then rewrite them to values that force all subsequent requests through the same VIP. So for example, let's say you have an APM portal at portal.mycompany.com. That sits in front of an application, and that application sends back references to itself and another internal URLs in HTTP headers and the HTML payload.

    img src="http://internal.domain.local/images/my_cat.png" 
    

    will get rewritten to something like

    img src="https://portal.mycompany.com/f5-w-1234564334565/images/my_cat.png"
    

    If the server spits out URLs for different servers inside the environment, APM portal will automatically rewrite those as well. This is one way to handle URL rewriting and requires no iRules, but as you mentioned earlier, it does incur a different licensing model. This, by the way, would automatically make web2 externally accessible (though you can block it).

    In some cases you can get away with similar functionality with an iRule to 1) replace Host headers, 2) replace redirect Location headers, and 3) replace URLs in the response payload. Oddly it seems the only thing you need to do is to replace the Host header in the request, so you may not have to go through all of this trouble. The question then becomes, what do you want to do with the web2 URL references? If web2 isn't intended to be externally accessible, then the incorrect links should be fine. If you want web2 to be externally accessible, then you either need to do the APM portal thing, or create a separate LTM VIP for web and rewrite URL references to web2 in the HTTP responses to point web2 traffic at that VIP.