IPSec without encryption between intranet and standalone

  • Thread starter Thread starter rolf
  • Start date Start date
R

rolf

Hi all,

Im trying to use IPSec to lock down a server denying all TCP traffic
and then opening traffic on certain ports for certain IP addresses.

The ruleset works fine, the server still has public http acces, I can
get terminal services up etc. However the intranet accesses the msSQL
server on the remote host via a connection string and there is a pause
everytime a new connection is made or a session expires as the intranet
attempts to authenticate via kerberos. This is not possible as they are
not on the same domain.

Couple of questions;
1 - why is this problem not apparent when using teminal services etc,
but very apparent on the intranet msSQL access, when all the rules have
the default kerberos authentication.
2 - can I dtop authentication completely..? If I used a sharedkey how
would that let HTML traffic through..?
3 - if I use a shared key how to get that key used from the intranet to
the remote machine..? Do I set up IPSec at the other end as well..?

Thanks for any help but of an IPSec newbie.
 
As I read your posting, and an earlier one, you have no shared
realm and so no chance for there to be any form Kerberos authN
to ever work. Also, all that you are attempting to do is to filter
what IPs can connect at which ports - you are not trying to provide
an packet protection except allowed endpoints (IPs/prot/ports).
However you are using rules as if you are trying to form IPsec
security associations (Kerberos and talk of shared key).
If all you want to do is endpoint filtering just make all of your
filters shared key and enter something and forget it. You are
not using security associations, only the filtering.
Things slow down because for each connection effort there
is a magnification in time due to the attempts to do a Kerberos
authN, the communications exchange to find a common provider,
etc.. Again, you only need to have a working authN such as
Kerberos, or shared key, if you are intending to use packet
protection levels. Just define your rules with a garbage shared
string (that you do not have to in any way share) and uncheck
any default rules, plus for actions just use permit or block.

There is an IPsec newsgroup, which you will find mentioned
along with much other IPsec docs/guidance at
http://microsoft.com/ipsec
 
Thanks for the reply, I reposted as the focus of the question was
different. I was not aware I could enter a nonsense string as a shared
key and it would still work! That sounds like exactly the thing I need.
For this server I am indeed not interested in encrypting the traffic
but I couldnt see anything obvious about 'switching it off'.

Thanks again,

I'll rewrite hte rules and see what happens.
 
It works IF you are not trying to form any security associations,
which it sounded like you are not.
 
I've now set all the rules to use a public key which is set to a
rubbish string. I am still getting the pause of a few seconds from the
local instranet when establishing connections to the remote msSQL
server. Is there anything I should do at the intranet end..?

I've also unassinged the IPSec polcy and instantly the 'lag' disappears
so definately something to do with the IPSec policy.

Thanks for the help so far I hope to get this sorted as I need the
IPSec policy in place to stop random dictionary attacks on the msSQL
passwords, which fills all the logs up and slows the machines response
down.

Thanks
 
Are _all_ of your filters set to either permit or block actions,
with nothing otherwise that would attempt to form a security
association ?
 
Hi there Roger,

Yes Ive checked again and all rules are either PERMIT or BLOCK no
security or authentication requests.

I'm at my wits end with this...have no idea what could be causing this
lag in initial contact. Ive also tried altering the IPsec policy at the
other end so it has the shared key etc but no joy.

Thanks
Rolf
 
Hi Rolf

If it were in my environment I would probably be using
NetMon or a similar capture tools to take a look at just
exactly what is going over the network in order to find the
delay, but it seems that you have ruled out IPsec attempting
authentications that are destined to fail.
 
Back
Top