IPSec Filter Question - Network

This is a discussion on IPSec Filter Question - Network ; I'm working on a server with 2 nics and trying to implement a fairly simple IPSec filter. Nic1 faces the network (172.16.8.131/255.255.248.0) Nic2 faces a private customer network (172.17.88.2/255.255.255.0) with 2 client PCs with 172.17.88.50 and .51 addresses. I have ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: IPSec Filter Question

  1. IPSec Filter Question

    I'm working on a server with 2 nics and trying to implement a fairly simple
    IPSec filter.

    Nic1 faces the network (172.16.8.131/255.255.248.0)
    Nic2 faces a private customer network (172.17.88.2/255.255.255.0) with 2
    client PCs with 172.17.88.50 and .51 addresses.

    I have created two filters. The first blocks any traffic from a subnet
    (172.17.88.0/255.255.255.0) to another subnet (172.16.0.0/255.255.0.0) This
    filter works beautifully, I cannot reach anything on the 172.16.x.x network
    from the 172.17.88.x subnet PCs

    The second filter PERMITS any traffic from the subnet 172.17.88.0 to a
    specific IP address of 172.16.8.152.

    As the second filter is more specific, I would have expected traffic to be
    able to pass to 172.16.8.152 because this filter will be encountered first.
    However, I cannot get to 172.16.8.152 no matter what I do from any client
    PCs on the 172.17.88.x subnet.

    However, if I change the second filter to PERMIT traffic from the subnet
    172.17.88.0 to the 172.16.8.0 subnet, I can get to 172.16.8.152 from the
    172.17.88.x subnet client PCs just fine.

    I just can't figure out why using the more specific filter (PERMIT to only
    172.16.8.152) doesn't work, yet a less-specific PERMIT filter (to
    172.16.8.0) does work?

    Thanks for any ideas or help on this, it's driving me nuts!


  2. Re: IPSec Filter Question

    To clarify, are your filters set up on each machine as follows:
    172.17.88.0/24 - > 172.16.0.0/16, Block, One-way Filter
    172.17.88.0/24 - > 172.16.8.152, Permit, One-way Filter

    What are the weights of the filters showing up in the IP Security Monitor
    UI?

    Jason


    "Chupacabra" wrote in message
    news:%23DG9%23nQrGHA.4992@TK2MSFTNGP05.phx.gbl...
    > I'm working on a server with 2 nics and trying to implement a fairly
    > simple IPSec filter.
    >
    > Nic1 faces the network (172.16.8.131/255.255.248.0)
    > Nic2 faces a private customer network (172.17.88.2/255.255.255.0) with 2
    > client PCs with 172.17.88.50 and .51 addresses.
    >
    > I have created two filters. The first blocks any traffic from a subnet
    > (172.17.88.0/255.255.255.0) to another subnet (172.16.0.0/255.255.0.0)
    > This filter works beautifully, I cannot reach anything on the 172.16.x.x
    > network from the 172.17.88.x subnet PCs
    >
    > The second filter PERMITS any traffic from the subnet 172.17.88.0 to a
    > specific IP address of 172.16.8.152.
    >
    > As the second filter is more specific, I would have expected traffic to be
    > able to pass to 172.16.8.152 because this filter will be encountered
    > first. However, I cannot get to 172.16.8.152 no matter what I do from any
    > client PCs on the 172.17.88.x subnet.
    >
    > However, if I change the second filter to PERMIT traffic from the subnet
    > 172.17.88.0 to the 172.16.8.0 subnet, I can get to 172.16.8.152 from the
    > 172.17.88.x subnet client PCs just fine.
    >
    > I just can't figure out why using the more specific filter (PERMIT to only
    > 172.16.8.152) doesn't work, yet a less-specific PERMIT filter (to
    > 172.16.8.0) does work?
    >
    > Thanks for any ideas or help on this, it's driving me nuts!
    >



  3. Re: IPSec Filter Question


    "Jason Popp [MSFT]" wrote in message
    news:exNu2PurGHA.1732@TK2MSFTNGP03.phx.gbl...

    > To clarify, are your filters set up on each machine as follows:
    > 172.17.88.0/24 - > 172.16.0.0/16, Block, One-way Filter
    > 172.17.88.0/24 - > 172.16.8.152, Permit, One-way Filter
    >
    > What are the weights of the filters showing up in the IP Security Monitor
    > UI?


    Maybe that's where I'm going wrong, but I only have the IPSec filters
    configured on the server, which is also acting as a router between the
    172.17.88 subnet and the 172.16.8 subnet? Although all the other filters
    work, it's just the one going directly to 172.16.8.152 that doesn't work.

    Weights are below:

    172.17.88.0/24 - > 172.16.0.0/16, Block, One-way Filter (Weight is
    57933824)
    172.17.88.0/24 - > 172.16.8.152, Permit, One-way Filter (Weight is
    66846721)

    I have tried using the Mirror option in every combination for both filters
    with no joy.

    Thanks for your help!


  4. Re: IPSec Filter Question

    I posted this accidentally to the above thread but here goes again:

    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) On a related note, have you tried adding the
    same IPsec policy to a client system as well as the RRAS box?

    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



    "Chupacabra" wrote in message
    news:OExrPNyrGHA.3324@TK2MSFTNGP02.phx.gbl...
    >
    > "Jason Popp [MSFT]" wrote in message
    > news:exNu2PurGHA.1732@TK2MSFTNGP03.phx.gbl...
    >
    >> To clarify, are your filters set up on each machine as follows:
    >> 172.17.88.0/24 - > 172.16.0.0/16, Block, One-way Filter
    >> 172.17.88.0/24 - > 172.16.8.152, Permit, One-way Filter
    >>
    >> What are the weights of the filters showing up in the IP Security Monitor
    >> UI?

    >
    > Maybe that's where I'm going wrong, but I only have the IPSec filters
    > configured on the server, which is also acting as a router between the
    > 172.17.88 subnet and the 172.16.8 subnet? Although all the other filters
    > work, it's just the one going directly to 172.16.8.152 that doesn't work.
    >
    > Weights are below:
    >
    > 172.17.88.0/24 - > 172.16.0.0/16, Block, One-way Filter (Weight is
    > 57933824)
    > 172.17.88.0/24 - > 172.16.8.152, Permit, One-way Filter (Weight is
    > 66846721)
    >
    > I have tried using the Mirror option in every combination for both filters
    > with no joy.
    >
    > Thanks for your help!
    >



  5. Re: IPSec Filter Question


    "Jason Popp [MSFT]" wrote in message
    news:%23vS$1GgsGHA.1208@TK2MSFTNGP02.phx.gbl...

    >I posted this accidentally to the above thread but here goes again:
    >
    > 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) On a related note, have you tried adding
    > the same IPsec policy to a client system as well as the RRAS box?
    >
    > 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)


    For now, applying the policies to the workstations does work, it just
    doesn't work to a specific IP on the server. For now, I think this will be
    sufficient.

    Thanks!



+ Reply to Thread