Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 345
  • Last Modified:

Can't ping remote network over RAS connection

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
rjhoward
Asked:
rjhoward
  • 7
  • 5
  • 2
  • +1
1 Solution
 
dr00pyCommented:
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
 
rjhowardAuthor Commented:
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
 
yorenCommented:
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
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!

 
rjhowardAuthor Commented:
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
 
yorenCommented:
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
 
rjhowardAuthor Commented:
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
 
hajekCommented:
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
 
rjhowardAuthor Commented:
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
 
hajekCommented:
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
 
rjhowardAuthor Commented:
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
 
hajekCommented:
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
 
rjhowardAuthor Commented:
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
 
rjhowardAuthor Commented:
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
 
hajekCommented:
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
 
hajekCommented:
And does the route table looks to be the same as before ?
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 7
  • 5
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now