Re: Firewall Service dies like clockwork
- From: "Phill Hardstaff" <phillh@xxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Wed, 27 Nov 2002 10:48:04 +1100
MessageTom, yep sounds like the same thing, I will try it next week when I get
back to work and let you know, from memory I think I block one or two sites
that I am really not too worried about, was going to use
http://www.contentkeeper.com/ anyway :)
Jim, somehow I sent the last message twice, sorry about that.
Cheers
Phil
----- Original Message -----
From: Thomas W Shinder
To: [ISAserver.org Discussion List]
Sent: Tuesday, November 26, 2002 4:28 PM
Subject: [isalist] Re: Firewall Service dies like clockwork
http://www.ISAserver.org
http://www.ISAserver.org
Hey guys,
Here's some information I have that might be useful in this situation:
Junior Member
Member # 8800
posted November 15, 2002 12:13 PM
------------------------------------------------------------------------
** NEWS FLASH **
Microsoft has managed to reproduce our problem in their lab AND they
have managed to find the cause.. no cure yet though :-(
IF you have UDP based publishing (any UPD not just DNS) AND a Site and
Content filter containing FQDN the following happens;
Incoming UDP requests are checked against the Site and Content rules by
attempting to do a reverse lookup on the incoming IP (to find a FQDN to match
against the IP).
If this for some reason fails (like the requesting IP not being in a
reverse zone) then the ISA tries to make a NBTSTAT query against the remote IP
to find the FQDN.
Once it has succeded, failed or timed-out on the incoming request it
will then process the request.
This can take some time (at least on my side we just drop incoming
netbios so those will have to timeout) and during that time the ISA is gobbling
up UDP connections.
With heavy traffic this will at times cause the pool of available UDP
mapppings to be full so that incoming requests first have to wait for another
request to make it through the S&S rules before itself can start the path
through!
So if;
- you have a remote client that is not in a reverse zone and that can
not be resolved by nbtstat AND if it is re-requesting the DNS information after
say 5 seconds
- then you can easily end up in a situation where
- the requests are being held pending, in wait for a process slot,
while the ISA is trying to resolve the FQDN of a previous request FROM THE SAME
MACHINE!
So the good news is that they know why and the bad news is that it
sounds like it is a fundamental change that needs to be done!
Possible workaround, no S&S rules! Not sure I want to go that way....
Was this clear? If not, drop me a line and I'll try again....
/Jörgen
HTH,
Tom
Thomas W Shinder
www.isaserver.org/shinder
http://tinyurl.com/1jq1
http://tinyurl.com/1llp
Other related posts:
