XP IPsec policy imported to Vista doesn't work - Network

This is a discussion on XP IPsec policy imported to Vista doesn't work - Network ; Hi, My wireless LAN at home doesn't use WEP or WPA. This is intentional. An OpenBSD-machine with a wireless LAN-card functions as an access point. To secure the traffic of my laptop over the WLAN, I use IPsec. This works ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: XP IPsec policy imported to Vista doesn't work

  1. XP IPsec policy imported to Vista doesn't work

    Hi,

    My wireless LAN at home doesn't use WEP or WPA. This is intentional. An
    OpenBSD-machine with a wireless LAN-card functions as an access point.
    To secure the traffic of my laptop over the WLAN, I use IPsec. This works
    great on Linux, OpenBSD and Windows XP. I can't get it to work on Vista
    though.

    The IP address of the wireless card in the access point is fixed:
    192.168.2.1 (on a /24 subnet). DHCP is not in use, so the wireless interface
    of the laptop also has a fixed IP address: 192.168.2.15. The default gateway
    of the laptop is 192.168.2.1.

    On everything but Vista, I use IPsec tunnel mode. I use tunnel mode, because
    *all* traffic between the wireless interface of the laptop and the wireless
    interface of the access point needs to be protected by IPsec.

    To do this, I created (on XP) two filter lists: "laptop -> gateway" has
    "My IP Address" as source address and "Any IP Address" as destination address
    ("Mirrored" is *not* selected). The other filter list "gateway -> laptop" is
    the reverse of "laptop -> gateway". I created one Filter Action, with
    "Negotiate Security" selected, and won't allow any non-IPsec-protected
    communication.

    With these two filter lists and one filter action, I created an IP Security
    Policy. I don't use the Default Response Rule, but created two IP Security
    Rules. Each Rule uses one IP Filter. The rule which uses the
    "laptop -> gateway" IP Filter has 192.168.2.1 as tunnel endpoint, and the
    rule which uses the "gateway -> laptop" IP Filter has 192.168.2.15 as tunnel
    endpoint. Both rules have the same Filter Action, Authentication Method
    (a certificate) and Connection Type (All network connections).

    With this configuration, when I select "Assign" in the MMC window, XP will
    successfully negotiate both Main Mode and Quick Mode security associations,
    and all wireless traffic is IPsec-protected.

    When I follow the exact same steps in Vista (Ultimate 32 bit, using the "IP
    Security Policies" MMC snap-in), traffic remains unprotected. Using a
    network sniffer on the access point, I'm not seeing any attempt to negotiate
    any security association. It seems as if the "assign policy" action doesn't
    actually do anything. I even exported and imported the policy from XP to
    Vista (which was successful), but even then the traffic remained unprotected
    after assigning the policy.

    This was with a fully up-to-date Vista (as of dec 28th), and I also tried with
    the SP1 release candidate.

    I tried to use the Advanced Firewall GUI to create a similar policy, but I
    wasn't able to specify the equivalent of "Any IP address" as destination
    address.

    What am I missing here? Do I need to do something extra on Vista, besides
    creating and assigning the policy?

    Thanks,
    --
    Jurjen Oskam

    Savage's Law of Expediency:
    You want it bad, you'll get it bad.

  2. Re: XP IPsec policy imported to Vista doesn't work

    On 2007-12-29, Jurjen Oskam wrote:

    > I tried to use the Advanced Firewall GUI to create a similar policy, but I
    > wasn't able to specify the equivalent of "Any IP address" as destination
    > address.

    I've been experimenting some more with this using netsh.

    This is what I want (note the endpointX=any):

    netsh advfirewall consec add rule name="gateway -> laptop" endpoint1=any endpoint2=192.168.2.15/255.255.255.255 action=requireinrequireout mode=tunnel enable=no localtunnelendpoint=192.168.2.1 remotetunnelendpoint=192.168.2.15 auth1=computercert auth1ca="C=NL, S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\', CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"

    netsh advfirewall consec add rule name="laptop -> gateway" endpoint1=192.168.2.15/255.255.255.255 endpoint2=any action=requireinrequireout mode=tunnel enable=no localtunnelendpoint=192.168.2.15 remotetunnelendpoint=192.168.2.1 auth1=computercert auth1ca="C=NL, S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\', CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"

    However, this results (for each netsh invocation) in the error message:

    "Endpoint 'any' cannot be specified for a tunnel mode rule"

    Hmm. According to the Vista advanced firewall help: "IPsec Tunnel Mode is not
    supported for remote access VPN scenarios. L2TP/IPsec or PPTP should be used
    for remote access VPN connections." This *did* work in XP, so it appears that
    this capability was removed from Vista for a reason. It also seems likely that
    this is the reason why the legacy MMC snap-in won't work. It's unfortunate
    that it silently fails though.


    The weird thing is that it *does* work, if you replace "any" with a list of
    every IP address on the Net (and some extra)?

    netsh advfirewall consec add rule name="gateway -> laptop" endpoint1=1.0.0.0-192.168.2.14,192.168.2.16-223.255.255.255 endpoint2=192.168.2.15/255.255.255.255 action=requireinrequireout mode=tunnel enable=no localtunnelendpoint=192.168.2.1 remotetunnelendpoint=192.168.2.15 auth1=computercert auth1ca="C=NL, S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\', CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"

    netsh advfirewall consec add rule name="laptop -> gateway" endpoint2=1.0.0.0-192.168.2.14,192.168.2.16-223.255.255.255 endpoint1=192.168.2.15/255.255.255.255 action=requireinrequireout mode=tunnel enable=no localtunnelendpoint=192.168.2.15 remotetunnelendpoint=192.168.2.1 auth1=computercert auth1ca="C=NL, S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\', CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"


    This is not optimal though. Why won't it Just Work(tm) like it did in XP? Why
    is this now "not supported" all of a sudden?
    --
    Jurjen Oskam

    Savage's Law of Expediency:
    You want it bad, you'll get it bad.

  3. Re: XP IPsec policy imported to Vista doesn't work

    I believe there was a big with the Policyagent portion of tunnel mode that
    was fixed in the final release of Vista SP1.

    Unfortunately the "dynamic tunnel" config with a destination of Any was not
    carried forward into Windows Vista 'Windows Firewall with Advanced Security'
    Policies.

    Jason



    "Jurjen Oskam" wrote in message
    news:slrnfncr1f.5dh.jurjen@calvin.stupendous.org.. .
    > On 2007-12-29, Jurjen Oskam wrote:
    >
    >> I tried to use the Advanced Firewall GUI to create a similar policy, but
    >> I
    >> wasn't able to specify the equivalent of "Any IP address" as destination
    >> address.
    >
    > I've been experimenting some more with this using netsh.
    >
    > This is what I want (note the endpointX=any):
    >
    > netsh advfirewall consec add rule name="gateway -> laptop" endpoint1=any
    > endpoint2=192.168.2.15/255.255.255.255 action=requireinrequireout
    > mode=tunnel enable=no localtunnelendpoint=192.168.2.1
    > remotetunnelendpoint=192.168.2.15 auth1=computercert auth1ca="C=NL,
    > S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\',
    > CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"
    >
    > netsh advfirewall consec add rule name="laptop -> gateway"
    > endpoint1=192.168.2.15/255.255.255.255 endpoint2=any
    > action=requireinrequireout mode=tunnel enable=no
    > localtunnelendpoint=192.168.2.15 remotetunnelendpoint=192.168.2.1
    > auth1=computercert auth1ca="C=NL, S=Zuid-Holland, L=Papendrecht,
    > O=Stupendous, OU=\'Certificate Authority\',
    > CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"
    >
    > However, this results (for each netsh invocation) in the error message:
    >
    > "Endpoint 'any' cannot be specified for a tunnel mode rule"
    >
    > Hmm. According to the Vista advanced firewall help: "IPsec Tunnel Mode is
    > not
    > supported for remote access VPN scenarios. L2TP/IPsec or PPTP should be
    > used
    > for remote access VPN connections." This *did* work in XP, so it appears
    > that
    > this capability was removed from Vista for a reason. It also seems likely
    > that
    > this is the reason why the legacy MMC snap-in won't work. It's unfortunate
    > that it silently fails though.
    >
    >
    > The weird thing is that it *does* work, if you replace "any" with a list
    > of
    > every IP address on the Net (and some extra)?
    >
    > netsh advfirewall consec add rule name="gateway -> laptop"
    > endpoint1=1.0.0.0-192.168.2.14,192.168.2.16-223.255.255.255
    > endpoint2=192.168.2.15/255.255.255.255 action=requireinrequireout
    > mode=tunnel enable=no localtunnelendpoint=192.168.2.1
    > remotetunnelendpoint=192.168.2.15 auth1=computercert auth1ca="C=NL,
    > S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\',
    > CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"
    >
    > netsh advfirewall consec add rule name="laptop -> gateway"
    > endpoint2=1.0.0.0-192.168.2.14,192.168.2.16-223.255.255.255
    > endpoint1=192.168.2.15/255.255.255.255 action=requireinrequireout
    > mode=tunnel enable=no localtunnelendpoint=192.168.2.15
    > remotetunnelendpoint=192.168.2.1 auth1=computercert auth1ca="C=NL,
    > S=Zuid-Holland, L=Papendrecht, O=Stupendous, OU=\'Certificate Authority\',
    > CN=certificate-authority.stupendous.org, E=jurjen-ca@stupendous.org"
    >
    >
    > This is not optimal though. Why won't it Just Work(tm) like it did in XP?
    > Why
    > is this now "not supported" all of a sudden?
    > --
    > Jurjen Oskam
    >
    > Savage's Law of Expediency:
    > You want it bad, you'll get it bad.

+ Reply to Thread
« Is IPSec as a built-in feature in Vista or Windows Server 2008? | file transfer large files »