Solved

Can't ping remote network over RAS connection

Posted on 1998-08-12
15
270 Views
Last Modified: 2013-12-28
We have a group of about 5 NT 4.0 workstations and 3 servers, all of which have RAS installed and all but one of which work just fine.  All the machines are on a LAN of course, and all have only one NIC.

We're using RAS to establish a PPP connection to a remote server, after which we expect to be able to telnet, ftp, or ping various other nodes on the remote network.  The one machine that's giving us fits will connect, and successfully establishes the PPP connection, but can't access any resource on the remote network.  It can ping itself and that's it.  It can't even ping the PPP server it dialed into!

It's configured to "Use default gateway on remote network".  In fact it appears to be configured exactly like other workstations which are working fine.  One thing that's odd is that when I ping the remote network, the modem lights do not blink (neither TX nor RX).

I've done a thorough ransacking of newsgroups and the Microsoft Knowledge Base, but they've been no help so far.  There was a Registry issue on this machine recently, so I'm wondering if some subtle Registry setting got clobbered.  I've deinstalled and reinstalled RAS several times; also to no avail.

Any help would be greatly appreciated.
0
Comment
Question by:rjhoward
  • 7
  • 5
  • 2
  • +1
15 Comments
 

Expert Comment

by:dr00py
ID: 1788811
It looks like there is no connection at all ...
Check if you have enough rights on the remote PC.
Also check your modem lights while you are activating the connection. They should blink ...
Do you use a DNS-server or do you use fixed IP adresses?
use IPCONFIG /ALL to check your IP configurations ...
Do this before and after you've tried to establish a connection.



0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788812
The remote PC actually isn't a PC but a Unix box, although I don't know what flavor.  The modem lights do blink while the PPP connection is being established.  And IPCONFIG /ALL shows that I do have an IP address on the remote network.  I'm using IP addresses, so DNS is not an issue (yet).
0
 
LVL 7

Expert Comment

by:yoren
ID: 1788813
Kind of a long-shot, but you might want to check that you haven't disabled your bindings. Make sure in Control Panel/Network/Bindings that all your "Remote Access WAN Wrapper" entries are Enabled.
0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788814
Good idea, but no dice.  All the bindings are enabled and are consistant with the machines that are working properly.  It was worth a try, though.

I really need to get this fixed, so am raising to 200 points.
0
 
LVL 7

Expert Comment

by:yoren
ID: 1788815
Can you type ROUTE PRINT on the culprit machine to see where it's trying to send those packets? Also try it on a good machine to see the difference.
0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788816
Good idea, but, alas, no dice.  I compared the ROUTE PRINT on a good machine vs. offending machine, both with PPP connection in place and without.  There was no difference (except the obvious ones like different IP addresses).  Same number of entries.  Same subnet masks.  Same gateways.

Don't you just love NT?
0
 
LVL 1

Expert Comment

by:hajek
ID: 1788817
Write us your IP addresses and output from "route print" on both machines, RAS client and server. If case of UNIX one, the command is "netstat -rn" (works on NT, too).

0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 1

Author Comment

by:rjhoward
ID: 1788818
I don't have access to the server machine; it doesn't even belong to my company.  However, I don't think the problem is on the server, because (1) other workstations can access it with no problem and (2) the offending machine has the same problem with every other server it tries to access.

So, here's the "route print" from the offending machine (after establishing PPP connection):

Network Address  Netmask             Gateway Address   Interface
0.0.0.0                 0.0.0.0                153.64.118.254      153.64.18.229
0.0.0.0                 0.0.0.0                192.127.150.26      192.127.150.26
127.0.0.0             255.0.0.0             127.0.0.1               127.0.0.1
153.64.118.0        255.255.255.0      153.64.18.229        153.64.18.229
153.64.18.229      255.255.255.255   127.0.0.1               127.0.0.1
153.64.255.255    255.255.255.255    153.64.18.229       153.64.18.229
192.127.150.0      255.255.255.0       192.127.150.26      192.127.150.26
192.127.150.26     255.255.255.255   127.0.0.1              127.0.0.1
224.0.0.0             224.0.0.0              192.127.150.26      192.127.150.26
224.0.0.0             224.0.0.0              153.64.118.229      153.64.18.229
255.255.255.255   255.255.255.0       153.64.18.229       153.64.18.229

Here it is from a machine that works properly:

Network Address  Netmask             Gateway Address   Interface
0.0.0.0                 0.0.0.0                153.64.118.254      153.64.18.209
0.0.0.0                 0.0.0.0                192.127.150.13      192.127.150.13
127.0.0.0             255.0.0.0             127.0.0.1               127.0.0.1
153.64.118.0        255.255.255.0      153.64.18.209        153.64.18.209
153.64.18.209      255.255.255.255   127.0.0.1               127.0.0.1
153.64.255.255    255.255.255.255    153.64.18.209       153.64.18.209
192.127.150.0      255.255.255.0       192.127.150.13      192.127.150.13
192.127.150.13     255.255.255.255   127.0.0.1              127.0.0.1
224.0.0.0             224.0.0.0              192.127.150.13      192.127.150.13
224.0.0.0             224.0.0.0              153.64.118.209      153.64.18.209
255.255.255.255   255.255.255.0       153.64.18.209       153.64.18.209

TIA for your help.
0
 
LVL 1

Expert Comment

by:hajek
ID: 1788819
Wow, nice table :-)
a) I do not like
0.0.0.0       0.0.0.0    153.64.118.254      153.64.18.229
0.0.0.0       0.0.0.0    192.127.150.26      192.127.150.26
rows. Each of them means : .. in other case send packet to ...
I believe there should be (max) 1 such row. But maybe in NT this means such packets will be sent to both networks ??? Strange.

b)
153.64.18.229      255.255.255.255   127.0.0.1    127.0.0.1
192.127.150.26     255.255.255.255   127.0.0.1    127.0.0.1

your computer has 2 IPs... what is your IP address on RAS side, what is IP address of RAS side of the server (where can not you ping) ?
0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788820
The 153.64.118 IPs are the on the LAN (which works fine), and the 192.127.150 IPs are on the PPP connection (which doesn't).

Also, I just noticed I left off the Metric column.  Metric values are all 1 except the first and fourth lines, which are 2 (on both machines).  This implies to me that the 153 route is more "expensive" and, therefore, less preferred.  Right?  Interesting as that is, since it's the same on both machines it's probably not relevant.
0
 
LVL 1

Expert Comment

by:hajek
ID: 1788821
It's really strange. I see one routing problem, when you use more the onen dial-up server (do you really dial to the same server from both clients ? :-)), but essential is why you can not see modem activity during ping.

I should do following:
1) remove RAS service from the WS
2) remove TCP/IP LAN protocol from WS
3) reboot
4) add RAS service to WS, configure it properly
5) try to RAS and ping to remote side
   If it won't work, solve this as primary problem.

Seems to me there is some (registry ??) problem, which cause all packets to be sent to LAN, none to RAS.
0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788822
Yes, both clients do dial into the same server.

Removing RAS AND TCP/IP is something I haven't tried.  I did remove and reinstall RAS, but not the protocol or the NIC.

Good idea.  I'll try it and report back in a day or two.
0
 
LVL 1

Author Comment

by:rjhoward
ID: 1788823
That worked!  Actually, I took it a bit further and removed the NIC, too.

Hajek, if you'll put in an answer to the question, I'll give you your points.  Many thanks.
0
 
LVL 1

Accepted Solution

by:
hajek earned 200 total points
ID: 1788824
I should do following:
     1) remove RAS service from the WS
     2) remove TCP/IP LAN protocol from WS
     3) reboot
     4) add RAS service to WS, configure it properly
     5) try to RAS and ping to remote side
        If it won't work, solve this as primary problem.
0
 
LVL 1

Expert Comment

by:hajek
ID: 1788825
And does the route table looks to be the same as before ?
0

Featured Post

Free book by J.Peter Bruzzese, Microsoft MVP

Are you using Office 365? Trying to set up email signatures but you’re struggling with transport rules and connectors? Let renowned Microsoft MVP J.Peter Bruzzese show you how in this exclusive e-book on Office 365 email signatures. Better yet, it’s free!

Join & Write a Comment

Recently Microsoft released a brand new function called CONCAT. It's supposed to replace its predecessor CONCATENATE. But how does it work? And what's new? In this article, we take a closer look at all of this - we even included an exercise file for…
If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
The viewer will learn how to successfully create a multiboot device using the SARDU utility on Windows 7. Start the SARDU utility: Change the image directory to wherever you store your ISOs, this will prevent you from having 2 copies of an ISO wit…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now