Cisco PIX Firewall blocks packets

[dan_track]

Hi

I have a cisco pix 515E firewall, I'm experiencing a strange problem, and I'd like to get people's ideas as to what it could be and what debugging I can do.

Basically the problem is that randomly from two different unrelated servers some SYN packets to port 1521 are being dropped by the firewall, and as a result I'm getting TCP timeouts. I found this by port monitoring and using tcpdump on the external firewall interface and internal firewall interface. I could see packets coming into the external connection but they aren't coming out from the internal connection. These connections are all to the oracle database which is listening on port 1521.

The firewall at the moment is allowing all connections through to any port. I have some fixup rules in the config one of them is for the port 1521. I've removed that particular fixup but it hasn't made any difference to the problem.

From those servers I don't get any problems to any other port, the problem only exists to port 1521.

Can someone please help give me ideas about this.

Thanks in advance

Dan

[Deft]

.

[Deft]

Hey Dan. Have same situation with PIX 7.1.1 too. See my conversation with expert at http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Expert%20Archive&topic=Security&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dda901e/93#selected_message

Will try to debug...

We can talk by ICQ about 1521 problem if you want:) 108879415

[jogillis]

What is your connection timeout value. If it is high or "0" (no timeout), check and see if you have old connections between the host involved. If so clear the connections and see if the problem goes away.

Also what did you mean by using "port monitoring" to collect info.

jogillis

[dan_track]

Hi jogillis

Thanks for the reponse. Here's my timeout values:

timeout xlate 3:00:00

timeout conn 0:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

I hope this helps. I've been scratching my head for a week now trying to solve this.

Thanks again

Dan

[jogillis]

Dan,

I see you have connections set to not timeout. Did you check for old connections?

show conn | include

I had your exact scenario with our sql server, requests go into the pix but never come out. We also have connections set to never timeout. I used the caputure command on both interfaces to get my trace, then using the port numbers from the capture I discovered old connections with those same port numbers. Of course if you pix is restarted very often then this is a mute point.

jogillis

[dan_track]

Hi

Just to add evidence to my theory, I get the following in my logs:

Mar 17 17:15:58 fwl-inside-pri Mar 17 2006 15:48:00: %PIX-6-302014: Teardown TCP connection 21835588 for green:10.110.9.122/53488 to data:10.10.8.22/22 duration 0:02:01 bytes 0 SYN Timeout

However the above logs don't account for every timeout, that I have seen.

Any idea how to fix this?

Thanks in advance

Dan

[dan_track]

Hi

Just to add further evidence:

By sniffing the network on the pix external facing network interface I receive packets similar to this:

19:49:15.758315 red.example.com.44808 > green.example.com.1521: S

3506603012:3506603012(0) win 5840

ale 0> (DF)

But sniffing the internal facing interface (i.e the database end), those packets don't come through. Its as though the pix has silently dropped them.

Now so far from my tests, I've noticed that a failure has always been occurring when the mss value is set to 1460. Although this might be a red-herring as trawling through the capture logs I can see other SYN packets pass through with that value. Setting the "sysopt tcpmss" value to 1460 doesn't make any difference.

Any ideas where the problem may lie?

Is this a bug in the cisco OS?

Thanks

Dan

[tphan]

Hello Dan,

Just wondering if you've solved this problem with Oracle yet? I'm running into the same issue and so far are having no luck.

I installed the pix with v7.2(1) with a wide open (no restrictions) configuration and no NATs (enabling traffic to pass without NAT). All traffic works except for SQL*Net port (1521). Curiosly though, TNSPings and telnet using port 1521 works. As soon as a user issue a sql "connect" command, it would hang and timeout.

When I pull the pix out and revert to our router, everything works as normal. Any insights to this would greatly appreciated.

Thanks

Thomas

[amohabir1]

Are you nat'ing. Did you try a one to one static ip mapping?

[tphan]

No, I was hoping not having to NAT. We're not using the PIX for the internet, but rather as a security device to separate our 2 internal networks. Anyhow, since it is all internal, I'd prefer to stay away from NAT. Is NAT required in order to use SQL*Net Inspection? It just doesn't make any sense...

[amohabir1]

Are those servers in the inside and are you letting external clients connect to it?

[tphan]

From the Pix standpoint, network A having security level 100 and network B having security level 50. One of the scenario is Oracle client on Network B trying to "connect" to Oracle Server on network A. No NATs configured. Access-lists are configured to allow all ports bidirectionally. The Pix is configured just like a router, with access-lists allowing all traffic.

[siennax]

Hi,

Is there already a solution for this problem. I think we have the same issue, we have a pix between the application server and oracle. Where running pix 7.2.1 and see that queries to the database are rejected without any logging in the pix. I disabled the inspect rules for sqlnet, but no solution. When we directly connect the database in the same subnet as the application server we have no problem. Also connections through the pix with tools like DBvisualiser/tora are dropped?

Jeroen.

[rsmith]

I don't know if it is related, but we had an issue with HTTP, and the MSS value exceeded being dropped silently. We added the following lines to allow MSS values exceeded, and traffic flowed correctly. This should work with any TCP traffic. You may want to lock this down further with ACL's ("match any" line)as there are some security concerns with MSS exceeded packets. Hope this helps.

tcp-map mss-map

exceed-mss allow

class-map http-map1

match any

policy-map global_policy

class http-map1

set connection advanced-options mss-map