PIX V8.04 Update - Sqlnet Problem

Unanswered Question
Sep 23rd, 2008

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?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
suschoud Tue, 09/23/2008 - 13:07

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 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.



Michael.Tuggle@... Fri, 10/03/2008 - 07:18

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.

Matthew Warrick Fri, 10/03/2008 - 07:31

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.

r.bender Sat, 10/04/2008 - 21:14

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.

Michael.Tuggle@... Tue, 10/07/2008 - 07:53

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.

r.bender Tue, 10/07/2008 - 09:33

I do not know. I have not tried this with the ASA. I hope to when I get a chance. If you test this please let me know.


Michael.Tuggle@... Thu, 10/09/2008 - 04:50

We are planning our upgrade at the end of the month so I will post the sqlnets results at that time.

jghope Thu, 10/09/2008 - 06:32

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.

r.bender Thu, 10/09/2008 - 08:57

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.


Matthew Warrick Thu, 10/09/2008 - 12:20

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.

Good luck!

r.bender Thu, 10/09/2008 - 12:38

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. ;-)

Matthew Warrick Thu, 10/09/2008 - 12:49

Will do, however it takes about 2 weeks to get the approvals to get it into production around here lol.

jghope Thu, 10/16/2008 - 23:51

The workaround worked fine - had to tweak an access rule as well. Will go for the software update as soon as possible

Michael.Tuggle@... Mon, 10/27/2008 - 05:51

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.

peteruwa Wed, 10/29/2008 - 07:07

Hi Mic,

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.



Michael.Tuggle@... Wed, 10/29/2008 - 07:35

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, 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.

peteruwa Wed, 10/29/2008 - 09:04


Thanks for the advice. I think I will go with the 7.2.4 and wait as suggested.



franklinb Mon, 11/03/2008 - 22:39

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.

peteruwa Tue, 11/04/2008 - 06:03

Hi Mic

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



jaylakhani Wed, 12/10/2008 - 16:40

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?


franklinb Wed, 12/10/2008 - 16:45

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.

jaylakhani Wed, 12/10/2008 - 20:03

ok, thanks. I thought it inspect keeps track of the connections and opens / closes ports as needed for that connection.


whhtnetwork Tue, 10/13/2009 - 00:47

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

r.bender Tue, 10/13/2009 - 05:51

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.

r.bender Tue, 10/13/2009 - 06:19

The first one we used was asa804-32-k8.bin and it worked fine. We are currently using asa821-k8.bin and it works fine as well.


This Discussion