Site-to-Site VPN client routing question - clients at branch office not able to access network at HQ

Discussion in 'Server Networking' started by Hii Sing Chung, Oct 14, 2007.

  1. I have a small network (5 clients) at Shanghai ( and my HQ is
    in Singapore (97 clients, My task is to connect the 2
    networks using Windows RRAS. In HQ I already has a RRAS server (SGRAS01)
    that I setup using Windows 2000 server. It has been running well for 5
    years, serving VPN clients. SGRAS01 has 2 physical network interfaces, one
    connecting to the Internet, one sitting on network. I set up a
    Windows 2003 server at Shanghai (SHDC01), it is a domain controller of the
    same domain at my HQ (no child domain). SHDC01 has only 1 network card, it
    is behind a TP-LINK TL-R402M router. I also configured a persistent demand
    dial interface on SHDC01 to connect to SGRAS01, and a corresponding demail
    dial interface on SGRAS01 (currently disabled). The Windows Firewall hasn't
    been enabled yet on SHDC01. Right now I wish to accomplish the
    Shanghai-Singapore 1-way connection first, before going into the 2-way VPN
    connection (I am prepared to change the router). I set a fixed IP
    ( on the Dial-in tab of the user account (ddsgusser) used for the
    demand dial interface on SHDC01. The clients on the Shanghai networks are
    configured (using DHCP) to route packets destined for through
    SHDC01. A route print on any clients can verify the routing entry, where is the IP address of SHDC01.
    The demand dial connection from SHDC01 to SGRAS01 is successful, and SHDC01
    has no problem connecting to any clients on the networks. However,
    all the clients on the Shanghai network cannot access any clients on
    Singapore network, tracert shows the packets are lost after going through
    SHDC01. The clients on the Shanghai network can access Singapore network if
    they use direct vpn connection to SGRAS01, which they have been doing all
    this while.

    You can see the screen captures here:!CEF9A5068D415432!404.entry

    Any help or suggestions is very much appreciated.

    Sing Chung
    Hii Sing Chung, Oct 14, 2007
    1. Advertisements

  2. You need to:

    1. In Shanghai,...Stop using the DC for this and disable RRAS on it before
    you start having problems with Active Directory

    2. Setup RRAS on a 2-Nic machine identical to how you did the one in
    Singapore. It needs to sit on the network edge facing the Internet just
    like you did in Singapore. If you only have one Public IP# and are unable
    to do that,...then use the RRAS machine to completely replace the TP-LINK
    TL-R402M router with the RRAS machine.

    It is possible to do this with a 2-Nic DC (like SBS does) but I do not
    recommend exposing your DC directly to the Internet like that.

    3. Do you realize that you are not using a valid RFC Private IP Range on the
    LAN at the HQ?

    4. Do you realize that is a heavily over used RFC Private IP
    Range and almost every broadband device is using the same one by default?
    To avoid possible future conflicts with VPN change the third octet to a
    higher number like maybe 50 ( It is much easier to do that
    now while the network is small.

    Phillip Windell

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    Phillip Windell, Oct 14, 2007
    1. Advertisements

  3. Hii Sing Chung

    Bill Grant Guest

    First of all, a warning about using a DC as a router. This is always a
    bad idea.

    Your DC might only have one NIC, but as soon as your VPN connection is
    made it has two IP addresses, so you get all sorts of problems (the old
    multihomed DC problems from N T plus some new ones). I would recommend that
    you use some other machine as your router, ot the DC.

    The next thing to note is that you do not have two links. The routing
    works through the one VPN link. The routing is set up on the demand-dial
    interfaces, so it is important that the demand-dial interfaces are actually
    bound to the connection, no matter which server initiates the connection.

    You do not need to manually enter any IP addresses on the clients to get
    the routing to work. All the routing is done by the RRAS servers.

    On the RRAS server at HQ, configure a demand-dial interface. Using the
    new static route wizard in RRAS, configure a route to but do
    not enter a gateway address. Instead, select the demand-dial interface from
    the dropdown list. This route will be stored in the registry until something
    connects to the dd interface.

    On the RRAS server in Shanghai, configure a demand-dial interface and
    give it a static route to as above. Configure this interface to
    initiate a VPN connection to the RRAS server in Singapore. Note that you
    must use the name of the demand-dial interface on the Singapore RRAS server
    as your username. This makes sure that the connection is made to the correct
    dd interface and sets up the correct route back to Shanghai through the VPN

    When the Singapore RRAS router gets the connection request it checks
    that the username matches one of its demand-dial inerfaces. (If it does not,
    it connects like a dialup VPN client and the static route is not added to
    the routing table. Site to site routing then fails). When the connection is
    made to the dd interface, the subnet route back to Shanghai is added to the
    routing table using the dd interface as the gateway.

    Now the VPN link acts like a simple IP router. Any traffic for the
    Singapore subnet reaching the Shanghai RRAS router is sent through the VPN
    tunnel. Similarly any traffic reaching the RRAS server in Singapore which is
    on the Shanghai subnet will be routed through the VPN tunnel.

    If you always connect from the Shanghai end, you are finished. If you
    want to be able to connect from Singapore you need to make sure that you can
    use the name of the dd interface on the Shanghai RRAS server as the username
    and that the Shanghai server has this name set up as a valid account name.

    This setup assumes that the RRAS routers are the default gateways for
    each LAN. If they are not you need extra routing on the LAN to get the VPN
    traffic to the RRAS routers.
    Bill Grant, Oct 14, 2007
  4. Thanks, Phillip,

    1. & 2. These has been considered before. There is only one public IP,
    however considering the possibility of server breakdown higher than the
    router breakdown and the Internet access at Shanghai is more important than
    accessing to Singapore network, I opted for a less-risky, compromised
    solution. Also, there is no IT support at Shanghai side (possibility of
    flying me again from Singapore is slim), so the 'plug-and-go' type of
    infrastructure needs to be in place. In future when the Shanghai office is
    big enough (financially viable) to support multiple servers, I will ISA type
    3. The people who initially set up our networks in Singapore used the
    invalid RFC subnets for private networks, we also have,
    and before. For a number of years I had proposed to change the
    addressing but were turned down due to 'risks'.
    4. I know about the network potential problem, I can change
    that, but right now my priority is to verify that the routing (of clients at
    Shanghai to Singapore) can work (or is correct). On the other hand, if I can
    verify that this setup is not going to work, and the reason, I will not
    waste any more time here.
    Hii Sing Chung, Oct 14, 2007
  5. Thanks Bill,

    I changed the network address at Shanghai to I've got the
    RRAS servers connected to each other through Demand Dial interfaces but the
    clients behind them can't see the opposite networks, even if I manually put
    in a static route on the clients.
    What else might be missing?

    The screen captures can be seen here:!CEF9A5068D415432!404.entry
    Hii Sing Chung, Oct 15, 2007
  6. Hii Sing Chung

    Bill Grant Guest

    Are the demand-dial interfaces at both ends bound to the connection? You
    can check this by making sure that the dd interface on the answering router
    has changed to connected status.

    If they are both connected, it is just a matter of checking the routing
    tables. Check that each RRAS router has a subnet route for the other subnet
    through the VPN link. Do tracert commands from one site to the other and see
    where it breaks down.
    Bill Grant, Oct 15, 2007
  7. Is there any problem with the one RRAS box being a single nic machine behind
    an existing firewall device? RRAS still makes me dizzy when it comes to
    single NIC RRAS boxes and what you can/can't do with them is whatever

    Phillip Windell

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    Phillip Windell, Oct 15, 2007
  8. Hii Sing Chung, Oct 15, 2007
  9. Hii Sing Chung

    Bill Grant Guest

    No, its not a big problem, Philip. Once the connection is up, the point to
    point connection is between the two RRAS routers. The usual problem with a
    setup like that is that the RRAS router is not the default gateway for the
    LAN (because the Internet router is) and the private traffic for the other
    site hits the gateway router unencrypted and unencapsulated (and is
    dropped). It needs to go to the RRAS router first. Then it can go out as
    encapsulated data through the gateway.
    Bill Grant, Oct 16, 2007
  10. Ok, thanks Bill. Sounds like it is simpler to just avoid the situation
    unless there is no other choice.

    Phillip Windell

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.

    Phillip Windell, Oct 16, 2007
  11. Hii Sing Chung

    Bill Grant Guest

    Couldn't agree more. I never do it myself.

    I am pretty up to date with this stuff because I just set up a test
    using vms to check that Server 2003 and Server 2008 are compatible. (They
    are. You can have one of each as a RRAS server and site to site works fine).

    Bill Grant, Oct 17, 2007
  12. I realized that I need to key in the static routes of the corresponding
    networks in the clients on each networks. In Shanghai side, all the clients
    I keyed in the static route mask gateway and for the clients at Singapore, I keyed in the static route mask gateway After that the clients
    in Shanghai has no problem seeing the clients at Singapore but the opposite
    don't work - Clients at Singapore side cannot see any clients in Shanghai.
    That's 50% success. What else can I try?
    For the static routes I can use DHCP to assign to the clients, so not much
    of manual work there.
    Hii Sing Chung, Oct 18, 2007
  13. Hii Sing Chung

    Bill Grant Guest

    I suspect that the problem is with your default gateway settings (as
    discussed in a later entry in this thread). If a client machine in one site
    can see a client machine in the other site, the routing between sites is set
    up correctly. The routes on both RRAS servers must be correct.

    If the RRAS router is not the default gateway for the local LAN, you
    need extra routing (either on the default router or on every machine which
    you want to contact from the other site) to get the private traffic to the
    RRAS router.

    If there is no route on the local LAN to get traffic for the other site
    to the RRAs router, it uses the default route and goes directly to the
    gateway router. Because its destination address is a private IP, the router
    drops the packet.
    Bill Grant, Oct 19, 2007
  14. OK. I made some more tracert and ping tests, I found out that all except
    Vista clients in Shanghai are not reachable. With that I can conlcude that
    the site-to-site networks are working and fine. The vista issue I think got
    to do with Vista security, any clues?
    Hii Sing Chung, Oct 19, 2007
    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.