IPSec filter bug?

[Guest]

I'll try to keep this simple

I've got a multi-homed Win2K server with one NIC connected to the internet, and two other NICs connected to different local subnets. The goal is to allow the local subnets to access the internet, but not each other. I also need to support VPN. Since I have to use RRAS for VPN, I am using NAT with IP forwarding enabled (instead of ICS) to allow the local subnets to access the internet

So everything is working great, except the local subnets can now talk to each other because IP forwarding is enabled to support NAT. For technical reasons, I can't use packet filtering in RRAS to block this traffic. Which leaves IPSec

I set up an IPSec filter that blocks all packets going from subnet A to subnet B (using the "A specific IP Subnet" option for both source and destination). When I apply this filter, traffic between subnets is _not_ blocked. If I change the filter so that the destination is "Any IP Address", traffic from the source subnet is blocked. Unfortunately, it is blocked _everywhere_, so now I can't get to the internet. If I instead change the filter so the destination is "A specific IP Address", and enter the address of a host on subnet B, all traffic from subnet A destined for subnet B _is_ properly blocked. But going this route will require me to enter a filter for every host on both subnets (yuck!)

So, my question is: is this behavior by design? At first I thought maybe IP forwarding was short-circuiting something and bypassing the IPSec filters, but it appears that it's only "broken" for subnet-to-subnet filters. Any ideas

Thanks in advance

- Chris

 

[Herb Martin]

I set up an IPSec filter that blocks all packets going from subnet A to
subnet B (using the "A specific IP Subnet" option for both source and
destination). When I apply this filter, traffic between subnets is _not_
blocked. If I change the filter so that the destination is "Any IP
Address", traffic from the source subnet is blocked. Unfortunately, it is
blocked _everywhere_, so now I can't get to the internet. If I instead
change the filter so the destination is "A specific IP Address", and enter
the address of a host on subnet B, all traffic from subnet A destined for
subnet B _is_ properly blocked. But going this route will require me to
enter a filter for every host on both subnets (yuck!).
That doesn't jibe with experience, so perhaps you understanding
of "subnet" is different here.

Subnet means "machines matched by that subnet"
(subnet is just used shorthand for a group of machines) so traffic
can still come THROUGH that subnet, as long as it doesn't
originate with any of those Addresses.

So, my question is: is this behavior by design? At first I thought maybe

IP forwarding was short-circuiting something and bypassing the IPSec
filters, but it appears that it's only "broken" for subnet-to-subnet
filters. Any ideas?

No, blocking a subnet will disallow IP conversations with the matched
machines.

Either you filter is not correct, or something is askew.

--
Herb Martin

I'll try to keep this simple.

I've got a multi-homed Win2K server with one NIC connected to the

internet, and two other NICs connected to different local subnets. The goal
is to allow the local subnets to access the internet, but not each other. I
also need to support VPN. Since I have to use RRAS for VPN, I am using NAT
with IP forwarding enabled (instead of ICS) to allow the local subnets to
access the internet.

So everything is working great, except the local subnets can now talk to

each other because IP forwarding is enabled to support NAT. For technical
reasons, I can't use packet filtering in RRAS to block this traffic. Which
leaves IPSec.

 

[Chris]

Thanks for your reply.

Okay, after playing around with this, I have noticed the
exact same behavior in the RRAS filters as well. I still
believe there is a bug here. Let me boil this down to an
even simpler example, with some more specifics:

Let's say I have a Win2K server with 2 NICs installed,
configured as follows:

NIC A:
IP Address 192.168.0.1
Subnet Mask 255.255.255.0

NIC B:
IP Address 192.168.1.1
Subnet Mask 255.255.255.0

Hosts connected to NIC A
IP Address 192.168.0.<2-254>
Subnet Mask 255.255.255.0
Gateway 192.168.0.1

Hosts connected to NIC B
IP Address 192.168.1.<2-254>
Subnet Mask 255.255.255.0
Gateway 192.168.1.1

RRAS is running, with IP forwarding enabled.

Now, the goal is for hosts on both subnets to be able to
talk to the server, but not each other. (I realize that
having IP forwarding enabled is exactly what you would
NOT want to do to achieve this, but bear with me for the
purposes of this discussion.)

So, in it's default state, host 192.168.0.10 can ping
192.168.1.20 (because of IP forwarding). To prevent
this, I tried setting up an IP Filter in IPSec that
blocks all traffic between 192.168.0.0/24 and
192.168.1.0/24. This does NOT work -- the pings still go
through.

However, if I change the filter so that it is less
specific and blocks traffic between 192.168.0.0/24
and "everything", it works as expected. Or, if I make
the filter more specific and block traffic between
192.168.0.0/24 and 192.168.1.20, it works as expected.

I have verified the exact same behavior in the RRAS
packet filters as well -- setting an input or output
filter on one of the adapters to block traffic between
the subnets does NOT work, but making the filter more
general or more specific does work.

I know that this example is rather esoteric, but imagine
adding a 3rd NIC to the server, connected to the
Internet, and enabling NAT so the two subnets have web
access. In that case I do need IP forwarding enabled,
otherwise NAT won't work.

So, my question is still: is this behavior by design? I
would think that if IP forwarding were causing the stack
to shortcut from one subnet to the other, it would mean
that no filters would be able to block this traffic.
However, only the subnet-to-subnet filters fail, so I
would tend to think something else is going on.

If anyone has any ideas, or can suggest another way of
setting this up (using a single computer), I'm all
ears.

Thanks again in advance.

- Chris