Forum Discussion

coda6_52611's avatar
coda6_52611
Icon for Nimbostratus rankNimbostratus
Aug 28, 2015

Virtual Server sending resets to the client and the node.

Running a 10.2.4 LTM, had a working dev environment for Asset Suite. App admins upgrade Asset Suite, finally, to address POODLE and all the other recent vulnerabilities out there. Post upgrade, they could authenticate to the app, but then they would get a "Page could not be displayed" message from IE and various other errors depending on which browsers you use.

 

We successfully fought through certificate issues and got all of that stuff straightened out, but I still was getting the "Page could not be displayed" message after authentication. If we bypass the LTM, it works fine, so not an app issue.

 

This VS is a Standard load balance with a pool with two members, using source address persistence, SNAT AutoMap and a redirect iRule to ensure everyone is using the correct URI.

 

After a couple of tcpdumps, I saw the LTM sending RST packets to both the client and the nodes. I did a few devcentral searches and looked at some SOLs. I removed the iRule from play and had the same issue. I adjusted "Maximum Syn Retransmissions" in my TCP profile and looked anywhere else I thought there could be a reset option.

 

Finally I removed the HTTP profile from the VS and the app works, but you need to put in the whole URI. Problem is, the redirect iRule is a must have for my customer and I can't do that without an HTTP profile.

 

What in the HTTP profile could be causing these resets?

 

Thanks,

 

Ken

 

APM
application delivery
deployment
LTM
security
TMOS

5 Replies

Sort By
  • Amit_Karnik's avatar
    Amit_Karnik
    Icon for Nimbostratus rankNimbostratus
    Aug 28, 2015

    Is the protocol data coming into the connection http protocol compliant ? It may look like http but may not ?

     

    If the http-profile cannot parse the request, it may close the connection. However in this case I would expect that only the clientside connection gets reset. There should be no server side connection established till the request gets parsed.

     

    cheers.

     

  • coda6_52611's avatar
    coda6_52611
    Icon for Nimbostratus rankNimbostratus
    Aug 28, 2015

    The protocol is SSL, with certs in place. The build was working before a code upgrade.

     

  • Amit_Karnik_269's avatar
    Amit_Karnik_269
    Icon for Nimbostratus rankNimbostratus
    Aug 28, 2015

    Since the code-upgrade was on the app, and you get the resets after logging-in, I suspect that a certain http request may not be compliant.

     

    Also take a look at the profile, there are some limits.. for e.g. of headers, max header value, etc.

     

    If you are terminating SSL, you can use tcpdump and the key file to decrypt the traffic (you may have to downgrade the cipher temporarily). Then inspect the http request just before the resets and check if that has any offending content/issues.

     

    Also other app related issues, such as cookies, etc. might be in play too. For e.g. if the app uses Java and the cookie set by the App is not set correctly to allow access to JVM only the browser, but these debug steps can be taken after ruling out the basic http level issues.

     

    cheers.

     

    • Amit_Karnik_269's avatar
      Amit_Karnik_269
      Icon for Nimbostratus rankNimbostratus
      Aug 28, 2015
      ALso you mention about a redirect. Could you move that functionality from the http profile to an iRule ?
  • coda6_52611's avatar
    coda6_52611
    Icon for Nimbostratus rankNimbostratus
    Aug 28, 2015

    I'm bridging the SSL traffic so it's still encrypted on the back end, weak ciphers were part of the problems initially that we fixed with new certs and new root certificates. I'll have to try and import the key into wireshark.

     

    I am doing the redirect with an iRule, but I can't apply the iRule without an HTTP profile.