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

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 194.1.1.0 mask 255.255.255.0 gateway 192.168.100.2 and for the clients at Singapore, I keyed in the static route 192.168.100.0 mask 255.255.255.0 gateway 194.1.1.12. 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.

"Bill Grant" <not.available@online> wrote in message news:%23PT200xDIHA.1316@xxxxxxxxxxxxxxxxxxxxxxx
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.

"Hii Sing Chung" <singchung@xxxxxxxxxxx> wrote in message news:641F8CBA-93E3-4B54-853D-2114A11B42CA@xxxxxxxxxxxxxxxx
Thanks Bill,

I changed the network address at Shanghai to 192.168.100.0/24. 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: http://singchung.spaces.live.com/blog/cns!CEF9A5068D415432!404.entry

"Bill Grant" <not.available@online> wrote in message news:%232X0uIiDIHA.536@xxxxxxxxxxxxxxxxxxxxxxx
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 192.168.1.0/24 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 194.1.1.0/24 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 link.

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.

"Hii Sing Chung" <singchung@xxxxxxxxxxx> wrote in message news:0481E662-8754-4E23-AD46-415A48BCDED1@xxxxxxxxxxxxxxxx
I have a small network (5 clients) at Shanghai (192.168.1.0/24) and my HQ is
in Singapore (97 clients, 194.1.1.0/24). 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 194.1.1.0 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
(194.1.1.49) 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 194.1.1.0 through
SHDC01. A route print on any clients can verify the routing entry 194.1.1.0
255.255.255.0 192.168.1.2, where 192.168.1.2 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 194.1.1.0 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: http://singchung.spaces.live.com/blog/cns!CEF9A5068D415432!404.entry

Any help or suggestions is very much appreciated.

Sing Chung





.

Relevant Pages

  • Re: Sligtly OT: setting static routes on clients
    ... >>>I've got a network of clients on which I'd like to set static ... >>>to do this with DHCP? ... >>You can try using the DHCP Classless Static Route option (#121, ... Option 121 includes network and netmask fields, ...
    (freebsd-questions)
  • Site-to-Site VPN client routing question - clients at branch office not able to access n
    ... I have a small network (5 clients) at Shanghai and my HQ is ... Windows 2003 server at Shanghai (SHDC01), it is a domain controller of the ...
    (microsoft.public.windows.server.networking)
  • Option 249 Classless Static Routes
    ... Option 33 adds the static route into the client routing ... But I cannot ping the getway on the other side 172.16.0.1. ... I can ping the network IP 172.16.0.0 and it returns ... this but the clients are pre-xp and doesn't work. ...
    (microsoft.public.windows.server.networking)
  • Re: IP address assignment problem
    ... I have a little problem and seek for ur thoughts, let's assume I'm in a very open environment where everyone can very easily try to get his/her laptop on the network and IP addresses are assigned by a DHCP server and we are in a domain environment, how do I prevent machines that are not part of our domain to be assigned an IP address? ... This approach doesn't stop your rogue clients from connecting to other clients, but merely doesn't give them the information they normally need to do so. ... Using 802.1x, your workstations authenticate through the switch to a radius server before they are allowed any connectivity. ... This authentication can use X.509 certificates, computer account credentials from AD, or whatever else you'd normally configure radius to authenticate with. ...
    (Focus-Microsoft)
  • RE: Dropped Client Connections
    ... I understand that the SBS clients will lose ... Do all clients lose network connection at same time? ... Do you have single or double NICs on SBS? ... Modify the registry to disable Receive Side Scaling ...
    (microsoft.public.windows.server.sbs)