IPSec tunnel to remote office; need proper static routes for RRAS

Discussion in 'Windows Networking' started by guywolcott, Feb 24, 2008.

  1. guywolcott

    guywolcott Guest

    I'm using SBS as my main office server/router/firewall, and I just
    added a remote office. At the remote office, I have a hardware
    firewall that supports only IPSec VPN tunnels. I have established an
    IPSec VPN tunnel according to http://support.microsoft.com/kb/816514

    The tunnel works fine, and I can see packets going across from the
    remote office (hardware firewall) back to the main office (SBS). But
    packets do not make it back the other way. It appears to be a routing
    problem on SBS. I know that I need to add a static route to send
    packets across the VPN tunnel rather than through the default gateway.
    But the static route described in the KB article doesn't work. Here's
    the setup:

    Main Office (SBS as router/firewall):
    Internal network (LAN): 192.168.16.0/24
    Internal interface: 192.168.16.2
    External interface: 67.100.185.126

    Remote office (hardware firewall):
    Internal network (LAN): 192.168.15.0/24
    Internal interface: 192.168.15.1
    External interface: 72.66.66.212

    According to the article, the static route should be: 192.168.15.0/24
    (gateway: 72.66.66.212; interface: external). But that doesn't work.
    When you add that static route in RRAS, it is just ignored. When you
    add it with ROUTE ADD, you get an error message saying the gateway is
    not on the network.

    I need to know the proper static route(s) to add to get the packets
    from the main office (SBS) private network, across the VPN tunnel, to
    the remote private network. I've read several places about using the
    "VPN interface" rather than the "external interface", but that is not
    an option. That seems to be something that comes along with a demand-
    dial VPN, which this is not (see the KB article).

    Any help would be most appreciated. I've been banging my head on this
    for several days.
     
    guywolcott, Feb 24, 2008
    #1
    1. Advertisements

  2. guywolcott

    Bill Grant Guest

    My guess is that you have not correctly configured the IPSec filters.

    You cannot use the routing methods used for other site to site VPNs. As
    you point out, they rely on demand-dial interfaces as the interfaces
    specified in the route commands.
     
    Bill Grant, Feb 24, 2008
    #2
    1. Advertisements

  3. guywolcott

    guywolcott Guest

    I'm pretty sure the filters are right. I have one policy with two
    rules. Each rule has one filter; they share the same "negotiate"
    filter action (containing the Phase 2 IPSec stuff):

    1st rule: Main to remote (filter: source: 192.168.16.0/24;
    destination: 192.168.15.0/24;protocol: Any; Mirror: no)
    2nd rule: Remote ro Main (filter: source: 192.168.15.0/24; dest:
    192.168.16.0/24; prot: Any; Mirror: no)

    If I change these, the tunnel itself doesn't seem to work, and they
    match up with what I have read. But I have also read in several places
    that IPSec is not a "routed" protocol (as implemented in Windows
    Server 2003), so it needs static routing to get packets through the
    tunnel. And now, when I tracert from the server to the remote office
    (which should use the tunnel), it tries to go through the default
    internet gateway, even though it is a private IP subnet.
     
    guywolcott, Feb 24, 2008
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.