Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Ping through VPN tunnel fails

 
SOLVED
Go to solution
Doug Phillips
Trusted Contributor

Ping through VPN tunnel fails

Well, I'm going cross-eyed reading the doc's and doing searches trying to figure this out. I'm not currently local to the network, it's a bit of a drive, so most or this is from memory. Here's the background (the "problem" is described at the end if you want to jump there and come back). Sorry for the length:

We had a small business network running for years with a Win2003 R2 as DC, an OpenVMS V7.3-2 with AdvancedServer V7.3B as Member Server and 12 client PC's using Reflection/TELNET to login to the Alpha and they also connect to file & printer shares on both the Alpha & W2k3 locally. The servers, PCs and devices on the local network all have 192.168.1/24 static IPs and the Alpha only has one network adaptor. A cable modem & Cisco VPN Router provides connection to the internet and a few people use Cisco's QuickVPN for occasional remote access to the LAN. The router provides DHCP for remote users.

The Alpha is scheduled for replacement with an Itanium but that is still months away and cannot be done quickly, and the Alpha is stuck at this version until it retires.

Recently, an "unusual" power event took out the W2k3 server's UPS and that trashed the server's redundant power supplies, RAID controller, system board, and who knows what else. An exact replacement for the old hardware could not be found. A new system was configured and as much of the full BackupExec-saved data as possible was restored. This all took more than a few days.

In the mean time to get the network back up so the company could work, I promoted the Alpha to PDC of a new domain (eg, "company"), preserving its shares. I added BIND server (was not previously set up) to the Alpha as a Master for the zone (company.lan). I added the AdvancedServer users and hostmaps via Admin because the original SID's were lost with the W2k3 ("unknown user" on the client) so I didn't copy back the lsa & sam files. With the WINS server no longer available the network uses DNS.
 
Using one of the PC's for testing, I cleared the WINS setting, changed the primary DNS to point to the Alpha and changed it to the new domain. It prompted for the "account with permission" and after a pause it indicated it joined (Welcome to the company domain). I rebooted the PC and did an ipconfig /flushdns. It could TELNET but it could not connect to any shares (the network could not be found). Tried another PC with same results. I set the AdvSrvr shares for everyone=full and still no connection. From the PCs I could ping the server by both IP and name. I gave things a long lunch break to maybe settle in, but still no success.

I reexamined the AdvSrvr and TCPIP & BIND configurations but couldn't find anything that looked wrong in the settings, config files or anything helpful in the logs. "Admin show computers" displayed the newly joined PCs, and correctly showed [WS][ws] when they were on or off. I switched a PC to Workgroup (company) and could then both telnet and connect to the shares. I copied the PC's old user profile to the new user, tweaked some file protections and the PC looked pretty much like it did and was able to do everything the user needed, so that's how I set up the other PC's and the local network is usable. Each local PC can ping the others by IP and name. The "new" W2k3 has now been brought up on the network in Workgroup mode and its shares and services are accessible.

It's been a long time since I've had to do any of this and the conditions were at a pretty high level of panic.

 
Now the problem:

A remote client can successfully connect a tunnel to the Cisco VPN router via QuickVPN but cannot connect through the tunnel to the Alpha, as it did before. The W2k3 server and PCs IP can be pinged through the tunnel but ping times out to the Alpha IP. WireShark is no help for encrypted packets.

I can access the router's https admin interface remotely through the tunnel and from its diagnostics screen the Alpha IP address can be pinged. The router's "show hosts" screen displays the W2k3 server and PC names and IPs, but the Alpha displays name "unknown" with its IP address, so it's not giving out it NetBIOS name but I'm only using IP addresses anyway.

The OpenVMS documentation for NetBIOS (and ICMP) is sparse, to say the least, so there might be a problem with NetBIOS but I can't run the nb tools from here to see and I don't think this is my main problem.

Suspecting that I did something wrong with TCPIP or BIND, I went on-site after-hours a couple of days ago, moved the tcpip*.dat files out of sys$system, renamed the config files that had templates and renamed the tcpip$bind directory. I did a new tcpip$config, telling it not to use the existing config files and did a new bind$setup. Other than the site-specific settings (ip, zone, domain, etc) which I've verified, I took all of the defaults. None of the config files were changed manually. The result was that the same services showed as enabled/started, $tcpip show (whatever) looked the same, all of the things that used to work still did and those that didn't work still don't.

Comparing this system to other "similar" systems at other remote sites, I see the same services enabled and started, "$tcpip show" and the logicals all look comparable. On BIND server enabled systems, the Resolver includes its own IP address in its DNS list as does the problem system. One of the other sites is still actually running VMS 7.3-2 with AdvSrvr 7.3B and has a Win2003 R2 DC in the network, and is working without problems (as did the subject site before, so we'll likely make some adjustments to that site's DR situation).

So, the failing pings from the remote client come from the remote's public IP address (e.g., 12.34.56.78) while the router's successful diagnostic pings come from the router (i.e., 192.168.1.1). Since "public IP" pings echo though the tunnel for other 192.168.1.0 addresses, my suspicions point to something in the Alpha, but I don't know what.

I plan to go on-site within the next day or so, but at this point I don't even know what to look for beyond what I've already described. Any help (other than "upgrade to something current" or "dump windows") will be appreciated, and if someone lets me know what further details I should capture when I'm there I will certainly do that. I know some details are sketchy here.

TIA

Doug Phillips

14 REPLIES 14
Steven Schweda
Honored Contributor

Re: Ping through VPN tunnel fails

 
abrsvc
Respected Contributor

Re: Ping through VPN tunnel fails

Quite often firewalls are set up to only allow Ping access to specific IP addresses to verify that the VPN is up.  All other IPs have Ping disabled.  This helps to prevent Ping from being used to discover valid IPs within a network.  Double check the firewall and be sure that you are allowing Ping access to the Alpha IP address.   This may lead to the complete solution.

 

Dan

Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

Thanks for the replies.

 

@Dan - I've tried with the client firewall disabled, and the Cisco Router (an RV180) doesn't filter any traffic within the tunnel. Yes, firewall was my first suspect, too, but it would need to be very selective with just 192.168.1.100 blocked and all other 192.168.1 traffic allowed. I find nothing on either end that should do that.

 

edit#1: I need to add that the QuickVPN log does show that it pings the other end just after it connects the tunnel, as you say.

 

edit#2: I also want to say that before the day of the disaster, remote access worked and no changes were made to the client or the router.

 

edit#3: To clarify about the firewall: I disable the client's AV firewall, but QuickVPN turns on the Windows firewall and does whatever it needs. The Windows firewall must be ON to enable Windows IPSec. Normally, I use the AV firewall with the Windows firewall disabled.

 

edit#4: Okay, re-did the attachment with CR/LF's. Sorry about that.

'

Please see the attachment which is the reply to Steven.

 

Steven Schweda
Honored Contributor

Re: Ping through VPN tunnel fails

 
Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

 
Dennis Handly
Acclaimed Contributor

Re: Ping through VPN tunnel fails

>Please see the attachment which is the reply to Steven.

 

(I don't think you really need to provide attachments to Steven for just text, it's just that he is browser challenged for creating his own posts.  :-)

Jeremy Begg
Trusted Contributor

Re: Ping through VPN tunnel fails

Hi Doug,

 

If I understand correctly, the Alpha responds when the client is on the local network but not when the client is outside the firewall?

 

Given the external client can ping the Windows server but not the Alpha, I'd be suspicious of the TCP/IP interface and route settings on the Alpha.  You need to check those again.

 

Regards,

Jeremy Begg

Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

The firewalls don't appear to be a problem. From each end (Cisco router & my PC's firewall & IPSec), when the VPN is connected I can see the other end as "allowed."

 

Over the phone I've confirmed the Alpha's settings are:

 

(reported output from $tcpip show interface)

 

LO0   127.0.0.1     255.0.0.0

WE0   192.168.1.100 255.255.255.0

 

That is as it should be.

 

(reported output from $tcpip show route)

 

AH  127.0.0.1             127.0.0.1

AN  192.168.1.0/24        192.168.1.100

AN  192.168.1.100         192.168.1.100

 

The Alpha doesn't access the internet so there is no default route and as far as I know, the routing has always been set the way it is. But, I don't understand how the Alpha's Routing could affect this inbound ICMP problem? If I had problems *from* the Alpha, I could see why, but not *to* the Alpha.

 

I did find that the Cisco router can run a capture on the local LAN and download it to Wireshark. When I ping the LAN's Windows PC through the VPN from my remote PC I see both the request and reply. When I ping the Alpha I see only the request. I do see all of the other LAN traffic that would be expected. (one PC seems a bit "chatty" but I'll worry about that some other day). When I ping the Alpha (or Windows) from the Cisco router I see both the request and reply.

 

So, I'm still working on going there but I don't yet have a date & time. If I don't find anything in a log file, or have any new ideas by then I guess I'll just move off the .dat & config files and TCPIP$CONFIG again from scratch.

Steven Schweda
Honored Contributor
Solution

Re: Ping through VPN tunnel fails

 
Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

> So, the failing pings from the remote client come from the remote's
> public IP address (e.g., 12.34.56.78) [...]

> The Alpha doesn't access the internet so there is no default route
>> [...]
>
>  Really?  And when someone like your remote client at "12.34.56.78"
> pings the VMS system, whither should the VMS system send its reply?
>
>   I'd add that default route.
>

I'll do that. In fact, I can give them the command over the phone and maybe save myself a trip. PING wasn't really my goal, it was TELNET, so we'll see if that works with a default route.

I expected to see at least a "host unreachable" sent to the requester IP for a route problem, but I guess I expected too much. My notes say that some TELNET via VPN accessable sites don't have a default route but I'll check them.
>> > [...] What are [the Windows server's] route settings? [...] >> >> Still wondering. > > Still true. Does the Windows server have a default route? (Or some >other route (static or dynamic) which points back to the VPN router?)
>

I would guess that it does, but I'll look when I get there. Windows setup is a little, umm, simpler. Thanks for the input. I'll post back if setting the default route fixes my problems.


Steven Schweda
Honored Contributor

Re: Ping through VPN tunnel fails

 
Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

Setting the default route did the trick. It looks like I'll need to do some remedial
reading.

>> I expected to see at least a "host unreachable" sent to the requester
>> IP for a route problem, but I guess I expected too much.
>
 >  The (remote client) sender _knows_ the route from _its_ end.  The
>question is how the VMS system is supposed to know where to send its
>reply.
>

I guess I don't understand everything I know about TCP/IP. RFC 792 says:
##
Addresses

      The address of the source in an echo message will be the
      destination of the echo reply message.  To form an echo reply
      message, the source and destination addresses are simply reversed,
      the type code changed to 0, and the checksum recomputed.
##

So, that's what I expected to happen.

>>  My notes say
>> that some TELNET via VPN accessable sites don't have a default route but
>> I'll check them.
>
>   I'm too simple to use dynamic routing, but I'd guess that that might
>help those who use it.  Naturally, your (invisible) notes tell me less
>than a transcript showing actual commands with their actual output.
>

:-)  my notes obviously don't tell me much, either, and to me they're visible.

>> [...] I can give them the command over the phone [...]
>
>   Yup.
>
>> [...] PING wasn't really my goal [...]
>
>   If they both time out, then the cause might be the same.

That's what I thought, too, and is why I was concentrating on PING.

> The real
>nocturnal-do-nothing dog (I claim) is the difference between the VMS
>system and the similarly situated Windows system.

Agreed, and since this is TCIP/IP V5.4 ECO2 the differences are likely
even greater.

Steven Schweda
Honored Contributor

Re: Ping through VPN tunnel fails

 
Doug Phillips
Trusted Contributor

Re: Ping through VPN tunnel fails

Steven, thanks for your time.