Networking Forums

Networking Forums > Computer Networking > Windows Networking > IPSec: Network sooo slooooow

Reply
Thread Tools Display Modes

IPSec: Network sooo slooooow

 
 
=?Utf-8?B?RCBIYXJ0cnk=?=
Guest
Posts: n/a

 
      03-15-2005, 12:49 PM
I have been fiddling with IPSec on a test network running in VMWare. I've
not set up IPSec policies before so am unsure if I have done something
stupid, perhaps made a mistake many have before me.....??

I have a simple network of two servers (2003 Ent) and a client (XP Pro SP2).
One server is an offline root standalone CA, the other a DC and enterprise
sub-CA. This autoenrolls certificates to users and computers.

I have enabled the Server (respond) policy for the entire domain, and with
the policy active, I can log onto the DC from the XP client, but very slowly.
From the DC I can monitor the SAs, they are being set up between the DC and
the XP client.

I get the same result whether I set the authentication for the policy to
certificates or kerberos, I have tried with both.

It might also be relevant that the DC is running the highsecdc.inf and the
client the highsecws.inf security templates. I am going to try the scenairo
without any security policy in place next.

Any ideas why the IPSec policy would 'work' but slow the network down so
much? eg The XP client has been logging on, at the 'applying computer
settings'/'applying your personal settings' stage for about 5-10 minutes now.

I understand that there is an overhead associated with IPSec, but surely not
this much? Even given the fact that the machines are VMs? BTW the physical
machine this is all running on is an Athlon 2.2GHz with 512MB RAM, Big disks.

--
David Hartry
 
Reply With Quote
 
 
 
 
=?Utf-8?B?RCBIYXJ0cnk=?=
Guest
Posts: n/a

 
      03-15-2005, 01:27 PM
When I wrote:
> I have enabled the Server (respond) policy for the entire domain


I meant the 'Server (request)' policy!


Thanks
Dave

 
Reply With Quote
 
Steven L Umbach
Guest
Posts: n/a

 
      03-17-2005, 03:02 AM
My guess is that since you enabled this at the domain level you are causing
problems with domain computers accessing domain controllers since domain
controllers are also the kerberos key distribution centers. When you
configure an ipsec policy in the domain you must exempt domain controllers
from ipsec negotiation. The is best done by adding a filter list to the
ipsec policy with a rule for permit action for all traffic to and from
domain controllers by their static IP addresses. It is best to not configure
an ipsec policy at the domain level but instead do it at the OU level. The
link below explains more. --- Steve

http://support.microsoft.com/default...b;en-us;254949

"D Hartry" <(E-Mail Removed)> wrote in message
news:9AB91D6A-8FC9-42E2-BB1A-(E-Mail Removed)...
>I have been fiddling with IPSec on a test network running in VMWare. I've
> not set up IPSec policies before so am unsure if I have done something
> stupid, perhaps made a mistake many have before me.....??
>
> I have a simple network of two servers (2003 Ent) and a client (XP Pro
> SP2).
> One server is an offline root standalone CA, the other a DC and enterprise
> sub-CA. This autoenrolls certificates to users and computers.
>
> I have enabled the Server (respond) policy for the entire domain, and with
> the policy active, I can log onto the DC from the XP client, but very
> slowly.
> From the DC I can monitor the SAs, they are being set up between the DC
> and
> the XP client.
>
> I get the same result whether I set the authentication for the policy to
> certificates or kerberos, I have tried with both.
>
> It might also be relevant that the DC is running the highsecdc.inf and the
> client the highsecws.inf security templates. I am going to try the
> scenairo
> without any security policy in place next.
>
> Any ideas why the IPSec policy would 'work' but slow the network down so
> much? eg The XP client has been logging on, at the 'applying computer
> settings'/'applying your personal settings' stage for about 5-10 minutes
> now.
>
> I understand that there is an overhead associated with IPSec, but surely
> not
> this much? Even given the fact that the machines are VMs? BTW the
> physical
> machine this is all running on is an Athlon 2.2GHz with 512MB RAM, Big
> disks.
>
> --
> David Hartry



 
Reply With Quote
 
=?Utf-8?B?RCBIYXJ0cnk=?=
Guest
Posts: n/a

 
      03-17-2005, 02:57 PM
Thanks Steve,

I had almost come to this conclusion myself after searching on the web, but
you have confirmed my suspicions. If possible, I would like to secure all
traffic to DCs except for the logon etc traffic that needs to be unsecured. I
think I need to set specific filters to allow unsecured domain membership
traffic to/from DCs, but to secure all other traffic. I'm unsure exactly what
traffic needs to be excluded. Can anyone tell me the protocols and ports
used in 'domain membership' communications between DCs and domain computers?

Thanks again,
Dave


"Steven L Umbach" wrote:

> My guess is that since you enabled this at the domain level you are causing
> problems with domain computers accessing domain controllers since domain
> controllers are also the kerberos key distribution centers. When you
> configure an ipsec policy in the domain you must exempt domain controllers
> from ipsec negotiation. The is best done by adding a filter list to the
> ipsec policy with a rule for permit action for all traffic to and from
> domain controllers by their static IP addresses. It is best to not configure
> an ipsec policy at the domain level but instead do it at the OU level. The
> link below explains more. --- Steve
>
> http://support.microsoft.com/default...b;en-us;254949
>
> "D Hartry" <(E-Mail Removed)> wrote in message
> news:9AB91D6A-8FC9-42E2-BB1A-(E-Mail Removed)...
> >I have been fiddling with IPSec on a test network running in VMWare. I've
> > not set up IPSec policies before so am unsure if I have done something
> > stupid, perhaps made a mistake many have before me.....??
> >
> > I have a simple network of two servers (2003 Ent) and a client (XP Pro
> > SP2).
> > One server is an offline root standalone CA, the other a DC and enterprise
> > sub-CA. This autoenrolls certificates to users and computers.
> >
> > I have enabled the Server (respond) policy for the entire domain, and with
> > the policy active, I can log onto the DC from the XP client, but very
> > slowly.
> > From the DC I can monitor the SAs, they are being set up between the DC
> > and
> > the XP client.
> >
> > I get the same result whether I set the authentication for the policy to
> > certificates or kerberos, I have tried with both.
> >
> > It might also be relevant that the DC is running the highsecdc.inf and the
> > client the highsecws.inf security templates. I am going to try the
> > scenairo
> > without any security policy in place next.
> >
> > Any ideas why the IPSec policy would 'work' but slow the network down so
> > much? eg The XP client has been logging on, at the 'applying computer
> > settings'/'applying your personal settings' stage for about 5-10 minutes
> > now.
> >
> > I understand that there is an overhead associated with IPSec, but surely
> > not
> > this much? Even given the fact that the machines are VMs? BTW the
> > physical
> > machine this is all running on is an Athlon 2.2GHz with 512MB RAM, Big
> > disks.
> >
> > --
> > David Hartry

>
>
>

 
Reply With Quote
 
Steven L Umbach
Guest
Posts: n/a

 
      03-17-2005, 05:51 PM
The Windows free 2003 Security Guide covers this in detail by describing how
to use ipsec filtering to secure domain controllers. Ipsec filtering uses an
ipsec policy that uses only permit and deny filter actions to act as a
packet filtering firewall instead of negotiation policy. The link below is
to the Windows 2003 Security Guide. There is also a challenge in dynamic RPC
port assignment that can be remedied with a registry entry to restrict ports
that will be used. The second link will give a basic idea of what
ports/protocols are used. --- Steve

http://www.microsoft.com/downloads/d...displaylang=en
http://support.microsoft.com/default...en-us%3B179442

Windows NT
Client Port(s) Server Port Service
1024-65535/TCP 135/TCP RPC *
137/UDP 137/UDP NetBIOS Name
138/UDP 138/UDP NetBIOS Netlogon and Browsing
1024-65535/TCP 139/TCP NetBIOS Session
1024-65535/TCP 42/TCP WINS Replication

Windows 2000
For a mixed-mode domain with either Windows NT domain controllers or legacy
clients or trust relationship between two windows 2000 domain controllers
that are not in the same forest, all of the preceding ports for Windows NT
may need to be opened in addition to the following ports: Client Port(s)
Server Port Service
1024-65535/TCP 135/TCP RPC *
1024-65535/TCP/UDP 389/TCP/UDP LDAP
1024-65535/TCP 636/TCP LDAP SSL
1024-65535/TCP 3268/TCP LDAP GC
1024-65535/TCP 3269/TCP LDAP GC SSL
53,1024-65535/TCP/UDP 53/TCP/UDP DNS
1024-65535/TCP/UDP 88/TCP/UDP Kerberos
1024-65535/TCP 445/TCP SMB


"D Hartry" <(E-Mail Removed)> wrote in message
news:95B2E066-C844-4200-95F0-(E-Mail Removed)...
> Thanks Steve,
>
> I had almost come to this conclusion myself after searching on the web,
> but
> you have confirmed my suspicions. If possible, I would like to secure all
> traffic to DCs except for the logon etc traffic that needs to be
> unsecured. I
> think I need to set specific filters to allow unsecured domain membership
> traffic to/from DCs, but to secure all other traffic. I'm unsure exactly
> what
> traffic needs to be excluded. Can anyone tell me the protocols and ports
> used in 'domain membership' communications between DCs and domain
> computers?
>
> Thanks again,
> Dave
>
>
> "Steven L Umbach" wrote:
>
>> My guess is that since you enabled this at the domain level you are
>> causing
>> problems with domain computers accessing domain controllers since domain
>> controllers are also the kerberos key distribution centers. When you
>> configure an ipsec policy in the domain you must exempt domain
>> controllers
>> from ipsec negotiation. The is best done by adding a filter list to the
>> ipsec policy with a rule for permit action for all traffic to and from
>> domain controllers by their static IP addresses. It is best to not
>> configure
>> an ipsec policy at the domain level but instead do it at the OU level.
>> The
>> link below explains more. --- Steve
>>
>> http://support.microsoft.com/default...b;en-us;254949
>>
>> "D Hartry" <(E-Mail Removed)> wrote in message
>> news:9AB91D6A-8FC9-42E2-BB1A-(E-Mail Removed)...
>> >I have been fiddling with IPSec on a test network running in VMWare.
>> >I've
>> > not set up IPSec policies before so am unsure if I have done something
>> > stupid, perhaps made a mistake many have before me.....??
>> >
>> > I have a simple network of two servers (2003 Ent) and a client (XP Pro
>> > SP2).
>> > One server is an offline root standalone CA, the other a DC and
>> > enterprise
>> > sub-CA. This autoenrolls certificates to users and computers.
>> >
>> > I have enabled the Server (respond) policy for the entire domain, and
>> > with
>> > the policy active, I can log onto the DC from the XP client, but very
>> > slowly.
>> > From the DC I can monitor the SAs, they are being set up between the DC
>> > and
>> > the XP client.
>> >
>> > I get the same result whether I set the authentication for the policy
>> > to
>> > certificates or kerberos, I have tried with both.
>> >
>> > It might also be relevant that the DC is running the highsecdc.inf and
>> > the
>> > client the highsecws.inf security templates. I am going to try the
>> > scenairo
>> > without any security policy in place next.
>> >
>> > Any ideas why the IPSec policy would 'work' but slow the network down
>> > so
>> > much? eg The XP client has been logging on, at the 'applying computer
>> > settings'/'applying your personal settings' stage for about 5-10
>> > minutes
>> > now.
>> >
>> > I understand that there is an overhead associated with IPSec, but
>> > surely
>> > not
>> > this much? Even given the fact that the machines are VMs? BTW the
>> > physical
>> > machine this is all running on is an Athlon 2.2GHz with 512MB RAM, Big
>> > disks.
>> >
>> > --
>> > David Hartry

>>
>>
>>



 
Reply With Quote
 
=?Utf-8?B?RCBIYXJ0cnk=?=
Guest
Posts: n/a

 
      03-17-2005, 09:51 PM
Steve,

Thank you, exactly the information I was after.

"Steven L Umbach" wrote:

> The Windows free 2003 Security Guide covers this in detail by describing how
> to use ipsec filtering to secure domain controllers. Ipsec filtering uses an
> ipsec policy that uses only permit and deny filter actions to act as a
> packet filtering firewall instead of negotiation policy. The link below is
> to the Windows 2003 Security Guide. There is also a challenge in dynamic RPC
> port assignment that can be remedied with a registry entry to restrict ports
> that will be used. The second link will give a basic idea of what
> ports/protocols are used. --- Steve
>
> http://www.microsoft.com/downloads/d...displaylang=en
> http://support.microsoft.com/default...en-us%3B179442
>
> Windows NT
> Client Port(s) Server Port Service
> 1024-65535/TCP 135/TCP RPC *
> 137/UDP 137/UDP NetBIOS Name
> 138/UDP 138/UDP NetBIOS Netlogon and Browsing
> 1024-65535/TCP 139/TCP NetBIOS Session
> 1024-65535/TCP 42/TCP WINS Replication
>
> Windows 2000
> For a mixed-mode domain with either Windows NT domain controllers or legacy
> clients or trust relationship between two windows 2000 domain controllers
> that are not in the same forest, all of the preceding ports for Windows NT
> may need to be opened in addition to the following ports: Client Port(s)
> Server Port Service
> 1024-65535/TCP 135/TCP RPC *
> 1024-65535/TCP/UDP 389/TCP/UDP LDAP
> 1024-65535/TCP 636/TCP LDAP SSL
> 1024-65535/TCP 3268/TCP LDAP GC
> 1024-65535/TCP 3269/TCP LDAP GC SSL
> 53,1024-65535/TCP/UDP 53/TCP/UDP DNS
> 1024-65535/TCP/UDP 88/TCP/UDP Kerberos
> 1024-65535/TCP 445/TCP SMB
>
>
> "D Hartry" <(E-Mail Removed)> wrote in message
> news:95B2E066-C844-4200-95F0-(E-Mail Removed)...
> > Thanks Steve,
> >
> > I had almost come to this conclusion myself after searching on the web,
> > but
> > you have confirmed my suspicions. If possible, I would like to secure all
> > traffic to DCs except for the logon etc traffic that needs to be
> > unsecured. I
> > think I need to set specific filters to allow unsecured domain membership
> > traffic to/from DCs, but to secure all other traffic. I'm unsure exactly
> > what
> > traffic needs to be excluded. Can anyone tell me the protocols and ports
> > used in 'domain membership' communications between DCs and domain
> > computers?
> >
> > Thanks again,
> > Dave
> >
> >
> > "Steven L Umbach" wrote:
> >
> >> My guess is that since you enabled this at the domain level you are
> >> causing
> >> problems with domain computers accessing domain controllers since domain
> >> controllers are also the kerberos key distribution centers. When you
> >> configure an ipsec policy in the domain you must exempt domain
> >> controllers
> >> from ipsec negotiation. The is best done by adding a filter list to the
> >> ipsec policy with a rule for permit action for all traffic to and from
> >> domain controllers by their static IP addresses. It is best to not
> >> configure
> >> an ipsec policy at the domain level but instead do it at the OU level.
> >> The
> >> link below explains more. --- Steve
> >>
> >> http://support.microsoft.com/default...b;en-us;254949
> >>
> >> "D Hartry" <(E-Mail Removed)> wrote in message
> >> news:9AB91D6A-8FC9-42E2-BB1A-(E-Mail Removed)...
> >> >I have been fiddling with IPSec on a test network running in VMWare.
> >> >I've
> >> > not set up IPSec policies before so am unsure if I have done something
> >> > stupid, perhaps made a mistake many have before me.....??
> >> >
> >> > I have a simple network of two servers (2003 Ent) and a client (XP Pro
> >> > SP2).
> >> > One server is an offline root standalone CA, the other a DC and
> >> > enterprise
> >> > sub-CA. This autoenrolls certificates to users and computers.
> >> >
> >> > I have enabled the Server (respond) policy for the entire domain, and
> >> > with
> >> > the policy active, I can log onto the DC from the XP client, but very
> >> > slowly.
> >> > From the DC I can monitor the SAs, they are being set up between the DC
> >> > and
> >> > the XP client.
> >> >
> >> > I get the same result whether I set the authentication for the policy
> >> > to
> >> > certificates or kerberos, I have tried with both.
> >> >
> >> > It might also be relevant that the DC is running the highsecdc.inf and
> >> > the
> >> > client the highsecws.inf security templates. I am going to try the
> >> > scenairo
> >> > without any security policy in place next.
> >> >
> >> > Any ideas why the IPSec policy would 'work' but slow the network down
> >> > so
> >> > much? eg The XP client has been logging on, at the 'applying computer
> >> > settings'/'applying your personal settings' stage for about 5-10
> >> > minutes
> >> > now.
> >> >
> >> > I understand that there is an overhead associated with IPSec, but
> >> > surely
> >> > not
> >> > this much? Even given the fact that the machines are VMs? BTW the
> >> > physical
> >> > machine this is all running on is an Athlon 2.2GHz with 512MB RAM, Big
> >> > disks.
> >> >
> >> > --
> >> > David Hartry
> >>
> >>
> >>

>
>
>

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ipsec tunnel mode vs ip in ip with ipsec transport Reji Linux Networking 1 09-20-2011 04:29 PM
IPv6 + IPsec + ipsec-tools 0.6.[4567] + scope:link = no SA established phil-news-nospam@ipal.net Linux Networking 0 07-25-2007 09:01 PM
My new MN-500 is slooooow Matt Miller Broadband Hardware 0 05-15-2004 03:23 AM
Flip I'm fed up no ADSL and Slooooow 56K Stevie Boy Broadband 7 10-11-2003 07:47 PM
Slooooow networking... Rai! Linux Networking 5 09-16-2003 08:00 PM



1 2 3 4 5 6 7 8 9 10 11