RRAS Routing Problems

I have one of the weirdest routing problems I've ever seen in RRAS. I have
the following configuration, :

Boston:
-All clients default routed to the RRAS Server
-Network: 192.168.1.0
-RRAS Server: 192.168.1.29
--Windows 2003 SP 2 (Enterprise Server)
--PPTP Server
--Static route set to the remote route on the 192.168.2.0 network
--One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)

Fairfax:
-All clients default routed to the RRAS Server
-Network: 192.168.2.0
-RRAS Server: 192.168.2.29
--Windows 2008 (Enterprise Server)
--PPTP Server
--Static route set to the remote route on the 192.168.1.0 network
--One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)

These servers have a route called BostonFairfaxRoute. It's set up
identically on both servers, using that username and the username's password.
The RRAS servers connect the remote route successfully.

The problem lies in the ability to successfully route packets. The following
scenarios result:

192.168.2.29: CAN PING 192.168.1.29
192.168.1.29: Cannot ping 192.168.2.29
Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
Clients on the 192.1.0 network: Cannot ping 192.168.2.29

If the path between 192.168.2.29 and 192.168.1.29 didn't make it either way
I'd understand the problem. The confusing part is that it works one way! I've
never seen this before and have no idea how to solve it. I've verified all of
the settings more than once in what's a very common system for me to setup.

Anyone have any ideas?

Posting the routing tables on both servers may help.

--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
"Jack Dawsen" <Jack (E-Mail Removed)> wrote in message
news:5A2B34B5-FF37-4717-9BEA-(E-Mail Removed)...
>I have one of the weirdest routing problems I've ever seen in RRAS. I have
> the following configuration, :
>
> Boston:
> -All clients default routed to the RRAS Server
> -Network: 192.168.1.0
> -RRAS Server: 192.168.1.29
> --Windows 2003 SP 2 (Enterprise Server)
> --PPTP Server
> --Static route set to the remote route on the 192.168.2.0 network
> --One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)
>
> Fairfax:
> -All clients default routed to the RRAS Server
> -Network: 192.168.2.0
> -RRAS Server: 192.168.2.29
> --Windows 2008 (Enterprise Server)
> --PPTP Server
> --Static route set to the remote route on the 192.168.1.0 network
> --One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)
>
> These servers have a route called BostonFairfaxRoute. It's set up
> identically on both servers, using that username and the username's
> password.
> The RRAS servers connect the remote route successfully.
>
> The problem lies in the ability to successfully route packets. The
> following
> scenarios result:
>
> 192.168.2.29: CAN PING 192.168.1.29
> 192.168.1.29: Cannot ping 192.168.2.29
> Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
> Clients on the 192.1.0 network: Cannot ping 192.168.2.29
>
> If the path between 192.168.2.29 and 192.168.1.29 didn't make it either
> way
> I'd understand the problem. The confusing part is that it works one way!
> I've
> never seen this before and have no idea how to solve it. I've verified all
> of
> the settings more than once in what's a very common system for me to
> setup.
>
> Anyone have any ideas?

If the clients on their respective network are already "default routed" to
their respective RRAS Box then there is no "static route" that I can think
of that should be there. The RRAS boxes already "know" about the IP Segment
on the opposite end since they are directly connected to it. The Clients
only need to know where their RRAS Box is,...they do not need to "know"
specifically about the opposite LAN.

But then it has been a while since I worked with RRAS and I have a tendency
to think of it in terms of how I would a traditional router appliance.

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


"Jack Dawsen" <Jack (E-Mail Removed)> wrote in message
news:5A2B34B5-FF37-4717-9BEA-(E-Mail Removed)...
>I have one of the weirdest routing problems I've ever seen in RRAS. I have
> the following configuration, :
>
> Boston:
> -All clients default routed to the RRAS Server
> -Network: 192.168.1.0
> -RRAS Server: 192.168.1.29
> --Windows 2003 SP 2 (Enterprise Server)
> --PPTP Server
> --Static route set to the remote route on the 192.168.2.0 network
> --One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)
>
> Fairfax:
> -All clients default routed to the RRAS Server
> -Network: 192.168.2.0
> -RRAS Server: 192.168.2.29
> --Windows 2008 (Enterprise Server)
> --PPTP Server
> --Static route set to the remote route on the 192.168.1.0 network
> --One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)
>
> These servers have a route called BostonFairfaxRoute. It's set up
> identically on both servers, using that username and the username's
> password.
> The RRAS servers connect the remote route successfully.
>
> The problem lies in the ability to successfully route packets. The
> following
> scenarios result:
>
> 192.168.2.29: CAN PING 192.168.1.29
> 192.168.1.29: Cannot ping 192.168.2.29
> Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
> Clients on the 192.1.0 network: Cannot ping 192.168.2.29
>
> If the path between 192.168.2.29 and 192.168.1.29 didn't make it either
> way
> I'd understand the problem. The confusing part is that it works one way!
> I've
> never seen this before and have no idea how to solve it. I've verified all
> of
> the settings more than once in what's a very common system for me to
> setup.
>
> Anyone have any ideas?

Robert,

That completely slipped my mind, I had every intention of posting the
routing tables.

This is the table from Boston:

Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.29 20
72.85.61.11 255.255.255.255 192.168.1.1 192.168.1.29 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.29 192.168.1.29 20
192.168.1.10 255.255.255.255 192.168.2.201 192.168.2.201 1
192.168.1.11 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.1.29 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.29 192.168.1.29 20
192.168.2.0 255.255.255.0 192.168.1.10 192.168.2.201 1
192.168.2.201 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.2.255 255.255.255.255 192.168.2.201 192.168.2.201 50
224.0.0.0 240.0.0.0 192.168.1.29 192.168.1.29 20
224.0.0.0 240.0.0.0 192.168.2.201 192.168.2.201 50
255.255.255.255 255.255.255.255 192.168.1.29 192.168.1.29 1
255.255.255.255 255.255.255.255 192.168.2.201 192.168.2.201 1
Default Gateway: 192.168.1.1
--

And this is the table from Fairfax:

Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.29 286
67.101.123.140 255.255.255.255 192.168.2.1 192.168.2.29 31
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 192.168.2.201 192.168.1.10 31
192.168.1.10 255.255.255.255 On-link 192.168.1.10 286
192.168.2.0 255.255.255.0 On-link 192.168.2.29 286
192.168.2.29 255.255.255.255 On-link 192.168.2.29 286
192.168.2.200 255.255.255.255 On-link 192.168.2.200 306
192.168.2.255 255.255.255.255 On-link 192.168.2.29 286
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.2.29 286
224.0.0.0 240.0.0.0 On-link 192.168.2.200 306
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.2.29 286
255.255.255.255 255.255.255.255 On-link 192.168.2.200 306
255.255.255.255 255.255.255.255 On-link 192.168.1.10 286
--

Thank you in advance for any guidance you can provide!

Jack

"Robert L. (MS-MVP)" wrote:

> Posting the routing tables on both servers may help.
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting on
> http://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access on
> http://www.HowToNetworking.com
> "Jack Dawsen" <Jack (E-Mail Removed)> wrote in message
> news:5A2B34B5-FF37-4717-9BEA-(E-Mail Removed)...
> >I have one of the weirdest routing problems I've ever seen in RRAS. I have
> > the following configuration, :
> >
> > Boston:
> > -All clients default routed to the RRAS Server
> > -Network: 192.168.1.0
> > -RRAS Server: 192.168.1.29
> > --Windows 2003 SP 2 (Enterprise Server)
> > --PPTP Server
> > --Static route set to the remote route on the 192.168.2.0 network
> > --One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)
> >
> > Fairfax:
> > -All clients default routed to the RRAS Server
> > -Network: 192.168.2.0
> > -RRAS Server: 192.168.2.29
> > --Windows 2008 (Enterprise Server)
> > --PPTP Server
> > --Static route set to the remote route on the 192.168.1.0 network
> > --One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)
> >
> > These servers have a route called BostonFairfaxRoute. It's set up
> > identically on both servers, using that username and the username's
> > password.
> > The RRAS servers connect the remote route successfully.
> >
> > The problem lies in the ability to successfully route packets. The
> > following
> > scenarios result:
> >
> > 192.168.2.29: CAN PING 192.168.1.29
> > 192.168.1.29: Cannot ping 192.168.2.29
> > Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
> > Clients on the 192.1.0 network: Cannot ping 192.168.2.29
> >
> > If the path between 192.168.2.29 and 192.168.1.29 didn't make it either
> > way
> > I'd understand the problem. The confusing part is that it works one way!
> > I've
> > never seen this before and have no idea how to solve it. I've verified all
> > of
> > the settings more than once in what's a very common system for me to
> > setup.
> >
> > Anyone have any ideas?
>
>

The routing tables look good to me. Where the traffic stop if using tracert
from Fairfax to Boston? Do you have NAT/Firewall enabled?

--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
"Jack Dawsen" <(E-Mail Removed)> wrote in message
news:149D34AB-B32F-4E69-A72B-(E-Mail Removed)...
> Robert,
>
> That completely slipped my mind, I had every intention of posting the
> routing tables.
>
> This is the table from Boston:
>
> Network Destination Netmask Gateway Interface
> Metric
> 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.29 20
> 72.85.61.11 255.255.255.255 192.168.1.1 192.168.1.29 20
> 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
> 192.168.1.0 255.255.255.0 192.168.1.29 192.168.1.29 20
> 192.168.1.10 255.255.255.255 192.168.2.201 192.168.2.201 1
> 192.168.1.11 255.255.255.255 127.0.0.1 127.0.0.1 50
> 192.168.1.29 255.255.255.255 127.0.0.1 127.0.0.1 20
> 192.168.1.255 255.255.255.255 192.168.1.29 192.168.1.29 20
> 192.168.2.0 255.255.255.0 192.168.1.10 192.168.2.201 1
> 192.168.2.201 255.255.255.255 127.0.0.1 127.0.0.1 50
> 192.168.2.255 255.255.255.255 192.168.2.201 192.168.2.201 50
> 224.0.0.0 240.0.0.0 192.168.1.29 192.168.1.29 20
> 224.0.0.0 240.0.0.0 192.168.2.201 192.168.2.201 50
> 255.255.255.255 255.255.255.255 192.168.1.29 192.168.1.29 1
> 255.255.255.255 255.255.255.255 192.168.2.201 192.168.2.201 1
> Default Gateway: 192.168.1.1
> --
>
> And this is the table from Fairfax:
>
> Network Destination Netmask Gateway Interface
> Metric
> 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.29 286
> 67.101.123.140 255.255.255.255 192.168.2.1 192.168.2.29 31
> 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
> 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
> 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
> 192.168.1.0 255.255.255.0 192.168.2.201 192.168.1.10 31
> 192.168.1.10 255.255.255.255 On-link 192.168.1.10 286
> 192.168.2.0 255.255.255.0 On-link 192.168.2.29 286
> 192.168.2.29 255.255.255.255 On-link 192.168.2.29 286
> 192.168.2.200 255.255.255.255 On-link 192.168.2.200 306
> 192.168.2.255 255.255.255.255 On-link 192.168.2.29 286
> 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
> 224.0.0.0 240.0.0.0 On-link 192.168.2.29 286
> 224.0.0.0 240.0.0.0 On-link 192.168.2.200 306
> 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
> 255.255.255.255 255.255.255.255 On-link 192.168.2.29 286
> 255.255.255.255 255.255.255.255 On-link 192.168.2.200 306
> 255.255.255.255 255.255.255.255 On-link 192.168.1.10 286
> --
>
> Thank you in advance for any guidance you can provide!
>
> Jack
>
> "Robert L. (MS-MVP)" wrote:
>
>> Posting the routing tables on both servers may help.
>>
>> --
>> Bob Lin, MS-MVP, MCSE & CNE
>> Networking, Internet, Routing, VPN Troubleshooting on
>> http://www.ChicagoTech.net
>> How to Setup Windows, Network, VPN & Remote Access on
>> http://www.HowToNetworking.com
>> "Jack Dawsen" <Jack (E-Mail Removed)> wrote in message
>> news:5A2B34B5-FF37-4717-9BEA-(E-Mail Removed)...
>> >I have one of the weirdest routing problems I've ever seen in RRAS. I
>> >have
>> > the following configuration, :
>> >
>> > Boston:
>> > -All clients default routed to the RRAS Server
>> > -Network: 192.168.1.0
>> > -RRAS Server: 192.168.1.29
>> > --Windows 2003 SP 2 (Enterprise Server)
>> > --PPTP Server
>> > --Static route set to the remote route on the 192.168.2.0 network
>> > --One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)
>> >
>> > Fairfax:
>> > -All clients default routed to the RRAS Server
>> > -Network: 192.168.2.0
>> > -RRAS Server: 192.168.2.29
>> > --Windows 2008 (Enterprise Server)
>> > --PPTP Server
>> > --Static route set to the remote route on the 192.168.1.0 network
>> > --One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)
>> >
>> > These servers have a route called BostonFairfaxRoute. It's set up
>> > identically on both servers, using that username and the username's
>> > password.
>> > The RRAS servers connect the remote route successfully.
>> >
>> > The problem lies in the ability to successfully route packets. The
>> > following
>> > scenarios result:
>> >
>> > 192.168.2.29: CAN PING 192.168.1.29
>> > 192.168.1.29: Cannot ping 192.168.2.29
>> > Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
>> > Clients on the 192.1.0 network: Cannot ping 192.168.2.29
>> >
>> > If the path between 192.168.2.29 and 192.168.1.29 didn't make it either
>> > way
>> > I'd understand the problem. The confusing part is that it works one
>> > way!
>> > I've
>> > never seen this before and have no idea how to solve it. I've verified
>> > all
>> > of
>> > the settings more than once in what's a very common system for me to
>> > setup.
>> >
>> > Anyone have any ideas?
>>
>>

"Phillip Windell" <(E-Mail Removed)> wrote in message >
> But then it has been a while since I worked with RRAS and I have a
> tendency to think of it in terms of how I would a traditional router
> appliance.
>

If the VPN link is up and the static routes are in place, that is
perfectly reasonable. Since the two routers are linked by a point to point
connection, the setup can be looked at as a simple (slow) IP router. Packets
reaching one VPN router addressed to the "other" site are delivered directly
by the VPN router at the other end, just like one IP router connecting two
segments. What happens between the two routers can be ignored as far as
routing is concerned (except the speed!) Even firewalls can be ignored
because the original private addressed packet is encrypted and encapsulated
when it goes through the firewall. It is just the payload of the packet. The
firewall only sees the header of the public addressed wrapper.

"Bill Grant" <not.available@online> wrote in message
news:(E-Mail Removed)...
> If the VPN link is up and the static routes are in place, that is
> perfectly reasonable. Since the two routers are linked by a point to point
> connection, the setup can be looked at as a simple (slow) IP router.

Yes. That is why I don't see the need to add static routes. With an IP
Router there would be no static route at all. The Router (or Routers in
P2P) are already aware of the segments that they are already directly
connected two, so when there is only two segments there just simply would
not be a static route at all. I have to trust your judgment when it comes
to RRAS becuase you know it better than I do, so I am trying to understand,
but I don't see any need for a static route.

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

Robert,

I'm glad we're coming to the same conclusions on the routing tables and
setup, at least I know I'm not crazy.

As for the traffic, pings succeed from the Fairfax RRAS box to the Boston
RASS box, and strangely enough even pinging CLIENTS on the Boston side from
the Fairfax RRAS box succeeds. When pinging the Fairfax RRAS box from Boston,
however, failure occurs. The tracert from the Boston RRAS box to the Fairfax
RRAS box fails right from the start, so at least it doesn't appear to be
erroneously routing through the DSL router.

Let me know what you think,

Jack

"Robert L. (MS-MVP)" wrote:

> The routing tables look good to me. Where the traffic stop if using tracert
> from Fairfax to Boston? Do you have NAT/Firewall enabled?
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting on
> http://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access on
> http://www.HowToNetworking.com
> "Jack Dawsen" <(E-Mail Removed)> wrote in message
> news:149D34AB-B32F-4E69-A72B-(E-Mail Removed)...
> > Robert,
> >
> > That completely slipped my mind, I had every intention of posting the
> > routing tables.
> >
> > This is the table from Boston:
> >
> > Network Destination Netmask Gateway Interface
> > Metric
> > 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.29 20
> > 72.85.61.11 255.255.255.255 192.168.1.1 192.168.1.29 20
> > 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
> > 192.168.1.0 255.255.255.0 192.168.1.29 192.168.1.29 20
> > 192.168.1.10 255.255.255.255 192.168.2.201 192.168.2.201 1
> > 192.168.1.11 255.255.255.255 127.0.0.1 127.0.0.1 50
> > 192.168.1.29 255.255.255.255 127.0.0.1 127.0.0.1 20
> > 192.168.1.255 255.255.255.255 192.168.1.29 192.168.1.29 20
> > 192.168.2.0 255.255.255.0 192.168.1.10 192.168.2.201 1
> > 192.168.2.201 255.255.255.255 127.0.0.1 127.0.0.1 50
> > 192.168.2.255 255.255.255.255 192.168.2.201 192.168.2.201 50
> > 224.0.0.0 240.0.0.0 192.168.1.29 192.168.1.29 20
> > 224.0.0.0 240.0.0.0 192.168.2.201 192.168.2.201 50
> > 255.255.255.255 255.255.255.255 192.168.1.29 192.168.1.29 1
> > 255.255.255.255 255.255.255.255 192.168.2.201 192.168.2.201 1
> > Default Gateway: 192.168.1.1
> > --
> >
> > And this is the table from Fairfax:
> >
> > Network Destination Netmask Gateway Interface
> > Metric
> > 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.29 286
> > 67.101.123.140 255.255.255.255 192.168.2.1 192.168.2.29 31
> > 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
> > 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
> > 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
> > 192.168.1.0 255.255.255.0 192.168.2.201 192.168.1.10 31
> > 192.168.1.10 255.255.255.255 On-link 192.168.1.10 286
> > 192.168.2.0 255.255.255.0 On-link 192.168.2.29 286
> > 192.168.2.29 255.255.255.255 On-link 192.168.2.29 286
> > 192.168.2.200 255.255.255.255 On-link 192.168.2.200 306
> > 192.168.2.255 255.255.255.255 On-link 192.168.2.29 286
> > 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
> > 224.0.0.0 240.0.0.0 On-link 192.168.2.29 286
> > 224.0.0.0 240.0.0.0 On-link 192.168.2.200 306
> > 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
> > 255.255.255.255 255.255.255.255 On-link 192.168.2.29 286
> > 255.255.255.255 255.255.255.255 On-link 192.168.2.200 306
> > 255.255.255.255 255.255.255.255 On-link 192.168.1.10 286
> > --
> >
> > Thank you in advance for any guidance you can provide!
> >
> > Jack
> >
> > "Robert L. (MS-MVP)" wrote:
> >
> >> Posting the routing tables on both servers may help.
> >>
> >> --
> >> Bob Lin, MS-MVP, MCSE & CNE
> >> Networking, Internet, Routing, VPN Troubleshooting on
> >> http://www.ChicagoTech.net
> >> How to Setup Windows, Network, VPN & Remote Access on
> >> http://www.HowToNetworking.com
> >> "Jack Dawsen" <Jack (E-Mail Removed)> wrote in message
> >> news:5A2B34B5-FF37-4717-9BEA-(E-Mail Removed)...
> >> >I have one of the weirdest routing problems I've ever seen in RRAS. I
> >> >have
> >> > the following configuration, :
> >> >
> >> > Boston:
> >> > -All clients default routed to the RRAS Server
> >> > -Network: 192.168.1.0
> >> > -RRAS Server: 192.168.1.29
> >> > --Windows 2003 SP 2 (Enterprise Server)
> >> > --PPTP Server
> >> > --Static route set to the remote route on the 192.168.2.0 network
> >> > --One NIC, default routed to 192.168.1.1 (DSL Router to the cloud)
> >> >
> >> > Fairfax:
> >> > -All clients default routed to the RRAS Server
> >> > -Network: 192.168.2.0
> >> > -RRAS Server: 192.168.2.29
> >> > --Windows 2008 (Enterprise Server)
> >> > --PPTP Server
> >> > --Static route set to the remote route on the 192.168.1.0 network
> >> > --One NIC, default routed to 192.168.2.1 (DSL Router to the cloud)
> >> >
> >> > These servers have a route called BostonFairfaxRoute. It's set up
> >> > identically on both servers, using that username and the username's
> >> > password.
> >> > The RRAS servers connect the remote route successfully.
> >> >
> >> > The problem lies in the ability to successfully route packets. The
> >> > following
> >> > scenarios result:
> >> >
> >> > 192.168.2.29: CAN PING 192.168.1.29
> >> > 192.168.1.29: Cannot ping 192.168.2.29
> >> > Clients on 192.168.2.0 network: Cannot ping 192.168.1.29
> >> > Clients on the 192.1.0 network: Cannot ping 192.168.2.29
> >> >
> >> > If the path between 192.168.2.29 and 192.168.1.29 didn't make it either
> >> > way
> >> > I'd understand the problem. The confusing part is that it works one
> >> > way!
> >> > I've
> >> > never seen this before and have no idea how to solve it. I've verified
> >> > all
> >> > of
> >> > the settings more than once in what's a very common system for me to
> >> > setup.
> >> >
> >> > Anyone have any ideas?
> >>
> >>
>
>

"Jack Dawsen" <(E-Mail Removed)> wrote in message
news:26034291-BE70-42FE-8676-(E-Mail Removed)...
> I'm glad we're coming to the same conclusions on the routing tables and
> setup, at least I know I'm not crazy.

Until someone convinces me otherwise (and that may happen), I don't think
there should be any static routes on the RRAS boxes and I don't think
routing tables have anything to do with it.

> As for the traffic, pings succeed from the Fairfax RRAS box to the Boston
> RASS box, and strangely enough even pinging CLIENTS on the Boston side
> from
> the Fairfax RRAS box succeeds. When pinging the Fairfax RRAS box from
> Boston,
> however, failure occurs. The tracert from the Boston RRAS box to the
> Fairfax
> RRAS box fails right from the start, so at least it doesn't appear to be

A pair or RRAS boxes in a Site-to-Site Connection each have to "dial" each
other to have a "complete" two-way connection. It sounds like Fairfax has
properly "dialed" Boston but Boston has not properly "dialed" Fairfax. So
pings initiated from Fairfax to Boston succeed,...while pings initiated from
Boston to Fairfax fail.

Once a connection is "dialed" the routing table is dynamically
altered,...however this is not a static route or routing table issue.

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

Phillip,

Thank you for your comment on the static routes. Taking them off does not
resolve the situation, but once the problem is fixed I will experiment in
taking them off and seeing if they are updated dynamically.

As for "dialing," I'm not sure what you mean. Boston can successfully
connect the VPN to Fairfax, causing both machines to list the Demand Dial
item as "Connected," and Fairfax can successfully do the same thing in
reverse. In either case, the same one-sided behavior is exhibited.

Jack

"Phillip Windell" wrote:

> "Jack Dawsen" <(E-Mail Removed)> wrote in message
> news:26034291-BE70-42FE-8676-(E-Mail Removed)...
> > I'm glad we're coming to the same conclusions on the routing tables and
> > setup, at least I know I'm not crazy.
>
> Until someone convinces me otherwise (and that may happen), I don't think
> there should be any static routes on the RRAS boxes and I don't think
> routing tables have anything to do with it.
>
> > As for the traffic, pings succeed from the Fairfax RRAS box to the Boston
> > RASS box, and strangely enough even pinging CLIENTS on the Boston side
> > from
> > the Fairfax RRAS box succeeds. When pinging the Fairfax RRAS box from
> > Boston,
> > however, failure occurs. The tracert from the Boston RRAS box to the
> > Fairfax
> > RRAS box fails right from the start, so at least it doesn't appear to be
>
> A pair or RRAS boxes in a Site-to-Site Connection each have to "dial" each
> other to have a "complete" two-way connection. It sounds like Fairfax has
> properly "dialed" Boston but Boston has not properly "dialed" Fairfax. So
> pings initiated from Fairfax to Boston succeed,...while pings initiated from
> Boston to Fairfax fail.
>
> Once a connection is "dialed" the routing table is dynamically
> altered,...however this is not a static route or routing table issue.
>
> --
> 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.
> -----------------------------------------------------
>
>
>