Cisco ASA 5520 ver 8.3(1) problem with web server connection time-outs and TCP Reset-I

Please advise on how we can improve this situation.  We are migrating from a PIX to the ASA listed above, and have found that client queries to a Public Internet web database are considerably slower.

Queries would take 30 seconds to run accessing through the PIX, but were around 2.5 minutes through the ASA.  Each device is attached to a different ISP, but I don't believe that to be the error as from the average consumer ADSL connection the query also takes 30 seconds.  Googling the error brought up some information regarding low webserver timeout values, and the failure of the ASA to send a RST to the internal clients.  I configured the ASA to send RSTs to inbound and outbound connections on the "inside" interface, and that brought the database query time down to 1 minute!

I would like the time to be close to the usual 30 seconds as the customers are quite vocal!  Is there anything that can be configured to help?  I have posted the log from the one minute query.  The query completed at 18:22:11.

Thank you in advance for your help.
Who is Participating?
Pete LongConnect With a Mentor Technical ConsultantCommented:
Are these database queries?

Try adding the norandomseq to the end of the Database static translation e.g

static (Inside,DMZ1) Database_Server Database_Server netmask norandomseq

also I've seen this exact problem going from PIX to ASA - In my case it was the switch port having an autonegotiation error - I had calls logged to Cisco TAC and all sorts.

as a test lock the speed and duplex like this - any difference? (note this assumes you have an ASA that isnt a 5505 if yours is then this is set on the Vlan)

interface Ethernet0/1
 speed 100
 duplex half
 nameif Inside

support_ferretAuthor Commented:
Thank you for your reply  - yes these are database queries via https.

It appears I was hasty as now the times are back up to just over 1:30.  I also realised that I wasn't clear with my description - the database web server is a public server on the Internet, rather than one of ours serving public clients.

I will look at the port settings tomorrow.  I remember the public interface had to be fixed for the ISP, but haven't looked at the "inside" interface.

I did find an article where someone had this problem, but with a PIX.  The answer for them was that the behaviour is expected and the web server should close the connections properly!  Is it possible to configure the ASA to "pass" the traffic from the remote web server, avoiding the dropping of the RSTs, or can I tune the web clients on our internal network not to hold the connection open for as long?
support_ferretAuthor Commented:
I fixed the duplex and speed of the inside interface to "full" and "1000" as it is a gigabit network.  It has not made a difference so far.  The outside interface is set to "full" and "100".  I am thinking about calling the company thta owns the remote web server, although I doubt whether they will reconfigure their setup just for us.  What do you recommend?
WEBINAR: GDPR Implemented - Tips & Lessons Learned

Join the WatchGuard team on Thursday, March 29th as we recount some valuable lessons learned in weighing the needs of a business against the new regulatory environment, look ahead at the two months left before implementation, and help you understand the steps you can take today!

support_ferretAuthor Commented:
I noticed we did have an auto-negotiation error with the inside interface when I set it to 100Mb/s.  I have manually set now on switch and ASA to 100/full.  The problem remains however.  

Any ideas on the right direction?  I played around with http inspection but all that came of it was that the traffic was reported as a protocol violation.
support_ferretAuthor Commented:
I found an article indicating that the absence of a reverse-lookup DNS record for the ASA public IP address can cause this kind of issue.  We do not yet have one so I have requested, and will let you know the outcome.
support_ferretAuthor Commented:
I would like to accept the solution - it was a long time in the making so sorry for the delay.
QlemoBatchelor and DeveloperCommented:
If you want to do otherwise than recommended by me, just post and press "Object" instead of "Submit". After that, feel free to award points, accept your own answer(s) or delete the question as you see fit.

Cleanup Volunteer
support_ferretAuthor Commented:
objecting and awarding points
support_ferretAuthor Commented:
Sorry for the delay.  In the end, it was a speed mismatch, but on the outside interface that was connecting to the ISP's router.  The ISP had changed their port to negotiate 1000Mbps, so we had to change ours to match.

Thanks for your help!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.