Please assist with question about a CSS

[dagates]

We have a server segment behind a CSS. The CSS is the default gateway for the servers. The servers do establish connectivity to a mainframe on the other side of the CSS. There are no content rules on the CSS for this connectivity nor is there any nats involved. The CSS is just acting like a router (as I understand it).

The server/application teams are reporting that the connection between the servers and mainframe are timming out.

Keeping in mind that there are no rules or services on the CSS involved in the communication, could the CSS drop the connection based on a timeout? Is there a global timeout setting on the CSS? Is there a such thing as a bypass configuration?

This is way deeper than my knowledge. If there is doc that covers this please let me know?

[Gilles Dufour]

all traffic going through a CSS will use a FCB [flow control block].

This is a block of info used by the CSS to decide weither to nat or not and how to forward the traffic.

All FCB are subject to idle timeout.

Once a FCB is deleted, the CSS loses the info necessary to make the forwarding/nating and it will drop packets.

Since this traffic is simply routed, there is no content rule to catch the traffic and change the flow-timeout-multiplier.

So, you should try to set the port used by the application as a permanent port with the command 'flow permanent port1 '

Let me know if this solves your problem.

Gilles.

[wsyed]

I have a somewhat similar issue. I have a web server behind a CSS which is behind a PIX.

So the layout is :

Internet -> Router -> PIX -> CSS -> Webserver

All users from outside and the users on our local LAN can hit the site. But for some users when they try to login to the site sometimes it works and sometimes they just cannot login. Most of the time they cannot login. There are no rules defined for this site on the CSS, so the traffic is just passing through the CSS

On the CSS when I check " sh flows " I notice that when the user hits the site, i see an entry for him but it stays there for hardly a few seconds and disappears and although the web page is open on the users browser when the user enters the username and password it hangs and the user cannot log in. And I see no connections on the CSS. On the other hand maybe 1 out of 10 times, when the same user hits the site , I can see the connection on the CSS and it stays there and does not disappear. The user can then login and browse the site fine at blazing speeds. And while the user is browsing I can see multiple connections for him on the CSS.

Why is the CSS just randomly dropping the connection most of the times. This is happening for quite a few customers and internal users and is affecting business.

Any help would greatly be appreciated.

Thanks,

Syed

[Gilles Dufour]

if you do a 'show dos' do you see any entry ?

The only thing that come to my mind, is asymetric traffic.

Could you capture a trace of a client having a problem on the backend and frontend side of the css.

Gilles.

[wsyed]

show dos , shows 50 DoS Attack events, the current one being just one hour ago. Could you please tell me how do I clean it up and prevent it from attacks.

I've pasted some output below:

CSS11150# sh dos

Denial of Service Attack Summary:

Total Attacks: 137564

SYN Attacks: 132,455 Maximum per second: 35

LAND Attacks: 0 Maximum per second: 0

Zero Port Attacks: 0 Maximum per second: 0

Illegal Src Attacks: 5,109 Maximum per second: 17

Illegal Dst Attacks: 0 Maximum per second: 0

Smurf Attacks: 0 Maximum per second: 0

First Attack Detected: 05/22/2007 00:56:45

Last Attack Detected: 07/09/2007 13:24:45

DOS Attack Event 1:

First Attack: 07/09/2007 06:09:48

Last Attack: 07/09/2007 12:30:50

Source Address: 74.x.x.x

Destination Address: 192.168.x.x

Event Type: SYN Attack Total Attacks: 12

DOS Attack Event 2:

~First Attack: 07/09/2007 11:02:41

Last Attack: 07/09/2007 12:41:04

Source Address: 64.x.x.x

Destination Address: 192.168.x.x

Event Type: SYN Attack Total Attacks: 9

DOS Attack Event 3:

First Attack: 07/09/2007 12:00:29

Last Attack: 07/09/2007 12:36:23

Source Address: 66.x.x.x Destination Address: 192.168.x.x

Event Type: SYN Attack Total Attacks: 3

DOS Attack Event 4:

First Attack: 07/09/2007 12:09:09

Last Attack: 07/09/2007 12:40:27

Source Address: 209.x.x.x

Destination Address: 192.168.x.x

Event Type: SYN Attack Total Attacks: 2

DOS Attack Event 5:

First Attack: 07/09/2007 12:21:50

Last Attack: 07/09/2007 13:05:58

Source Address: 70.x.x.x Destination Address: 192.168.x.x

Event Type: SYN Attack Total Attacks: 5

DOS Attack Event 15:

First Attack: 07/09/2007 12:53:34

Last Attack: 07/09/2007 12:55:06

Source Address: 192.168.x.x Destination Address: 216.x.x.x

Event Type: SYN Attack Total Attacks: 5

[wsyed]

I did a traceroute on the CSS first to my machine internally which works, and then to another machine internally which does not work. The CSS can ping both machines. Both machines are on the same subnet.

SUCCESSFUL:

CSS11150# traceroute 10.1.51.70

Traceroute:

traceroute to 10.1.51.70 from 10.101.1.1 30 hops max, 40 byte packets

1 TTL: 0 ms 0 ms 0 ms From 10.101.1.2

FAILED:

CSS11150# traceroute 10.1.51.81

Traceroute:

traceroute to 10.1.51.81 from 192.168.1.10 30 hops max, 40 byte packets

1 TTL: * * *

2 TTL: * * *

3 TTL: * * *

4 TTL: * * *

5 TTL: * * *

6 TTL: * * *

7 TTL: * * *

8 TTL: * * ♥

--Cancelled--

I've pasted the ip routes below:

CSS11150# sh ip routes

prefix/length next hop if type proto age metric

------------------ --------------- ---- ------ -------- ---------- -----------

1.1.0.0/16 1.1.1.101 2 mgmt local -- --

0.0.0.0/0 10.101.1.2 1019 remote static 1432999 0

0.0.0.0/0 192.168.1.1 1017 remote static 863275 0

10.100.40.0/24 10.100.40.1 1021 local local 4199510 0

192.168.0.0/24 192.168.0.1 1018 local local 1526642 0

192.168.1.0/24 192.168.1.10 1017 local local 4196983 0

[Gilles Dufour]

I was actually talking about a sniffer trace.

Not a traceroute.

We want to verify if the traffic bypasses the CSS on the way in or on the way out.

The DOS SYN attack indicates that the CSS did not see a response a SYN within 16sec and it removed the flow.

So, if the SYN/ACK bypassed the CSS because it took an asymetric route, then you see this kind of issue.

You need to guarantee that the response comes back through the CSS.

If necessary, nat outgoing traffic with a source group.

Gilles.

[wsyed]

In the traceroute, why is the traffic from the same LAN segment going to different interfaces of the CSS.

In the first one it goes to the 10.101.1.1 interface.

In the second traceroute it goes to the 192.168.1.10 interface.

All the internal machines routing through the second interface of 192.168.1.10 are having problems.

Do the IP routes look ok to you.

[Gilles Dufour]

you have configure 2 default routes :

0.0.0.0/0 10.101.1.2 1019 remote static 1432999 0

0.0.0.0/0 192.168.1.1 1017 remote static 863275 0

So the CSS is sending one connection to the first default route and another connection to the other default route.

Make sure these are true default routes. In other words, make sure you can connection to every location using any of these routes.

Gilles.

[wsyed]

Any clue as to why 2 machines on the same LAN have different traceroutes.

Also is there a way to completely bypass the CSS.

How do I implement your suggestion i.e to nat outgoing traffic with a source group.