PIX V8.04 Update - Sqlnet Problem

[r.bender]

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?

Thanks.

[jghope]

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

[Michael.Tuggle]

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]

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.

Regards

peter

[Michael.Tuggle]

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

Mic,

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

Regards

Peter

[franklinb]

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]

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

Regards

Peter

[jaylakhani]

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?

thanks,

[franklinb]

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]

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

Thanks

[whhtnetwork]

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]

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.

[whhtnetwork]

can you please tell me which version fixed the preoblem , Thanks

[r.bender]

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.

[whhtnetwork]

It means 821-K8 will work with SQL inspection ON.