After upgrading our PIX 515E from V7.22 to V8.04 everything but one protocol seems to work fine. When trying to make an Sqlnet connection through the firewall a syslog error is kicked out: "PIX-4-507001: Terminating TCP-Proxy connection from outside:x.x.x.x/1534 to inside:y.y.y.y/2778 - reassembly limit of 8192 bytes exceeded". A packet capture shows the client and server talking, even after the error.
Anyone seen this before?
When sqlnet inspection is applied as in your case, the ASA will proxy the TCP stream to make
sure the traffic arrives in order. When performing this, the firewall must buffer any
fragmented packets, but only have a limited size buffer of 8192 bytes. It is this limit
that is being hit in your case.
There is currently a feature request to have this limit changed, but at this point it is
just a request.
As a workaround, you can try disabling the inspection for this particular server.
ASA-5520-CSC-Standalone(config)# access-list sqlnet-list deny tcp any host 22.214.171.124 eq
ASA-5520-CSC-Standalone(config)# access-list sqlnet-list permit tcp any any eq 1521
ASA-5520-CSC-Standalone(config)# class-map sqlnet-class
ASA-5520-CSC-Standalone(config-cmap)# match access-list sqlnet-list
ASA-5520-CSC-Standalone(config-cmap)# policy-map global_policy
ASA-5520-CSC-Standalone(config-pmap)# class inspection_default
ASA-5520-CSC-Standalone(config-pmap-c)# no inspect sqlnet
ASA-5520-CSC-Standalone(config-pmap-c)# class sqlnet-class
ASA-5520-CSC-Standalone(config-pmap-c)# inspect sqlnet
Do rate helpful posts.
I am looking at upgrading from 7.2.4 to 8.0.4 and was wondering if you were just recieving the syslog messages or if it was killing your connections between the client and server. Also did you find a fix? Any input would be helpful.
When we upgraded to 8.0.4 we had to disable the sqlnet inspect because it was impacting connectivity. There is no fix for this at the moment that I am aware of.
I was getting syslog messages until I applied V8.0(4)3. This interim patch stopped the syslog errors and helped the commuincation a little but the the connection still did not function properly. The firewall appeared to be sending resets and killing the traffic. Cisco has indicated the this will be fixed in V8.0(4)6 but did not know when it would be released. I keep checking. For now I have rolled back to the known working V7.22.
You can try disabling the rtsp inspect.
Please refer to below URL:
Does the ASA have the same problem. We have the ASA 5520 and I know there is a good bit of differences between the ASA OS and the Pix OS even if they are running the same version.
Looks like we are hitting the same problem on a PIX running 8.0.4. Any news on the release date for 8.0.4(6)? I will try to apply the workaround this weekend.
No news. They closed the case and told me to keep checking their website for the Interim release as they did not have a date for the release. It was still in the testing stages. So far it has not been released and I check the site every week. Please let me if you find a work around that works.
Leveraging my advanced services contract I was just able to obtain a copy of asa804-6-k8.bin today which is supposed to resolve this issue.
I'd hit up TAC again and escalate this through the system until they give you access to the interim release as well I guess.
I did not know you could do that. If you are going to apply the update please let me know if it seems to fix the issue. That will save me some time. ;-)
Just to let you know I performed the update this weekend and ran into the same SQL-NET inspection issue with the ASA. Like everyone else disabled SQL-NET inspection to resolve the issue.
I am about upgrading our PIX from 7.0(4) -> 7.2x - 8.0x but afraid of the issues discussed on this subject. Do you advice that I go ahead to 8.0x or just upgrade to 7.2x and wait until these issues are resolved.
Basically the work around is to turn off SQLNet inspection. This worked with no problem in our environment. Cisco has released an interim fix for the issue, 126.96.36.199. I am not applying the fix but am waiting until 8.0.5 is released, which Cisco assured me will contain the fix. Cisco did not give a specific time for the next release but said it would probably be in the next couple of months. I would say unless you are looking at something specific to 8.0x code, like a SSL VPN feature, EIGRP, etc.., I would hold off on upgrading to 8.0x until 8.0.5 is released. I had 7.2.4 before the upgrade and it seemed to be a very stable release. I will say the SSL VPN features in 8.0 are far better than 7.X code. Any way good luck with whatever you decide.
I wish I'd seen this before upgrading mine! I did so 2 weeks ago but only recently was the issue discovered. I found that site relating to RTSP and just did the same thing for SQLNET and disabled the inspection. I still haven't read anything that explains why the previous version could do it fine and not this one?
I'll wait for 8.0.5 before re-enabling inspection.
Thanks for your advice. I braved upgrading the PIX through ver7.04->7.24->8.04 and all seems to be working fine. I had a few issues with sqlnet which did not work after upgrade to 8.04 but had to turn off sqlnet inspection on the firewall. Will wait for the 8.05 before enabling that again. Thanks once again for this post. It gave many forum members an insight and caution before going ahead with upgrade.
It worked ok afterwards
Thanks, this is a very useful post. I have the same problem and seems like for a quick fix I would need to remove sqlnet inspection... however I am unsure if any other applications will break if I was to remove sql net inspection... any thoughts?
I have disabled inspection because we have a separate IPS for this role. Even without this it will not break traffic, it will just mean the PIX/ASA is not doing deep packet inspection - the traffic will still get through.
ok, thanks. I thought it inspect keeps track of the connections and opens / closes ports as needed for that connection.
As far as i Know Sql Inspect is used for special application handeling like Ftp data stream goes out on one port and listen back on different port, to handle thesetype of applications responce we need inspect.
As already discussed on the forum that disabling sql inspect is workaround but my main consern is this after disabling Sqlnet will ASA being able to do application handling
Thanks for the reply. I should cloes this out as we have replaced the PIX unit with an ASA which works fine. You are correct that the SQL inspect works like FTP in that it "listens" to the conversation as some SQL TCP conversations change to higher port numbers on the fly. This is what caused our problem. 2 of out 4 of our SQL conversations had this issue. I am not sure what makes the SQL communication work like this but I am guessing it is the driver as the ones that did not change ports were unix to unix communication and the oones that did not were Windows to Unix via an Oracle driver. Anyway, we have moved on. Thanks.