Have you pulled a list of the filters (and their associated weights) from
the IPsec monitor? Are the weights listed properly but not working as
expected or are they listed out of the order you are expecting?

I don't have an XP box in front of me to check, but can you also pull the
active policy using ipseccmd to look at the active filters?

Jason

"Greg O" wrote in message
news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
> Hi,
> I have explained the problem in another thread in the security newsgroup:
>
> http://groups.google.com/group/micro...b4000d05280776
>
> It seems to be a big in IPSEC as it filas to allow a connection to the
> Internet but does it for an internal address.
>

The weights and filters are listed properly (checked in IPSEC monitor), they
just don't work. If I make a general block say from internal subnet A to B
(for example 192.168.0.0 to 192.168.1.0) and then give a more specific
permit to 192.168.0.0 to say 192.168.1.15 then anyone on 192.168.0.0 should
be able to receive from 192.168.1.15. In fact if I do this it works
perfectly. If I however change the 192.168.1.15 to an external IP address
say of a web site, then it doesn't work. If I then disable the block it
starts to work. It seems like a bug in IPSEC itself because it only fails on
external addresses not internal ones. The more specific filter should
override the general one but it doesn't on external IP addresses.

I wanted to only allow specific web sites into the network and block all
others for safety reasons.




"Jason Popp [MSFT]" wrote in message
news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
> Have you pulled a list of the filters (and their associated weights) from
> the IPsec monitor? Are the weights listed properly but not working as
> expected or are they listed out of the order you are expecting?
>
> I don't have an XP box in front of me to check, but can you also pull the
> active policy using ipseccmd to look at the active filters?
>
> Jason
>
> "Greg O" wrote in message
> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>> Hi,
>> I have explained the problem in another thread in the security newsgroup:
>>
>> http://groups.google.com/group/micro...b4000d05280776
>>
>> It seems to be a big in IPSEC as it filas to allow a connection to the
>> Internet but does it for an internal address.
>>
>

Can you list the actual filters you have deployed? From the description in
the google link it wasn't clear to me...
e.g. Any < - > 192.168.0.0/24, Permit
e.g. Me < - > 192.168.0.5, TCP/80 Block


Jason

"Greg O" wrote in message
news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
> The weights and filters are listed properly (checked in IPSEC monitor),
> they just don't work. If I make a general block say from internal subnet A
> to B (for example 192.168.0.0 to 192.168.1.0) and then give a more
> specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I do
> this it works perfectly. If I however change the 192.168.1.15 to an
> external IP address say of a web site, then it doesn't work. If I then
> disable the block it starts to work. It seems like a bug in IPSEC itself
> because it only fails on external addresses not internal ones. The more
> specific filter should override the general one but it doesn't on external
> IP addresses.
>
> I wanted to only allow specific web sites into the network and block all
> others for safety reasons.
>
>
>
>
> "Jason Popp [MSFT]" wrote in message
> news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>> Have you pulled a list of the filters (and their associated weights) from
>> the IPsec monitor? Are the weights listed properly but not working as
>> expected or are they listed out of the order you are expecting?
>>
>> I don't have an XP box in front of me to check, but can you also pull the
>> active policy using ipseccmd to look at the active filters?
>>
>> Jason
>>
>> "Greg O" wrote in message
>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>> Hi,
>>> I have explained the problem in another thread in the security
>>> newsgroup:
>>>
>>> http://groups.google.com/group/micro...b4000d05280776
>>>
>>> It seems to be a big in IPSEC as it filas to allow a connection to the
>>> Internet but does it for an internal address.
>>>
>>
>
>

I reloaded the 2003 operating system to make sure it wasn't a recent patch
causing problems, it just has service pack 1 so far. Before it was fully
patched. For example:

Any <-> 192.168.0.0, Block
192.168.1.5 <-> 192.168.0.10 Permit

This internal connection would work. If I however add a rule:

192.168.0.10 <-> 200.199.136.200 Permit

then this would not work because it is outside the network, i.e. the
internet. This is a made up external IP address as an example, I have tried
many different external IP addresses with no success. I can show this is a
problem in IPSEC (that is, not a firewall or other issue) by removing the
general block i.e. remove
Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
external web site. The general block seems to override the Permit even
though it has a lower weighting. I did confirm the weighting of the general
block is lower in IP monitor. I believe ipseccmd is not used in server 2003,
at least it is not recognized. I assume there is a netsh equivalent command.


"Jason Popp [MSFT]" wrote in message
news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
> Can you list the actual filters you have deployed? From the description
> in the google link it wasn't clear to me...
> e.g. Any < - > 192.168.0.0/24, Permit
> e.g. Me < - > 192.168.0.5, TCP/80 Block
>
>
> Jason
>
> "Greg O" wrote in message
> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>> The weights and filters are listed properly (checked in IPSEC monitor),
>> they just don't work. If I make a general block say from internal subnet
>> A to B (for example 192.168.0.0 to 192.168.1.0) and then give a more
>> specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
>> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I do
>> this it works perfectly. If I however change the 192.168.1.15 to an
>> external IP address say of a web site, then it doesn't work. If I then
>> disable the block it starts to work. It seems like a bug in IPSEC itself
>> because it only fails on external addresses not internal ones. The more
>> specific filter should override the general one but it doesn't on
>> external IP addresses.
>>
>> I wanted to only allow specific web sites into the network and block all
>> others for safety reasons.
>>
>>
>>
>>
>> "Jason Popp [MSFT]" wrote in message
>> news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>> Have you pulled a list of the filters (and their associated weights)
>>> from the IPsec monitor? Are the weights listed properly but not working
>>> as expected or are they listed out of the order you are expecting?
>>>
>>> I don't have an XP box in front of me to check, but can you also pull
>>> the active policy using ipseccmd to look at the active filters?
>>>
>>> Jason
>>>
>>> "Greg O" wrote in message
>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>> Hi,
>>>> I have explained the problem in another thread in the security
>>>> newsgroup:
>>>>
>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>
>>>> It seems to be a big in IPSEC as it filas to allow a connection to the
>>>> Internet but does it for an internal address.
>>>>
>>>
>>
>>
>

I haven't had the opportunity to repro the RRAS config with the policies but
on the surface they look good to me. I think that in order to track this
down, the best course of action will be to run through the following
(assuming the use of Win2003)

Export the current policy via NETSH or the IPsec Policy Management UI
Enable IKEDiagnostics (netsh ipsec set config ipsecdiagnostics value=7)
Enable IKE Logging for Oakley (netsh ipsec set config ikelogging=1)

Both logging events require a restart (well ikelogging can work with just
restarting policyagent but I'm pretty sure diagnostics requires a restart to
get events to the sec log.)

Setting IKEDiagnostics adds a lot of traffic to the Security log, but what
will be interesting are the packet drops (in addition to the oakley log of
when you do the repro -and in addition to the policy dump)

Jason


"Jason Popp [MSFT]" wrote in message
news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
> Can you list the actual filters you have deployed? From the description
> in the google link it wasn't clear to me...
> e.g. Any < - > 192.168.0.0/24, Permit
> e.g. Me < - > 192.168.0.5, TCP/80 Block
>
>
> Jason
>
> "Greg O" wrote in message
> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>> The weights and filters are listed properly (checked in IPSEC monitor),
>> they just don't work. If I make a general block say from internal subnet
>> A to B (for example 192.168.0.0 to 192.168.1.0) and then give a more
>> specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
>> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I do
>> this it works perfectly. If I however change the 192.168.1.15 to an
>> external IP address say of a web site, then it doesn't work. If I then
>> disable the block it starts to work. It seems like a bug in IPSEC itself
>> because it only fails on external addresses not internal ones. The more
>> specific filter should override the general one but it doesn't on
>> external IP addresses.
>>
>> I wanted to only allow specific web sites into the network and block all
>> others for safety reasons.
>>
>>
>>
>>
>> "Jason Popp [MSFT]" wrote in message
>> news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>> Have you pulled a list of the filters (and their associated weights)
>>> from the IPsec monitor? Are the weights listed properly but not working
>>> as expected or are they listed out of the order you are expecting?
>>>
>>> I don't have an XP box in front of me to check, but can you also pull
>>> the active policy using ipseccmd to look at the active filters?
>>>
>>> Jason
>>>
>>> "Greg O" wrote in message
>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>> Hi,
>>>> I have explained the problem in another thread in the security
>>>> newsgroup:
>>>>
>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>
>>>> It seems to be a big in IPSEC as it filas to allow a connection to the
>>>> Internet but does it for an internal address.
>>>>
>>>
>>
>>
>

Oops, didn't mean to link this to the RRAS config from the post below this
one.

However the diagnostics will be the same to get more info...

Jason


"Jason Popp [MSFT]" wrote in message
news:uAVe6%23fsGHA.4748@TK2MSFTNGP03.phx.gbl...
>I haven't had the opportunity to repro the RRAS config with the policies
>but on the surface they look good to me. I think that in order to track
>this down, the best course of action will be to run through the following
>(assuming the use of Win2003)
>
> Export the current policy via NETSH or the IPsec Policy Management UI
> Enable IKEDiagnostics (netsh ipsec set config ipsecdiagnostics value=7)
> Enable IKE Logging for Oakley (netsh ipsec set config ikelogging=1)
>
> Both logging events require a restart (well ikelogging can work with just
> restarting policyagent but I'm pretty sure diagnostics requires a restart
> to get events to the sec log.)
>
> Setting IKEDiagnostics adds a lot of traffic to the Security log, but what
> will be interesting are the packet drops (in addition to the oakley log of
> when you do the repro -and in addition to the policy dump)
>
> Jason
>
>
> "Jason Popp [MSFT]" wrote in message
> news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>> Can you list the actual filters you have deployed? From the description
>> in the google link it wasn't clear to me...
>> e.g. Any < - > 192.168.0.0/24, Permit
>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>
>>
>> Jason
>>
>> "Greg O" wrote in message
>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>> The weights and filters are listed properly (checked in IPSEC monitor),
>>> they just don't work. If I make a general block say from internal subnet
>>> A to B (for example 192.168.0.0 to 192.168.1.0) and then give a more
>>> specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
>>> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I do
>>> this it works perfectly. If I however change the 192.168.1.15 to an
>>> external IP address say of a web site, then it doesn't work. If I then
>>> disable the block it starts to work. It seems like a bug in IPSEC itself
>>> because it only fails on external addresses not internal ones. The more
>>> specific filter should override the general one but it doesn't on
>>> external IP addresses.
>>>
>>> I wanted to only allow specific web sites into the network and block all
>>> others for safety reasons.
>>>
>>>
>>>
>>>
>>> "Jason Popp [MSFT]" wrote in
>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>> Have you pulled a list of the filters (and their associated weights)
>>>> from the IPsec monitor? Are the weights listed properly but not
>>>> working as expected or are they listed out of the order you are
>>>> expecting?
>>>>
>>>> I don't have an XP box in front of me to check, but can you also pull
>>>> the active policy using ipseccmd to look at the active filters?
>>>>
>>>> Jason
>>>>
>>>> "Greg O" wrote in message
>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>> Hi,
>>>>> I have explained the problem in another thread in the security
>>>>> newsgroup:
>>>>>
>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>
>>>>> It seems to be a big in IPSEC as it filas to allow a connection to the
>>>>> Internet but does it for an internal address.
>>>>>
>>>>
>>>
>>>
>>
>

How are the clients configured for internet access? Are they using a proxy
w/ or without proxy client, router, NAT? And if so, what is the IP address
of the Internet egress point?

Jason


"Greg O" wrote in message
news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>I reloaded the 2003 operating system to make sure it wasn't a recent patch
>causing problems, it just has service pack 1 so far. Before it was fully
>patched. For example:
>
> Any <-> 192.168.0.0, Block
> 192.168.1.5 <-> 192.168.0.10 Permit
>
> This internal connection would work. If I however add a rule:
>
> 192.168.0.10 <-> 200.199.136.200 Permit
>
> then this would not work because it is outside the network, i.e. the
> internet. This is a made up external IP address as an example, I have
> tried many different external IP addresses with no success. I can show
> this is a problem in IPSEC (that is, not a firewall or other issue) by
> removing the general block i.e. remove
> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
> external web site. The general block seems to override the Permit even
> though it has a lower weighting. I did confirm the weighting of the
> general block is lower in IP monitor. I believe ipseccmd is not used in
> server 2003, at least it is not recognized. I assume there is a netsh
> equivalent command.
>
>
> "Jason Popp [MSFT]" wrote in message
> news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>> Can you list the actual filters you have deployed? From the description
>> in the google link it wasn't clear to me...
>> e.g. Any < - > 192.168.0.0/24, Permit
>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>
>>
>> Jason
>>
>> "Greg O" wrote in message
>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>> The weights and filters are listed properly (checked in IPSEC monitor),
>>> they just don't work. If I make a general block say from internal subnet
>>> A to B (for example 192.168.0.0 to 192.168.1.0) and then give a more
>>> specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
>>> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I do
>>> this it works perfectly. If I however change the 192.168.1.15 to an
>>> external IP address say of a web site, then it doesn't work. If I then
>>> disable the block it starts to work. It seems like a bug in IPSEC itself
>>> because it only fails on external addresses not internal ones. The more
>>> specific filter should override the general one but it doesn't on
>>> external IP addresses.
>>>
>>> I wanted to only allow specific web sites into the network and block all
>>> others for safety reasons.
>>>
>>>
>>>
>>>
>>> "Jason Popp [MSFT]" wrote in
>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>> Have you pulled a list of the filters (and their associated weights)
>>>> from the IPsec monitor? Are the weights listed properly but not
>>>> working as expected or are they listed out of the order you are
>>>> expecting?
>>>>
>>>> I don't have an XP box in front of me to check, but can you also pull
>>>> the active policy using ipseccmd to look at the active filters?
>>>>
>>>> Jason
>>>>
>>>> "Greg O" wrote in message
>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>> Hi,
>>>>> I have explained the problem in another thread in the security
>>>>> newsgroup:
>>>>>
>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>
>>>>> It seems to be a big in IPSEC as it filas to allow a connection to the
>>>>> Internet but does it for an internal address.
>>>>>
>>>>
>>>
>>>
>>
>
>

It cannot be any other problem since if I unassign the policy all subnets
can connect to the internet and to each other. If I assign the policy no one
can access the internet even the web sites I explicitly permit.If I permit
an internal IP address (i.e. one on the network) then IPSEC allows it. It
just won't allow any external IP addresses. I can even get a working rule
permitting and internal IP address, e.g. 192.168.0.10 <-> 192.168.1.10
permit and this will work. If I change this rule to 192.168.0.10 <->
200.199.198.197 permit then it stops working. The weight should be the same
since I only changed the IP address on the same part of the rule.

I know it seems odd, I can only think it is a fault in IPSEC for some
reason. Maybe if you tried it yourself you could see for yourself. It's
annoying because I wanted to allow specific web sites and block all others
for safety reasons. It may be another Microsoft product is supposed to do
this instead and they intend people to upgrade. Does ISA do this for
example, though not with IPSEC of course.


"Jason Popp [MSFT]" wrote in message
news:%23ZNrBGgsGHA.1284@TK2MSFTNGP05.phx.gbl...
> How are the clients configured for internet access? Are they using a
> proxy w/ or without proxy client, router, NAT? And if so, what is the IP
> address of the Internet egress point?
>
> Jason
>
>
> "Greg O" wrote in message
> news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>I reloaded the 2003 operating system to make sure it wasn't a recent patch
>>causing problems, it just has service pack 1 so far. Before it was fully
>>patched. For example:
>>
>> Any <-> 192.168.0.0, Block
>> 192.168.1.5 <-> 192.168.0.10 Permit
>>
>> This internal connection would work. If I however add a rule:
>>
>> 192.168.0.10 <-> 200.199.136.200 Permit
>>
>> then this would not work because it is outside the network, i.e. the
>> internet. This is a made up external IP address as an example, I have
>> tried many different external IP addresses with no success. I can show
>> this is a problem in IPSEC (that is, not a firewall or other issue) by
>> removing the general block i.e. remove
>> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
>> external web site. The general block seems to override the Permit even
>> though it has a lower weighting. I did confirm the weighting of the
>> general block is lower in IP monitor. I believe ipseccmd is not used in
>> server 2003, at least it is not recognized. I assume there is a netsh
>> equivalent command.
>>
>>
>> "Jason Popp [MSFT]" wrote in message
>> news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>>> Can you list the actual filters you have deployed? From the description
>>> in the google link it wasn't clear to me...
>>> e.g. Any < - > 192.168.0.0/24, Permit
>>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>>
>>>
>>> Jason
>>>
>>> "Greg O" wrote in message
>>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>>> The weights and filters are listed properly (checked in IPSEC monitor),
>>>> they just don't work. If I make a general block say from internal
>>>> subnet A to B (for example 192.168.0.0 to 192.168.1.0) and then give a
>>>> more specific permit to 192.168.0.0 to say 192.168.1.15 then anyone on
>>>> 192.168.0.0 should be able to receive from 192.168.1.15. In fact if I
>>>> do this it works perfectly. If I however change the 192.168.1.15 to an
>>>> external IP address say of a web site, then it doesn't work. If I then
>>>> disable the block it starts to work. It seems like a bug in IPSEC
>>>> itself because it only fails on external addresses not internal ones.
>>>> The more specific filter should override the general one but it doesn't
>>>> on external IP addresses.
>>>>
>>>> I wanted to only allow specific web sites into the network and block
>>>> all others for safety reasons.
>>>>
>>>>
>>>>
>>>>
>>>> "Jason Popp [MSFT]" wrote in
>>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>>> Have you pulled a list of the filters (and their associated weights)
>>>>> from the IPsec monitor? Are the weights listed properly but not
>>>>> working as expected or are they listed out of the order you are
>>>>> expecting?
>>>>>
>>>>> I don't have an XP box in front of me to check, but can you also pull
>>>>> the active policy using ipseccmd to look at the active filters?
>>>>>
>>>>> Jason
>>>>>
>>>>> "Greg O" wrote in message
>>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>>> Hi,
>>>>>> I have explained the problem in another thread in the security
>>>>>> newsgroup:
>>>>>>
>>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>>
>>>>>> It seems to be a big in IPSEC as it filas to allow a connection to
>>>>>> the Internet but does it for an internal address.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

If you can provide an overview of how your network is set up for internet
access and what configs the clients use for Internet access in addition to
the data I noted in the last post above (netsh policy output, IKE / Oakley
log, IKEDiagnostics etc.) I can do more to take a look. Without the
additional detail it's pretty tough to speculate as to the exact cause of
the failure.

Jason


"Greg O" wrote in message
news:u0Aq84hsGHA.1272@TK2MSFTNGP05.phx.gbl...
> It cannot be any other problem since if I unassign the policy all subnets
> can connect to the internet and to each other. If I assign the policy no
> one can access the internet even the web sites I explicitly permit.If I
> permit an internal IP address (i.e. one on the network) then IPSEC allows
> it. It just won't allow any external IP addresses. I can even get a
> working rule permitting and internal IP address, e.g. 192.168.0.10 <->
> 192.168.1.10 permit and this will work. If I change this rule to
> 192.168.0.10 <-> 200.199.198.197 permit then it stops working. The weight
> should be the same since I only changed the IP address on the same part of
> the rule.
>
> I know it seems odd, I can only think it is a fault in IPSEC for some
> reason. Maybe if you tried it yourself you could see for yourself. It's
> annoying because I wanted to allow specific web sites and block all others
> for safety reasons. It may be another Microsoft product is supposed to do
> this instead and they intend people to upgrade. Does ISA do this for
> example, though not with IPSEC of course.
>
>
> "Jason Popp [MSFT]" wrote in message
> news:%23ZNrBGgsGHA.1284@TK2MSFTNGP05.phx.gbl...
>> How are the clients configured for internet access? Are they using a
>> proxy w/ or without proxy client, router, NAT? And if so, what is the IP
>> address of the Internet egress point?
>>
>> Jason
>>
>>
>> "Greg O" wrote in message
>> news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>>I reloaded the 2003 operating system to make sure it wasn't a recent
>>>patch causing problems, it just has service pack 1 so far. Before it was
>>>fully patched. For example:
>>>
>>> Any <-> 192.168.0.0, Block
>>> 192.168.1.5 <-> 192.168.0.10 Permit
>>>
>>> This internal connection would work. If I however add a rule:
>>>
>>> 192.168.0.10 <-> 200.199.136.200 Permit
>>>
>>> then this would not work because it is outside the network, i.e. the
>>> internet. This is a made up external IP address as an example, I have
>>> tried many different external IP addresses with no success. I can show
>>> this is a problem in IPSEC (that is, not a firewall or other issue) by
>>> removing the general block i.e. remove
>>> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
>>> external web site. The general block seems to override the Permit even
>>> though it has a lower weighting. I did confirm the weighting of the
>>> general block is lower in IP monitor. I believe ipseccmd is not used in
>>> server 2003, at least it is not recognized. I assume there is a netsh
>>> equivalent command.
>>>
>>>
>>> "Jason Popp [MSFT]" wrote in
>>> message news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>>>> Can you list the actual filters you have deployed? From the
>>>> description in the google link it wasn't clear to me...
>>>> e.g. Any < - > 192.168.0.0/24, Permit
>>>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>>>
>>>>
>>>> Jason
>>>>
>>>> "Greg O" wrote in message
>>>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>>>> The weights and filters are listed properly (checked in IPSEC
>>>>> monitor), they just don't work. If I make a general block say from
>>>>> internal subnet A to B (for example 192.168.0.0 to 192.168.1.0) and
>>>>> then give a more specific permit to 192.168.0.0 to say 192.168.1.15
>>>>> then anyone on 192.168.0.0 should be able to receive from
>>>>> 192.168.1.15. In fact if I do this it works perfectly. If I however
>>>>> change the 192.168.1.15 to an external IP address say of a web site,
>>>>> then it doesn't work. If I then disable the block it starts to work.
>>>>> It seems like a bug in IPSEC itself because it only fails on external
>>>>> addresses not internal ones. The more specific filter should override
>>>>> the general one but it doesn't on external IP addresses.
>>>>>
>>>>> I wanted to only allow specific web sites into the network and block
>>>>> all others for safety reasons.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Jason Popp [MSFT]" wrote in
>>>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>>>> Have you pulled a list of the filters (and their associated weights)
>>>>>> from the IPsec monitor? Are the weights listed properly but not
>>>>>> working as expected or are they listed out of the order you are
>>>>>> expecting?
>>>>>>
>>>>>> I don't have an XP box in front of me to check, but can you also pull
>>>>>> the active policy using ipseccmd to look at the active filters?
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> "Greg O" wrote in message
>>>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>>>> Hi,
>>>>>>> I have explained the problem in another thread in the security
>>>>>>> newsgroup:
>>>>>>>
>>>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>>>
>>>>>>> It seems to be a big in IPSEC as it filas to allow a connection to
>>>>>>> the Internet but does it for an internal address.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Believe me, I appreciate your time and help in this. I just don't think
there is anything wrong with my setup. I would love to be wrong though.

There are two servers, one is Server 2003 standard (called here Standard)
and the other is SBS 2003 (called here SBS). I use RRAS on the Standard
server which connects to the Internet and uses NAT. Connected to the
Standard server are 4 subnets, all 192.168.xxx.xxx. All currently have
internet access and all connect successfully to the Internet. I also use a
script to turn the internet on and off on subnet 3. I do this using a netsh
script which assigns two IPSEC plicies and then I alternate between the two
Policies using Scheduled Tasks. IPSEC Policy One blocks port 80, and also
8080 and 3128 (which are often used for proxies) and leaves everything else
open. This is 192.168.3.0 <-> any TCP Port 80 block (and the same for the
other ports 8080 and 3128). I would like to permit selected web sites, that
is, block port 80 for all but a few web sites. To do this I should be able
to permit a particular web site's IP address to subnet 3, and because it is
a more specific rule it has a higher weighting. I checked this in IPSEC
monitor. However the rule doesn't work, the selected web sites don't work
because the port 80 block continues to override them. If I remove the port
80 block then the web sites are accessible which leads me to believe there
is no other fault in the network. Also if I unassign the Policy One the web
sites are also accessible.

I also use a second policy, IPSEC Policy Two. This has a general rule which
blocks all traffic from subnet 3 to anywhere else on the network or
externally. In other words 192.168.3.0 <-> any, block. Then I have
192.168.3.0 <-> 192.168.1.0 Permit, 192.168.3.0 <-> 192.168.4.0 Permit. This
allows the users on subnet 3 to reach any other computer on subnets 1 and 4,
but blocks access to subnet 2 and the Internet. So the IPSEC more specific
rules work correctly here. If I then want to allow specific web sites I
should be able to add 192.168.3.0 <-> 200.199.198.97, Ports any, Protocols
any, Permit and this IP address (external to the network) should be
accessible to all on subnet 3. 200.199.198.197 is an example of a web site
address, I have tried addresses of for example newspapers online and none of
them work.

The IPSEC Policy is a Local Security Policy on the Standard server which is
also the gateway to the Internet. The SBS server is not relevant here as it
has no IPSEC policy, and the connections of the various subnets are all to
the Standard server. So subnet 3 for example (192.168.3.0) connects to a
network adaptor on the Standard server which has the IPSEC Local Policy, and
a second network adaptor on the Standard server connects to a cable modem.

I don't use Kerberos or any kind of encryption so there is no key
exchanges, etc. I just use IPSEC to block access as described.


"Jason Popp [MSFT]" wrote in message
news:emJdhXlsGHA.1224@TK2MSFTNGP03.phx.gbl...
> If you can provide an overview of how your network is set up for internet
> access and what configs the clients use for Internet access in addition to
> the data I noted in the last post above (netsh policy output, IKE / Oakley
> log, IKEDiagnostics etc.) I can do more to take a look. Without the
> additional detail it's pretty tough to speculate as to the exact cause of
> the failure.
>
> Jason
>
>
> "Greg O" wrote in message
> news:u0Aq84hsGHA.1272@TK2MSFTNGP05.phx.gbl...
>> It cannot be any other problem since if I unassign the policy all subnets
>> can connect to the internet and to each other. If I assign the policy no
>> one can access the internet even the web sites I explicitly permit.If I
>> permit an internal IP address (i.e. one on the network) then IPSEC allows
>> it. It just won't allow any external IP addresses. I can even get a
>> working rule permitting and internal IP address, e.g. 192.168.0.10 <->
>> 192.168.1.10 permit and this will work. If I change this rule to
>> 192.168.0.10 <-> 200.199.198.197 permit then it stops working. The weight
>> should be the same since I only changed the IP address on the same part
>> of the rule.
>>
>> I know it seems odd, I can only think it is a fault in IPSEC for some
>> reason. Maybe if you tried it yourself you could see for yourself. It's
>> annoying because I wanted to allow specific web sites and block all
>> others for safety reasons. It may be another Microsoft product is
>> supposed to do this instead and they intend people to upgrade. Does ISA
>> do this for example, though not with IPSEC of course.
>>
>>
>> "Jason Popp [MSFT]" wrote in message
>> news:%23ZNrBGgsGHA.1284@TK2MSFTNGP05.phx.gbl...
>>> How are the clients configured for internet access? Are they using a
>>> proxy w/ or without proxy client, router, NAT? And if so, what is the
>>> IP address of the Internet egress point?
>>>
>>> Jason
>>>
>>>
>>> "Greg O" wrote in message
>>> news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>>>I reloaded the 2003 operating system to make sure it wasn't a recent
>>>>patch causing problems, it just has service pack 1 so far. Before it was
>>>>fully patched. For example:
>>>>
>>>> Any <-> 192.168.0.0, Block
>>>> 192.168.1.5 <-> 192.168.0.10 Permit
>>>>
>>>> This internal connection would work. If I however add a rule:
>>>>
>>>> 192.168.0.10 <-> 200.199.136.200 Permit
>>>>
>>>> then this would not work because it is outside the network, i.e. the
>>>> internet. This is a made up external IP address as an example, I have
>>>> tried many different external IP addresses with no success. I can show
>>>> this is a problem in IPSEC (that is, not a firewall or other issue) by
>>>> removing the general block i.e. remove
>>>> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
>>>> external web site. The general block seems to override the Permit even
>>>> though it has a lower weighting. I did confirm the weighting of the
>>>> general block is lower in IP monitor. I believe ipseccmd is not used in
>>>> server 2003, at least it is not recognized. I assume there is a netsh
>>>> equivalent command.
>>>>
>>>>
>>>> "Jason Popp [MSFT]" wrote in
>>>> message news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>>>>> Can you list the actual filters you have deployed? From the
>>>>> description in the google link it wasn't clear to me...
>>>>> e.g. Any < - > 192.168.0.0/24, Permit
>>>>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>>>>
>>>>>
>>>>> Jason
>>>>>
>>>>> "Greg O" wrote in message
>>>>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>>>>> The weights and filters are listed properly (checked in IPSEC
>>>>>> monitor), they just don't work. If I make a general block say from
>>>>>> internal subnet A to B (for example 192.168.0.0 to 192.168.1.0) and
>>>>>> then give a more specific permit to 192.168.0.0 to say 192.168.1.15
>>>>>> then anyone on 192.168.0.0 should be able to receive from
>>>>>> 192.168.1.15. In fact if I do this it works perfectly. If I however
>>>>>> change the 192.168.1.15 to an external IP address say of a web site,
>>>>>> then it doesn't work. If I then disable the block it starts to work.
>>>>>> It seems like a bug in IPSEC itself because it only fails on external
>>>>>> addresses not internal ones. The more specific filter should override
>>>>>> the general one but it doesn't on external IP addresses.
>>>>>>
>>>>>> I wanted to only allow specific web sites into the network and block
>>>>>> all others for safety reasons.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Jason Popp [MSFT]" wrote in
>>>>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>>>>> Have you pulled a list of the filters (and their associated weights)
>>>>>>> from the IPsec monitor? Are the weights listed properly but not
>>>>>>> working as expected or are they listed out of the order you are
>>>>>>> expecting?
>>>>>>>
>>>>>>> I don't have an XP box in front of me to check, but can you also
>>>>>>> pull the active policy using ipseccmd to look at the active filters?
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> "Greg O" wrote in message
>>>>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>>>>> Hi,
>>>>>>>> I have explained the problem in another thread in the security
>>>>>>>> newsgroup:
>>>>>>>>
>>>>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>>>>
>>>>>>>> It seems to be a big in IPSEC as it filas to allow a connection to
>>>>>>>> the Internet but does it for an internal address.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

I don't see it as a matter of right or wrong either. I think that you are
correct in your understanding of how the filters should be set up and I
agree that the logic behind the policy is sound. However I think that the
issue comes down to the actual Source and Destination IP addresses being
used by RRAS to handle the internet-bound packets that are at the root of
this problem.

My understanding is that as the clients send the internet-bound traffic to
the RRAS server. The RRAS server changes the Source address of the incoming
packets to its externally facing NIC for the configured NAT/ address mapping
functionality, all of which takes place before the IPsec packet filter is
applied at the IPsec layer. As a result, when the stack finally checks the
IPsec policy database for a matching permit/block filter, it does not match
the outbound packet since it's source address no longer matches the subnet
you defined for the permit. Because you only have the filters on the RRAS
server the packets destined for the internet, when filtered by specific IP's
don't match.

To support this theory and your first policy scenario, I'd change the Permit
rule for the external web site to use the External IP address of the RRAS
system. The only issue is that if that does work to enable you to continue
controlling access at the RRAS server level, I can't see a way to make that
work with the subnet-specific rules you note for policy two short of having
to deploy the IPsec policies to the actual clients on the subnet.

All that being said, I am not an RRAS expert so in order to confirm my
theory I would have to look at a network sniff of the external web site
connection attempt along with the other detailed logs that I noted in my
earlier posts to understand the state of the traffic being exchanged...

I pulled my RRAS references from the following online doc:
http://technet2.microsoft.com/Window....mspx?mfr=true
Section titled "Outgoing and Incoming Packet Translation"

Jason


"Greg O" wrote in message
news:eccSinlsGHA.3952@TK2MSFTNGP03.phx.gbl...
> Believe me, I appreciate your time and help in this. I just don't think
> there is anything wrong with my setup. I would love to be wrong though.
>
> There are two servers, one is Server 2003 standard (called here Standard)
> and the other is SBS 2003 (called here SBS). I use RRAS on the Standard
> server which connects to the Internet and uses NAT. Connected to the
> Standard server are 4 subnets, all 192.168.xxx.xxx. All currently have
> internet access and all connect successfully to the Internet. I also use a
> script to turn the internet on and off on subnet 3. I do this using a
> netsh script which assigns two IPSEC plicies and then I alternate between
> the two Policies using Scheduled Tasks. IPSEC Policy One blocks port 80,
> and also 8080 and 3128 (which are often used for proxies) and leaves
> everything else open. This is 192.168.3.0 <-> any TCP Port 80 block (and
> the same for the other ports 8080 and 3128). I would like to permit
> selected web sites, that is, block port 80 for all but a few web sites. To
> do this I should be able to permit a particular web site's IP address to
> subnet 3, and because it is a more specific rule it has a higher
> weighting. I checked this in IPSEC monitor. However the rule doesn't work,
> the selected web sites don't work because the port 80 block continues to
> override them. If I remove the port 80 block then the web sites are
> accessible which leads me to believe there is no other fault in the
> network. Also if I unassign the Policy One the web sites are also
> accessible.
>
> I also use a second policy, IPSEC Policy Two. This has a general rule
> which blocks all traffic from subnet 3 to anywhere else on the network or
> externally. In other words 192.168.3.0 <-> any, block. Then I have
> 192.168.3.0 <-> 192.168.1.0 Permit, 192.168.3.0 <-> 192.168.4.0 Permit.
> This allows the users on subnet 3 to reach any other computer on subnets 1
> and 4, but blocks access to subnet 2 and the Internet. So the IPSEC more
> specific rules work correctly here. If I then want to allow specific web
> sites I should be able to add 192.168.3.0 <-> 200.199.198.97, Ports any,
> Protocols any, Permit and this IP address (external to the network)
> should be accessible to all on subnet 3. 200.199.198.197 is an example of
> a web site address, I have tried addresses of for example newspapers
> online and none of them work.
>
> The IPSEC Policy is a Local Security Policy on the Standard server which
> is also the gateway to the Internet. The SBS server is not relevant here
> as it has no IPSEC policy, and the connections of the various subnets are
> all to the Standard server. So subnet 3 for example (192.168.3.0) connects
> to a network adaptor on the Standard server which has the IPSEC Local
> Policy, and a second network adaptor on the Standard server connects to a
> cable modem.
>
> I don't use Kerberos or any kind of encryption so there is no key
> exchanges, etc. I just use IPSEC to block access as described.
>
>
> "Jason Popp [MSFT]" wrote in message
> news:emJdhXlsGHA.1224@TK2MSFTNGP03.phx.gbl...
>> If you can provide an overview of how your network is set up for internet
>> access and what configs the clients use for Internet access in addition
>> to the data I noted in the last post above (netsh policy output, IKE /
>> Oakley log, IKEDiagnostics etc.) I can do more to take a look. Without
>> the additional detail it's pretty tough to speculate as to the exact
>> cause of the failure.
>>
>> Jason
>>
>>
>> "Greg O" wrote in message
>> news:u0Aq84hsGHA.1272@TK2MSFTNGP05.phx.gbl...
>>> It cannot be any other problem since if I unassign the policy all
>>> subnets can connect to the internet and to each other. If I assign the
>>> policy no one can access the internet even the web sites I explicitly
>>> permit.If I permit an internal IP address (i.e. one on the network) then
>>> IPSEC allows it. It just won't allow any external IP addresses. I can
>>> even get a working rule permitting and internal IP address, e.g.
>>> 192.168.0.10 <-> 192.168.1.10 permit and this will work. If I change
>>> this rule to 192.168.0.10 <-> 200.199.198.197 permit then it stops
>>> working. The weight should be the same since I only changed the IP
>>> address on the same part of the rule.
>>>
>>> I know it seems odd, I can only think it is a fault in IPSEC for some
>>> reason. Maybe if you tried it yourself you could see for yourself. It's
>>> annoying because I wanted to allow specific web sites and block all
>>> others for safety reasons. It may be another Microsoft product is
>>> supposed to do this instead and they intend people to upgrade. Does ISA
>>> do this for example, though not with IPSEC of course.
>>>
>>>
>>> "Jason Popp [MSFT]" wrote in
>>> message news:%23ZNrBGgsGHA.1284@TK2MSFTNGP05.phx.gbl...
>>>> How are the clients configured for internet access? Are they using a
>>>> proxy w/ or without proxy client, router, NAT? And if so, what is the
>>>> IP address of the Internet egress point?
>>>>
>>>> Jason
>>>>
>>>>
>>>> "Greg O" wrote in message
>>>> news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>>>>I reloaded the 2003 operating system to make sure it wasn't a recent
>>>>>patch causing problems, it just has service pack 1 so far. Before it
>>>>>was fully patched. For example:
>>>>>
>>>>> Any <-> 192.168.0.0, Block
>>>>> 192.168.1.5 <-> 192.168.0.10 Permit
>>>>>
>>>>> This internal connection would work. If I however add a rule:
>>>>>
>>>>> 192.168.0.10 <-> 200.199.136.200 Permit
>>>>>
>>>>> then this would not work because it is outside the network, i.e. the
>>>>> internet. This is a made up external IP address as an example, I have
>>>>> tried many different external IP addresses with no success. I can show
>>>>> this is a problem in IPSEC (that is, not a firewall or other issue)
>>>>> by removing the general block i.e. remove
>>>>> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
>>>>> external web site. The general block seems to override the Permit even
>>>>> though it has a lower weighting. I did confirm the weighting of the
>>>>> general block is lower in IP monitor. I believe ipseccmd is not used
>>>>> in server 2003, at least it is not recognized. I assume there is a
>>>>> netsh equivalent command.
>>>>>
>>>>>
>>>>> "Jason Popp [MSFT]" wrote in
>>>>> message news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>>>>>> Can you list the actual filters you have deployed? From the
>>>>>> description in the google link it wasn't clear to me...
>>>>>> e.g. Any < - > 192.168.0.0/24, Permit
>>>>>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> "Greg O" wrote in message
>>>>>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>>>>>> The weights and filters are listed properly (checked in IPSEC
>>>>>>> monitor), they just don't work. If I make a general block say from
>>>>>>> internal subnet A to B (for example 192.168.0.0 to 192.168.1.0) and
>>>>>>> then give a more specific permit to 192.168.0.0 to say 192.168.1.15
>>>>>>> then anyone on 192.168.0.0 should be able to receive from
>>>>>>> 192.168.1.15. In fact if I do this it works perfectly. If I however
>>>>>>> change the 192.168.1.15 to an external IP address say of a web site,
>>>>>>> then it doesn't work. If I then disable the block it starts to work.
>>>>>>> It seems like a bug in IPSEC itself because it only fails on
>>>>>>> external addresses not internal ones. The more specific filter
>>>>>>> should override the general one but it doesn't on external IP
>>>>>>> addresses.
>>>>>>>
>>>>>>> I wanted to only allow specific web sites into the network and block
>>>>>>> all others for safety reasons.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Jason Popp [MSFT]" wrote in
>>>>>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>>>>>> Have you pulled a list of the filters (and their associated
>>>>>>>> weights) from the IPsec monitor? Are the weights listed properly
>>>>>>>> but not working as expected or are they listed out of the order you
>>>>>>>> are expecting?
>>>>>>>>
>>>>>>>> I don't have an XP box in front of me to check, but can you also
>>>>>>>> pull the active policy using ipseccmd to look at the active
>>>>>>>> filters?
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> "Greg O" wrote in message
>>>>>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>>>>>> Hi,
>>>>>>>>> I have explained the problem in another thread in the security
>>>>>>>>> newsgroup:
>>>>>>>>>
>>>>>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>>>>>
>>>>>>>>> It seems to be a big in IPSEC as it filas to allow a connection to
>>>>>>>>> the Internet but does it for an internal address.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

I tried earlier using the IP address of the external network adaptor (i.e.
the one connected to the cable modem) but that didn't help. There is another
setting in IPSEC, to use a dynamic gateway which may be an attempt to get
around this problem. However when I try that e.g. dynamic gateway <->
192.168.3.0 block people can still get the Internet, so I'm not sure what it
is supposed to be blocking.

Yes it looks as though IPSEC cannot allow individual web sites. It's a shame
because it would be very useful for security. One way perhaps is if people
use remote desktop onto the gateway computer which isn't using NAT, then
perhaps their use of a browser could be controlled with IPSEC. This would
still be ok as internet access would all be through remote desktop instead
of RRAS.

Do you know if ISA can filter traffic to only allow selected web sites for a
particular subnet?



"Jason Popp [MSFT]" wrote in message
news:%23QsRoKpsGHA.1224@TK2MSFTNGP03.phx.gbl...
>I don't see it as a matter of right or wrong either. I think that you are
>correct in your understanding of how the filters should be set up and I
>agree that the logic behind the policy is sound. However I think that the
>issue comes down to the actual Source and Destination IP addresses being
>used by RRAS to handle the internet-bound packets that are at the root of
>this problem.
>
> My understanding is that as the clients send the internet-bound traffic to
> the RRAS server. The RRAS server changes the Source address of the
> incoming packets to its externally facing NIC for the configured NAT/
> address mapping functionality, all of which takes place before the IPsec
> packet filter is applied at the IPsec layer. As a result, when the stack
> finally checks the IPsec policy database for a matching permit/block
> filter, it does not match the outbound packet since it's source address no
> longer matches the subnet you defined for the permit. Because you only
> have the filters on the RRAS server the packets destined for the internet,
> when filtered by specific IP's don't match.
>
> To support this theory and your first policy scenario, I'd change the
> Permit rule for the external web site to use the External IP address of
> the RRAS system. The only issue is that if that does work to enable you
> to continue controlling access at the RRAS server level, I can't see a way
> to make that work with the subnet-specific rules you note for policy two
> short of having to deploy the IPsec policies to the actual clients on the
> subnet.
>
> All that being said, I am not an RRAS expert so in order to confirm my
> theory I would have to look at a network sniff of the external web site
> connection attempt along with the other detailed logs that I noted in my
> earlier posts to understand the state of the traffic being exchanged...
>
> I pulled my RRAS references from the following online doc:
> http://technet2.microsoft.com/Window....mspx?mfr=true
> Section titled "Outgoing and Incoming Packet Translation"
>
> Jason
>
>
> "Greg O" wrote in message
> news:eccSinlsGHA.3952@TK2MSFTNGP03.phx.gbl...
>> Believe me, I appreciate your time and help in this. I just don't think
>> there is anything wrong with my setup. I would love to be wrong though.
>>
>> There are two servers, one is Server 2003 standard (called here Standard)
>> and the other is SBS 2003 (called here SBS). I use RRAS on the Standard
>> server which connects to the Internet and uses NAT. Connected to the
>> Standard server are 4 subnets, all 192.168.xxx.xxx. All currently have
>> internet access and all connect successfully to the Internet. I also use
>> a script to turn the internet on and off on subnet 3. I do this using a
>> netsh script which assigns two IPSEC plicies and then I alternate between
>> the two Policies using Scheduled Tasks. IPSEC Policy One blocks port 80,
>> and also 8080 and 3128 (which are often used for proxies) and leaves
>> everything else open. This is 192.168.3.0 <-> any TCP Port 80 block (and
>> the same for the other ports 8080 and 3128). I would like to permit
>> selected web sites, that is, block port 80 for all but a few web sites.
>> To do this I should be able to permit a particular web site's IP address
>> to subnet 3, and because it is a more specific rule it has a higher
>> weighting. I checked this in IPSEC monitor. However the rule doesn't
>> work, the selected web sites don't work because the port 80 block
>> continues to override them. If I remove the port 80 block then the web
>> sites are accessible which leads me to believe there is no other fault in
>> the network. Also if I unassign the Policy One the web sites are also
>> accessible.
>>
>> I also use a second policy, IPSEC Policy Two. This has a general rule
>> which blocks all traffic from subnet 3 to anywhere else on the network or
>> externally. In other words 192.168.3.0 <-> any, block. Then I have
>> 192.168.3.0 <-> 192.168.1.0 Permit, 192.168.3.0 <-> 192.168.4.0 Permit.
>> This allows the users on subnet 3 to reach any other computer on subnets
>> 1 and 4, but blocks access to subnet 2 and the Internet. So the IPSEC
>> more specific rules work correctly here. If I then want to allow specific
>> web sites I should be able to add 192.168.3.0 <-> 200.199.198.97, Ports
>> any, Protocols any, Permit and this IP address (external to the network)
>> should be accessible to all on subnet 3. 200.199.198.197 is an example of
>> a web site address, I have tried addresses of for example newspapers
>> online and none of them work.
>>
>> The IPSEC Policy is a Local Security Policy on the Standard server which
>> is also the gateway to the Internet. The SBS server is not relevant here
>> as it has no IPSEC policy, and the connections of the various subnets are
>> all to the Standard server. So subnet 3 for example (192.168.3.0)
>> connects to a network adaptor on the Standard server which has the IPSEC
>> Local Policy, and a second network adaptor on the Standard server
>> connects to a cable modem.
>>
>> I don't use Kerberos or any kind of encryption so there is no key
>> exchanges, etc. I just use IPSEC to block access as described.
>>
>>
>> "Jason Popp [MSFT]" wrote in message
>> news:emJdhXlsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>> If you can provide an overview of how your network is set up for
>>> internet access and what configs the clients use for Internet access in
>>> addition to the data I noted in the last post above (netsh policy
>>> output, IKE / Oakley log, IKEDiagnostics etc.) I can do more to take a
>>> look. Without the additional detail it's pretty tough to speculate as
>>> to the exact cause of the failure.
>>>
>>> Jason
>>>
>>>
>>> "Greg O" wrote in message
>>> news:u0Aq84hsGHA.1272@TK2MSFTNGP05.phx.gbl...
>>>> It cannot be any other problem since if I unassign the policy all
>>>> subnets can connect to the internet and to each other. If I assign the
>>>> policy no one can access the internet even the web sites I explicitly
>>>> permit.If I permit an internal IP address (i.e. one on the network)
>>>> then IPSEC allows it. It just won't allow any external IP addresses. I
>>>> can even get a working rule permitting and internal IP address, e.g.
>>>> 192.168.0.10 <-> 192.168.1.10 permit and this will work. If I change
>>>> this rule to 192.168.0.10 <-> 200.199.198.197 permit then it stops
>>>> working. The weight should be the same since I only changed the IP
>>>> address on the same part of the rule.
>>>>
>>>> I know it seems odd, I can only think it is a fault in IPSEC for some
>>>> reason. Maybe if you tried it yourself you could see for yourself. It's
>>>> annoying because I wanted to allow specific web sites and block all
>>>> others for safety reasons. It may be another Microsoft product is
>>>> supposed to do this instead and they intend people to upgrade. Does ISA
>>>> do this for example, though not with IPSEC of course.
>>>>
>>>>
>>>> "Jason Popp [MSFT]" wrote in
>>>> message news:%23ZNrBGgsGHA.1284@TK2MSFTNGP05.phx.gbl...
>>>>> How are the clients configured for internet access? Are they using a
>>>>> proxy w/ or without proxy client, router, NAT? And if so, what is the
>>>>> IP address of the Internet egress point?
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>> "Greg O" wrote in message
>>>>> news:utwtt9fsGHA.1224@TK2MSFTNGP03.phx.gbl...
>>>>>>I reloaded the 2003 operating system to make sure it wasn't a recent
>>>>>>patch causing problems, it just has service pack 1 so far. Before it
>>>>>>was fully patched. For example:
>>>>>>
>>>>>> Any <-> 192.168.0.0, Block
>>>>>> 192.168.1.5 <-> 192.168.0.10 Permit
>>>>>>
>>>>>> This internal connection would work. If I however add a rule:
>>>>>>
>>>>>> 192.168.0.10 <-> 200.199.136.200 Permit
>>>>>>
>>>>>> then this would not work because it is outside the network, i.e. the
>>>>>> internet. This is a made up external IP address as an example, I have
>>>>>> tried many different external IP addresses with no success. I can
>>>>>> show this is a problem in IPSEC (that is, not a firewall or other
>>>>>> issue) by removing the general block i.e. remove
>>>>>> Any <-> 192.168.0.0, Block and then 192.168.0.10 can connect to any
>>>>>> external web site. The general block seems to override the Permit
>>>>>> even though it has a lower weighting. I did confirm the weighting of
>>>>>> the general block is lower in IP monitor. I believe ipseccmd is not
>>>>>> used in server 2003, at least it is not recognized. I assume there is
>>>>>> a netsh equivalent command.
>>>>>>
>>>>>>
>>>>>> "Jason Popp [MSFT]" wrote in
>>>>>> message news:uiTHKHMsGHA.452@TK2MSFTNGP05.phx.gbl...
>>>>>>> Can you list the actual filters you have deployed? From the
>>>>>>> description in the google link it wasn't clear to me...
>>>>>>> e.g. Any < - > 192.168.0.0/24, Permit
>>>>>>> e.g. Me < - > 192.168.0.5, TCP/80 Block
>>>>>>>
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> "Greg O" wrote in message
>>>>>>> news:O2a0NLvrGHA.4912@TK2MSFTNGP05.phx.gbl...
>>>>>>>> The weights and filters are listed properly (checked in IPSEC
>>>>>>>> monitor), they just don't work. If I make a general block say from
>>>>>>>> internal subnet A to B (for example 192.168.0.0 to 192.168.1.0) and
>>>>>>>> then give a more specific permit to 192.168.0.0 to say 192.168.1.15
>>>>>>>> then anyone on 192.168.0.0 should be able to receive from
>>>>>>>> 192.168.1.15. In fact if I do this it works perfectly. If I however
>>>>>>>> change the 192.168.1.15 to an external IP address say of a web
>>>>>>>> site, then it doesn't work. If I then disable the block it starts
>>>>>>>> to work. It seems like a bug in IPSEC itself because it only fails
>>>>>>>> on external addresses not internal ones. The more specific filter
>>>>>>>> should override the general one but it doesn't on external IP
>>>>>>>> addresses.
>>>>>>>>
>>>>>>>> I wanted to only allow specific web sites into the network and
>>>>>>>> block all others for safety reasons.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> "Jason Popp [MSFT]" wrote in
>>>>>>>> message news:O%23SueburGHA.4408@TK2MSFTNGP04.phx.gbl...
>>>>>>>>> Have you pulled a list of the filters (and their associated
>>>>>>>>> weights) from the IPsec monitor? Are the weights listed properly
>>>>>>>>> but not working as expected or are they listed out of the order
>>>>>>>>> you are expecting?
>>>>>>>>>
>>>>>>>>> I don't have an XP box in front of me to check, but can you also
>>>>>>>>> pull the active policy using ipseccmd to look at the active
>>>>>>>>> filters?
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>> "Greg O" wrote in message
>>>>>>>>> news:%23LVu1VjrGHA.3828@TK2MSFTNGP03.phx.gbl...
>>>>>>>>>> Hi,
>>>>>>>>>> I have explained the problem in another thread in the security
>>>>>>>>>> newsgroup:
>>>>>>>>>>
>>>>>>>>>> http://groups.google.com/group/micro...b4000d05280776
>>>>>>>>>>
>>>>>>>>>> It seems to be a big in IPSEC as it filas to allow a connection
>>>>>>>>>> to the Internet but does it for an internal address.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Hello Greg O,

IMHO (and correct me if I am wrong) your design is fundamentally wrong:
1. IPSec will always work when your policy set to block
2. IPSec will encrypt when your policy set to allow but how do you set up to
establish IPSec encryption with the destination?

--
J C
AEGON


"Greg O" wrote:

> Hi,
> I have explained the problem in another thread in the security newsgroup:
>
> http://groups.google.com/group/micro...b4000d05280776
>
> It seems to be a big in IPSEC as it filas to allow a connection to the
> Internet but does it for an internal address.
>
>
>