cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
709
Views
0
Helpful
6
Replies

IOS IPS problem

edison9114
Level 1
Level 1

I have a 3825 running 12.3(14)T4. On my serial port I have a T3/E3 card connecting to an MPLS cloud with about 40 sites and on my Gi0/1 port I have a SonicWall VPN concentrator connected to approx 200 sites. My servers are located off the Gi0/0 port. Typical throughput through the router averages about 2.0 MB through the Gi0/1 port and about 10 MB through the serial port.

The router has 256MB of memory installed and about 128MB available. I am loading 64 signatures with all the signatures set to alarm only. All other signatures have been deleted.

After enabling IPS on the Gi0/0 outbound interface, everything works fine for several hours and then users begin complaining about a loss of connectivity. Users can’t connect to web sites nor can they log in to the AD and telnet and Citrix sessions get dropped and cannot be reestablished. The logs show no signatures being triggered and my session thresholds are well below max connection limits. Once IPS is disabled, all problems disappear instantly. This has happened on three different occasions.

Results from sho ip inspect conf (after IPS has been turned off) are as follows;

Session audit trail is enabled

Session alert is enabled

one-minute (sampling period) thresholds are [4500:100000000] connections

max-incomplete sessions thresholds are [4500:20000000]

max-incomplete tcp connections per host is 100000. Block-time 0 minute.

tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec

tcp idle-time is 32400 sec -- udp idle-time is 30 sec

dns-timeout is 5 sec

Results from sho ip inspect stat (after IPS has been turned off) are as follows;

Packet inspection statistics [process switch:fast switch]

tcp packets: [3669185:366719687]

udp packets: [6797247:165723639]

packets: [1441881:3408917]

packets: [6801515:319778749]

Interfaces configured for inspection 0

Session creations since subsystem startup or last reset 511218

Current session counts (estab/half-open/terminating) [3489:380:5]

Maxever session counts (estab/half-open/terminating) [0:0:0]

Last session created 2d06h

Last statistic reset 2d13h

Last session creation rate 1585

Last half-open session total 0

Results from sho ip ips stat (after IPS has been turned off) are;

Interfaces configured for ips 0

Session creations since subsystem startup or last reset 511218

Current session counts (estab/half-open/terminating) [3512:385:7]

Maxever session counts (estab/half-open/terminating) [0:0:0]

Last session created 2d06h

Last statistic reset 2d13h

Any advice is appreciated.

6 Replies 6

Jeffrey Bollinger
Cisco Employee
Cisco Employee

You mentioned AD logins, Citrix, and some HTTP requests fail. Have you determined that these failures are all TCP based? Note that the IOS IPS state tracking engines will not function properly with asymmetric routing or packets that get inspected twice by the same engine.

If you're not seeing any signatures firing, I would look to see what path and return path traffic takes to a certain host to ensure that they're the same. Unexpected ACKs will likely get silently dropped by the state tracking engine.

There is only one path to these networks.

Hi. I have the similar problem(s)! Specifically with smtp and http requests; silently dropped. No log, no debug, nothing; just dropped! Checked only once, on outside intf in in direction. Was forced to turned ips off!

Look at:

DTS # CSCsd07249 IOS FW/IPS enhancement: better handling of TCP out of order packets

We have two ISR's at two sites, both have the above issue.

Try contacting John Gawf (gawf) (gawf@cisco.com), he may have a better answer.

Tim

Hi.

Turns out to be related with asymmetric routing!

(Concept, regarding fw's/id's, poorly explained lately on site but causing HUGE problems!?)

Tanx.

Regards, Nikola

mkirbyii
Level 1
Level 1

Of the signatures you have enabled, are 1330-all subsigs and 1308 enabled? I have had similar issues like you described above and were related to these sigs. By default, they deny-packet and do not Produce-alert.

1308 is ttl evasion

1330 are normalizer sigs

My advice, if you have these sigs, is to add Produce-alert to these and then watch the events. See if these are firing. If so remove the deny actions on the subsigs that are dropping traffic.

Mike

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: