today for no reason, external customers could no longer get to our https://
sites and could not vpn in via PPTP, yet HTTP and SMTP was fine..

Checked with the ISP and everything worked for them. However anybody
external to the ISP could not get in. I reloaded the router, no change..

IOS (tm) 3700 Software (C3725-IK9O3S-M), Version 12.3(6), RELEASE SOFTWARE
(fc3)

Eventually I removed an ip audit rule from the external interface and it all
came back to life.

However, my ids was not configured to drop.. the action for info and attach
sigs was to alarm and then i collected the info in syslog.

It seems that IDS was somehow dropping backets of particular protocols with
a certain TTL in them, which expalins why my ISP could get to the affected
sites no problem.

I made a new IDS policy under a different name and applied that..

Instantly the problem reappeared again..

has anyone ever seen this kind of behaviour?

ip audit po max-events 100

ip audit signature 1107 disable

ip audit signature 2000 disable

ip audit signature 2001 disable

ip audit signature 2004 disable

ip audit signature 2005 disable

ip audit name IDS info action alarm

ip audit name IDS attack action alarm

On Mon, 19 Jul 2004 23:17:55 -0500, P wrote:

> today for no reason, external customers could no longer get to our
> https:// sites and could not vpn in via PPTP, yet HTTP and SMTP was
> fine..
>
> Checked with the ISP and everything worked for them. However anybody
> external to the ISP could not get in. I reloaded the router, no change..
>
> IOS (tm) 3700 Software (C3725-IK9O3S-M), Version 12.3(6), RELEASE
> SOFTWARE (fc3)
>
> Eventually I removed an ip audit rule from the external interface and it
> all came back to life.
>
> However, my ids was not configured to drop.. the action for info and
> attach sigs was to alarm and then i collected the info in syslog.
>
> It seems that IDS was somehow dropping backets of particular protocols
> with a certain TTL in them, which expalins why my ISP could get to the
> affected sites no problem.
>
> I made a new IDS policy under a different name and applied that..
>
> Instantly the problem reappeared again..
>
> has anyone ever seen this kind of behaviour?
>
> ip audit po max-events 100
>
> ip audit signature 1107 disable
>
> ip audit signature 2000 disable
>
> ip audit signature 2001 disable
>
> ip audit signature 2004 disable
>
> ip audit signature 2005 disable
>
> ip audit name IDS info action alarm
>
> ip audit name IDS attack action alarm


Yes. No workaround that I know of, other than to use code that does not
exhibit this behavior.

Rik