Practical limit to IPSec Filter rules in a policy on Win2000?

  • Thread starter Thread starter Herb Martin
  • Start date Start date
H

Herb Martin

Is there a practical limit to IPSec Filter rules in a policy
on Win2000 Server (SP4)?

I loaded a reasonably big one -- the batch file is 35K --
and the LSASS process went to 98%, neither stopping the IPSec
Policy Agent nor killing the policy don't help: a re-boot
is required.

Any ideas or wonderful papers on IPSec (or pointers to a more
appropriate newsgroup to ask) are appreciated.
 
David Beder said:
Depending on how fast your processor is, the system should be able to handle
a few hundred rules, but generally, if you've got more than a handful of
rules, you might be going about things wrong. Ultimately it does boil down
to the number of actual filters being created and stored by your rules, and
the more filters you have the more likely that a chunk of them will need to
be examined by the driver to determine the best match. This however,
probably wouldn't show up as a hit to LSASS.

About 213 rules -- probably half with 1 filter and half with about 10; quick
estimate about 200 rules with 1000 filters for block OR PASS only. [Second
though: About 2/3 1 filter, 1/3 10 filters but this is a rough estimate
regardless.]

If I get it perfected, the rule count can drop about 40%, since then I can
just
BLOCK all, instead of each protocol (I am trying to find the problems this
will create if I miss something.) The filter count will only go down about
10 or
20% probably, because of the 10x rules for many that PASS.

But then I have a plan to implement actual IPSec negotation for SOME filters
so that clients can roam (dialup, hotel access, home DSL, etc.); probably
using
Certificates for IPSec authentication. This will only add a few rules,
without
changing the filter count much, since a BLOCK or PASS will be moved to
NEGOTIATE IPSec REQUIRED.
With your statement that you used a batch file, are you implying the usage
of the reskit tool ipsecpol.exe? And if so, is this policy being imported as
a static local policy, or are you running the batch file every time the
machine boots? Typically the usage of the term "rule" would imply a static
local policy, but I thought I'd make sure.

Yes to IPSecPol - right now I am just running in test mode so all this is
interactive
and when I hose it up, I just disable or kill the Policy. The testing is
using the
registry (-w REG) to build the policy.
It's not surprising that LSASS would peg while importing the policy, and if
it's a slower machine, there might be some additional time afterwards
while
<snip>

I suspect that LSAss was doing the Name Resolution for some of my rules
and this influenced the "peg out" -- I have removed all DNS names from rules
and resolve them prior to running the command. Side effect: Reduction in
filters (since I was including the DNS names as backup to address filters,
in case the IP changed on those machines.)

All rules are currently BLOCK or PASS -- I am just using it to firewall
this machine on unused or non-public ports. It's in an exposed location
where even my "neighbors" are suspect (at a LARGE ISP.)
If you're willing to share an outline of your policy, I might be able to
suggest some improvements/optimizations.

Sure, I can even send you the whole thing if you wish (I don't want to post
that because the goal is to cut down the attack surface area of an
IIS/Email/DNS
server in an exposed position. I can also send the Perl script that writes
this
batch file (it's really too complicated to hand manage).

Here's the deal: Rental Dedicated Server running web sites on multiple IP
addresses,
multiple ports (like for retrieving Web email/think OWA), a list server,
email server,
pop etc. It is also a domain client machine (in the ISP domain) so I need
connections
to their DCs and to their monitor consoles.

Finally, I am allowing some traffic to a number of disjoint (sub)networks
(about 4 but each
of these is handled as ONE item per rule.)

So, here's what I have: Rules that block TCP, UDP or BOTH on each protocol,
block
ICMP and then rules that ALLOW them specifically.to certain machines and
subnets.

Unresolved questions:
1) "More specific" rule takes effect -- how are things like:
ANY host -> SPECIFIC host on ANY PORT (UDP), compared to
Specific host -> Specific Host on Specific PORT (UDP) ?
Is PORT more specific than HOST? What about a HOST subnet /24 etc.

Also: What about a tie? (Seems like block is the rule.)

2) Seems you must put BOTH [brackets] AND the BLOCK keyword to get
a good rule, same for BOTH (parens) and PASS keyword to get a
PASS
My docs say that either work and several example files I found
on MS site
or elsewhere use one method or the other -- (IIRC, just the
bracketing worked
for dynamic filters.)

3) If you do "PORT" and omit PROTOCOL, does that mean "UDP/TCP" (won't
confuse raw IP, etc.?

4) Are there any plans to add "TCP (established)" like in RRAS?

Are there any better docs than the Help output? (I have several of the
articles from
the MS site and the web in general, but I will take all suggestions and
re-check them...)

And I am a TechNet nut so I have read EVERYTHING in there (resource kit
books,
step-by-step, KBs, etc.)

David
Microsoft Windows Networking
This posting is provided "AS IS" with no warranties, and confers no
rights.

Thanks for taking an interest.
 
I am close to getting it to work.

Several things I learned -- and many mistakes I have made -- about
IPSecPol and the syntax.

(I am down to 136 rules. Probably close to a thousand filter items.)

One: I was (sort of) wrong about needing BOTH the brackets and
the BLOCK or parens and PASS. The key words are not working.

It seems that syntax mistakes can be quietly eaten by IPSecPol SOMETIMES
and some such mistakes will lock the policy up -- a naive (quick) test will
seem to show the target blocked.

LSAss does go to 100% when loading the policy; and stays there for 5-15
minutes until it get's it fully processed (I assume.)

Sometimes the IPSec Policy Agent gets hose and is VERY difficult to stop.

Adding and activating even 1 rule cause what seem to be a full reprocessing.
 
Back
Top