The most difficult part of this is how to convey my question briefly. We are running ASA 8.2(4)1 in a production IPSec VPN L2L environment. We are running ASA 8.2(1) in a production SSL AnyConnect environment. Both devices have inspect SQLnet enabled globally. Basic SQLnet applications have been performing without issues. Recently we have introduced an Oracle product that allows load balancing using DNS. This application, if that is what we should call it, performs correctly over SSL 8.2(1) but misbahaves over IPSec VPN tunnels 8.2(4)1. In the packet captures I have of the 8.2(4)1 firewall I see the real address imbedded in the packets returning to the client at the client workstation. The client takes this information and tries to connect on the real IP and of course the connection will timeout (SYN timeout). So we assume it is a NAT issue which should be fixed up by inspect SQLnet? This does not seem to be the case with SSL 8.2(1) code.
My first question. Do I downgarde to 8.2(1) code or upgrade to 8.2(5)22? With change control the way it is it could be months before I get a second chance!
I have packet captures from the internal network, from the client and from the inside interface of most of the firewalls that I will share if you wish. Just let me know.
It won't be nice to say in first place that you may be hitting some bug on 184.108.40.206. But i recall there was similar SQL issue on forum while ago and it turned to be a bug on 220.127.116.11 which was fixed in 18.104.22.168. Unfortunately i don't have that bug id handy else would have referred and shared with you.
Since you would be going through a change control and second chance won't be too soon for you. I would like to place a generic recommendation. Do upgrade the code to 22.214.171.124 or later (as you mentioned 126.96.36.199)? At the same time see if you can upgrade the code on SSL ASA too, as 8.2.1 is not a reliable code, has lots of bugs carried from 7.x and 8.0 release.
With the upgrade your issue may get resolve. Still suggest you to take a second opinion from TAC as they might have seen this issue with other customers too.
The Bugs just don’t seem to fit the problem but your comments are helpful. Yesterday the application folks found an issue in their configuration file and relayed to me that the issue is with both SSL and IPSec. So I am regrouping.
We are having the same issue and we have setup as yours ASA Site to Site running 8.2(4)1. I found that there was a bug (CSCta03382) in 8.2.1 for sqlnet but that was fixed in 8.2(4)1. Could you tell us, what was the fix for your issue (now my issue)?