• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 614
  • Last Modified:

Ping router through MS VPN on demand

Hi. I am having a small issue pinging a router from a remote network. There are two networks (subnets) connected together using MS Site-to-Site VPN (dial on demand). Each site has its own subnet. Here is a description of the environment:

Site 1
Subnet: 172.17.16.x
Line: full T1 with 2 static addresses activated
Main router: 172.17.16.1 (for Canadian VPN)
Second router : 172.17.16.254 (for global VPN)
w2k3 Server: 172.17.16.2
DHCP: present with range within 172.17.16.x
Gateway for w2k3 server: 172.17.16.1
static routes: 172.16.0.0 using 172.17.16.254 and 172.17.18.0 using MSVPN interface

Site 2
Subnet: 172.17.18.x
Line: DSL with one fixed IP
Main router: 172.17.18.1 (for Canadian VPN)
w2k3 Server: 172.17.18.2
DHCP: present with range within 172.17.18.x
Gateway for w2k3 server: 172.17.16.1
static routes: 172.16.17.0 using MSVPN interface

Both sites can ping each other (including client PCs) except for three devices: 172.17.16.1 and 172.17.16.254 from site 2 and 172.17.18.1 from site 1.

I have experienced this issue before using MS VPN but until now, I didn't need to use these remote routers. I am now trying to reach the 172.17.16.254 router from site 2 in order to connect site 2 to all other global sites from this client.

Any clue or possibility to fix this? A static route?

Thanks.
0
benjilafouine
Asked:
benjilafouine
  • 11
  • 8
1 Solution
 
QlemoC++ DeveloperCommented:
Site 2:
Gateway for w2k3 server: 172.17.16.1

This is suspect. You should use a local default gateway, 172.17.18.x.
Anyway, I can't see the reason as the information is not detailed enough. You could try to use
   tracert -d -w 50 172.17.16.1
from Site 2 to see which way the packet goes, whether it's a routing issue.

0
 
benjilafouineAuthor Commented:
Oups! I made a small address mistake. Gateway for site 2 is 172.17.18.1 (and not 172.17.16.1). Cut and paste error...
0
 
benjilafouineAuthor Commented:
Tracert result was a complete "Request timed out".

I have several clients (even my own company) and using MS VPN, I am never capable of pinging remote routers at remote sites. This is probably a route or gateway problem (but I'm not certain)..
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
QlemoC++ DeveloperCommented:
As I always use NAT on RRAS, I cannot tell whether this is normal behaviour. But I remember the routers are not appearing in traceroute of any client.

The RRAS servers build an own network for VPN?
0
 
benjilafouineAuthor Commented:
No, it doesn't. Here's how it works:

Each VPN server gets an address from the facing network. Ex.: Server on Site 1 has IP 172.17.16.2. A virtual VPN dial-in adapter is created with address 172.17.16.82 (assigned from Site A DHCP). A second virtual PPP adapter is created and is assigned address 172.17.18.80 (from Site 2 DHCP).

The same reversed scenario is created in the facing server (site 2 server gets a site 1 address)

Two static routes are created (one per server) to route to the corresponding server.

I have the feeling that this whole process causes the routers to be not visible from the other side, but a I do not understand why. A RIP problem maybe?
0
 
QlemoC++ DeveloperCommented:
Did you try to reach the routers by their virtual addresses yet?

RIP is the wrong path here for sure. It is only responsible for propagating dynamic routes across routing devices.

0
 
benjilafouineAuthor Commented:
What do you mean by virtual address? The routers (physical and distinct routers) have two addresses each: one public address facing the Internet and one private address facing the internal network.
0
 
QlemoC++ DeveloperCommented:
Sorry, mixed something up. You do not try to reach the RRAS server themselves, but other routers.

As you use Class B addresses, the routers' netmask could be 255.255.0.0 instead of 255.255.255.0, so the might blow the answer into to network instead of addressing the W2k3 (& RRAS) servers for routing.

0
 
benjilafouineAuthor Commented:
I don't think that it changes anything? I agree that it could be 255.255.0.0 but I was given this range and 255.255.255.0 mask by my head office. I think that there is subnetting involved.

My own company has two subnets in the 192.168.x.x range with a netmask of 255.255.255.0 and I am observing the exact same behavior with MS VPN. I may have to bring this up with MS directly.

0
 
QlemoC++ DeveloperCommented:
As I told before, I always use NAT with RRAS. I know why ;-)

I can't believe the two problems are the same. Why should you be able to reach any computer on the other site, but not some? The difference must be in the routers' network setup.
0
 
benjilafouineAuthor Commented:
So what should I do? The routers are not different than any PCs in terms of IP address, if we exclude the fact that their gateway is not the same (the gateway is provided by the line provider).

Looks like I will have to verify against Microsoft.
0
 
QlemoC++ DeveloperCommented:
Can you set static route info on the routers? That would be enough ...
0
 
benjilafouineAuthor Commented:
Yes I could setup a static route on one router to test. However, one of the router is managed by a third party (and they are expensive!). What route are you thinking of?
0
 
QlemoC++ DeveloperCommented:
Site 1: 172.17.18.0/24 with gateway 172.17.16.2
Site 2: 172.17.16.0/24 with gateway 172.17.18.2
(is there a typo in Site 2 config for W2k3 gateway = 172.17.16.1? Should be 172.17.18.1?)
0
 
benjilafouineAuthor Commented:
I will try this outside working hours in case it causes a router reboot.
0
 
benjilafouineAuthor Commented:
Problem solved (sort of). It seems that the problem lies within the VPN link itself: it is unstable. Sometimes it pings, sometimes it don't.

MS VPN is far from being as stable as a hardware VPN solution. I am currently using it as a temporary measure.

Thanks all for you help.
0
 
benjilafouineAuthor Commented:
Problem sovled completely. VPN was unstable due to WINS service being present on the same server (as per a Microsoft KB).

 
0
 
QlemoC++ DeveloperCommented:
Please post MS KB link here, and then close the question accepting the link as solution.
0
 
benjilafouineAuthor Commented:
This solved the problem completely: http://support.microsoft.com/kb/292822
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 11
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now