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

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/blo...5432!404.entry

Any help or suggestions is very much appreciated.

Sing Chung

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 192.168.1.0 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 (192.168.50.0). It is much easier to do that
now while the network is small.

--
Phillip Windell
www.wandtv.com

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

"Hii Sing Chung" <(E-Mail Removed)> wrote in message
news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>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/blo...5432!404.entry
>
> Any help or suggestions is very much appreciated.
>
> Sing Chung
>

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" <(E-Mail Removed)> wrote in message
news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>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/blo...5432!404.entry
>
> Any help or suggestions is very much appreciated.
>
> Sing Chung
>

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
solution.
3. The people who initially set up our networks in Singapore used the
invalid RFC subnets for private networks, we also have 198.1.1.0, 195.1.1.0
and 193.1.1.0 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 192.168.1.0 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.

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 192.168.1.0 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 (192.168.50.0). It is much easier to do that
> now while the network is small.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft, or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
> "Hii Sing Chung" <(E-Mail Removed)> wrote in message
> news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>>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/blo...5432!404.entry
>>
>> Any help or suggestions is very much appreciated.
>>
>> Sing Chung
>>
>
>

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/blo...5432!404.entry

"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>>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/blo...5432!404.entry
>>
>> Any help or suggestions is very much appreciated.
>>
>> Sing Chung
>>
>

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" <(E-Mail Removed)> wrote in message
news:641F8CBA-93E3-4B54-853D-(E-Mail Removed)...
> 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/blo...5432!404.entry
>
> "Bill Grant" <not.available@online> wrote in message
> news:%(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>>>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/blo...5432!404.entry
>>>
>>> Any help or suggestions is very much appreciated.
>>>
>>> Sing Chung
>>>
>>
>

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
situations.


--
Phillip Windell
www.wandtv.com

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

Thanks, Bill,

I have put the screen captures at my spaces:
http://singchung.spaces.live.com/blo...5432!404.entry. Yes,
they are both connected, and the routing tables are right. Tracert at both
ends show the packets were lost after the DD interfaces.

"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:641F8CBA-93E3-4B54-853D-(E-Mail Removed)...
>> 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/blo...5432!404.entry
>>
>> "Bill Grant" <not.available@online> wrote in message
>> news:%(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>>> news:0481E662-8754-4E23-AD46-(E-Mail Removed)...
>>>>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/blo...5432!404.entry
>>>>
>>>> Any help or suggestions is very much appreciated.
>>>>
>>>> Sing Chung
>>>>
>>>
>>
>

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.

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 situations.
>
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft, or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>

Ok, thanks Bill. Sounds like it is simpler to just avoid the situation
unless there is no other choice.

--
Phillip Windell
www.wandtv.com

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

"Bill Grant" <not.available@online> wrote in message
news:(E-Mail Removed)...
> 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.
>
> "Phillip Windell" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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 situations.
>>
>>
>> --
>> Phillip Windell
>> www.wandtv.com
>>
>> The views expressed, are my own and not those of my employer, or
>> Microsoft, or anyone else associated with me, including my cats.
>> -----------------------------------------------------
>>
>>
>