Forum Discussion

tiwang_122270's avatar
Icon for Nimbostratus rankNimbostratus
Mar 03, 2014

Using SSL offload and passing traffic through to internal webserver

hi out there


I have defined a vs - solely LTM (bigip 11.3) where I make use of SSL offload in the F5 and passing the http traffic through to a internal webserver. The intention was that we in phase one of this project get the frame for it up and run - the F5 should only take care of SSL offload and passing the traffic on to the internal server. But - The authentication fails - I have enabled basic authentication on the webserver (IIS7.5) and it replies nicely with a 401 which the first time is passed through to client on the outside of the F5. Afterwards it fails and I cannot really find out why. I have been using the standard http profiles etc - as much as possibly right out of the box. Eg.: my problem here is that the first time the client access the internal webserver the authentication runs correctly - but afterwards it is as if the authentication fails - the webserver writes 401 in the logfile.. Since it is SSL encrypted on the client side it is a bit hard to investigate in even thoguh I can see what we think we sends by dumping it out with tcpdump and decrypt with ssldump - but I am still not sure what is going wrong. Are there some common pitfalls here when we do a protocol-transition?


best regards /ti


5 Replies

  • tiwang's avatar
    Icon for Nimbostratus rankNimbostratus

    Hi again I spend some hours yesterday evening i digging around to see if I could get some ideas because - it should in fact be simple pass-through and nothing else in phase 1 - keep it as simple as possibly so that we can create a baseline and say - this works. When I added "the fiddler" on the client between the webclient and the F5 the problem disappered so it had something to do with the flow. Tried several combinations of the "chunking" setup in the http profile and ended up with "Request chunking" preserve and "response chunking" rechunk - and then "it" worked.


    I had another vs where the application on the webserver did build a nice table with really many fields - and this was also completely "screwed up" when we put the traffic through the F5 until we found the chunking settings...


    Well - can somebody explain to me - what is it with F5 bigip's, the chunking handling and Microsoft IIS? Pr. default there is something which is - if not incorrect then incompatible setup....


    Comments please...


  • Ti,


    Do you only have one web server in your pool? If so, could you please post your virtual server, pool, and client SSL profile configurations?


    • Cory_50405's avatar
      Icon for Noctilucent rankNoctilucent
      What is your HTTP class 'DK_FILE_vs' doing? Have you done packet captures between the LTM and the server? It sounds like the authentication could be timing out/expiring for some reason.
    • tiwang_122270's avatar
      Icon for Nimbostratus rankNimbostratus
      hi cory I have only webserve rin my pool (second isdisabled but was a test vm so it can be removed - just disabled it at first: ltm pool /dk_dmz/DK_FILE_pool { members { /dk_dmz/AE-REL-IIS-02:80 { address session user-disabled } /dk_dmz/AEWEB-03:80 { address description "Webserver for webapp dmz" monitor /dk_dmz/DK_ICMP } } monitor /dk_dmz/DK_ICMP } ltm virtual /dk_dmz/DK_FILE_vs { description "Virtual server for pass-through to File upload service" destination /dk_dmz/ http-class { /dk_dmz/DK_FILE_vs } ip-protocol tcp mask pool /dk_dmz/DK_FILE_pool profiles { /Common/tcp { } /Common/wildcard.adp.com_ssl { context clientside } /dk_dmz/DK_ADP_HTTP_Profile { } } security-log-profiles { "/Common/Log all requests" } source source-address-translation { type automap } translate-address enabled translate-port enabled vlans-disabled } ltm profile client-ssl /Common/wildcard.adp.com_ssl { app-service none cert /Common/wildcard.adp.com_2015.crt chain /Common/digicertca_chain_2022.crt defaults-from /Common/clientssl key /Common/wildcard.adp.com_2015.key }
  • Do you have persistence configured? It could be that for the initial request the client authenticates to server 1 but for the second request it is sent to server 2 and therefore authentication fails. Cookie persistence is the best to use as it does not require persistence tables.


    Have you done a tcpdump on the server side? Might be worth using the -p switch to tcpdump, and ssldump.