RRAS router-router VPN

According to Microsoft's "Deploying Router-to-router VPNs" guide, when configuring
for a one-way initiation, the answering router is to configure
1. a Demand-dial interface with same name as intended caller user account.
2. caller account given a static route in its Dial-in properties (to hook
the calling router's network).

calling network (192.168.251.0/24)
answering network (192.168.252.0/24)

While the calling router does get recognised as a router-router connection
(answering router's RRAS panel shows the demand-dial interface as Connected),
there is no static route established based on that user account's settings.
Instead, what we saw an IP assignment _from_ the calling router to the answering
router:

PPP adapter {AB2D153C-0222-4A53-BE5E-CA1153E0B572}:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.251.207
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 127.0.0.1


For the matter, the calling router also happens to be a DHCP/RRAS server
on its own right to accept client VPN connections at the remote site. But
I did not expect that it will _assign_ a DHCP address to the answering router,
even though I know this is standard practice with peering routers; I was
only expecting a route back to 192.168.251.0 via the RRAS Dial-in interface
192.168.252.61 to gateway 192.168.252.x (whatever was given to the calling
router).

It is only when I define a Static route at the RRAS level does it get featured
in the Route table. However even then the connection is not perfect: machines
from the calling network can ping to machines in the answering network, but
not the other way round (other than the two end-point routers)!

If a ping packet can find its way through the two VPN routers, and _return_
through the same avenue, I am baffled to find ping packets from the answering
network not being able to penetrate through the calling router when the ECHO-REPLY
packet could.

Anybody got some thoughts to share on this?


Thanks,
Aaron Seet
DevAdvice Moderation Team
SgDotNet Council, Craftsman
ASPInsider | Microsoft MVP - ASP.NET

The melody of logic will always play out the truth.
~ Narumi Ayumu, Spira

You need to set a static route back to the originating subnet. To use an
analogy. It's like you travel from Dallas, TX to NY, NY and forgot how to
return.

Savvy95
MCT, MCSE, MCSA, MSDBA, CCNA

"Aaron Seet" wrote:

> According to Microsoft's "Deploying Router-to-router VPNs" guide, when configuring
> for a one-way initiation, the answering router is to configure
> 1. a Demand-dial interface with same name as intended caller user account.
> 2. caller account given a static route in its Dial-in properties (to hook
> the calling router's network).
>
> calling network (192.168.251.0/24)
> answering network (192.168.252.0/24)
>
> While the calling router does get recognised as a router-router connection
> (answering router's RRAS panel shows the demand-dial interface as Connected),
> there is no static route established based on that user account's settings.
> Instead, what we saw an IP assignment _from_ the calling router to the answering
> router:
>
> PPP adapter {AB2D153C-0222-4A53-BE5E-CA1153E0B572}:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
> Physical Address. . . . . . . . . : 00-53-45-00-00-00
> DHCP Enabled. . . . . . . . . . . : No
> IP Address. . . . . . . . . . . . : 192.168.251.207
> Subnet Mask . . . . . . . . . . . : 255.255.255.255
> Default Gateway . . . . . . . . . :
> DNS Servers . . . . . . . . . . . : 127.0.0.1
>
>
> For the matter, the calling router also happens to be a DHCP/RRAS server
> on its own right to accept client VPN connections at the remote site. But
> I did not expect that it will _assign_ a DHCP address to the answering router,
> even though I know this is standard practice with peering routers; I was
> only expecting a route back to 192.168.251.0 via the RRAS Dial-in interface
> 192.168.252.61 to gateway 192.168.252.x (whatever was given to the calling
> router).
>
> It is only when I define a Static route at the RRAS level does it get featured
> in the Route table. However even then the connection is not perfect: machines
> from the calling network can ping to machines in the answering network, but
> not the other way round (other than the two end-point routers)!
>
> If a ping packet can find its way through the two VPN routers, and _return_
> through the same avenue, I am baffled to find ping packets from the answering
> network not being able to penetrate through the calling router when the ECHO-REPLY
> packet could.
>
> Anybody got some thoughts to share on this?
>
>
> Thanks,
> Aaron Seet
> DevAdvice Moderation Team
> SgDotNet Council, Craftsman
> ASPInsider | Microsoft MVP - ASP.NET
>
> The melody of logic will always play out the truth.
> ~ Narumi Ayumu, Spiral
>
>
>

There is a static route set, not at the user level as the guide suggests,
but at the RRAS level.

Some new information in the hours spent trying to troubleshoot this problem:
I have a "spare" virtual PC image of a DC at home which I setup to act as
another RRAS calling router. Settings are identical, and yet this one can
traverse and browse freely across the networks.

One major difference was the lack of several DCOM errors the original calling
router/DC had. Why so? Because the answering router is the AD forest root
domain (win 2000), while the calling router a child tree domain (win 2003).
When the 2000 AD schema was updated in preparation for upgrade to 2003 in
the child tree, it does not include schema changes to reflect the revelation
of the NETWORK SERVICE account.
http://support.microsoft.com/?kbid=827016

so all those DCOM errors were due to the lack of NETWORK SERVICE, related
to many network service functionality.

Later on, i found out from my friend he installed SP1 to the Win 2003 calling
router. So right now I cannot tell if it is COM+ or SP1 that is the root
of the problem.


Aaron

s> You need to set a static route back to the originating subnet. To
s> use an analogy. It's like you travel from Dallas, TX to NY, NY and
s> forgot how to return.

Yesterday the RRAS/DC was restored to a pre-SP1 image, and the failure of
the LAN computers to browse computers in the answering network still persists.
What is different now, is the lack of those DCOM error messages which kept
appearing complaining about NETWORK SERVICE not existing.

Here's what I figure: in pre-SP1 the problems with NETWORK SERVICE _do_ happen
but don't get reported. Only SP1 introduces those new error messages. So
it appears this is the prime suspect.

The only way to know this for sure is to upgrade the answering router (forest
root domain) to win 2003 so that it list NETWORK SERVICE as a common account
in its schema. Until that issue is settled, we wouldn't know how it will
affect the calling router's Master browser service.


Aaron


AS> One major difference was the lack of several DCOM errors the
AS> original calling
AS> router/DC had. Why so? Because the answering router is the AD forest
AS> root
AS> domain (win 2000), while the calling router a child tree domain (win
AS> 2003).
AS> When the 2000 AD schema was updated in preparation for upgrade to
AS> 2003 in
AS> the child tree, it does not include schema changes to reflect the
AS> revelation
AS> of the NETWORK SERVICE account.
AS> http://support.microsoft.com/?kbid=827016
AS> so all those DCOM errors were due to the lack of NETWORK SERVICE,
AS> related to many network service functionality.
AS>
AS> Later on, i found out from my friend he installed SP1 to the Win
AS> 2003 calling router. So right now I cannot tell if it is COM+ or SP1
AS> that is the root of the problem.