Link to home
Start Free TrialLog in
Avatar of Tom-J-Lael
Tom-J-LaelFlag for Afghanistan

asked on

Can't access Novell Netware 5.1 server from across VPN

Overview:

Main office location and newly aquired Branch Office location
Firewall to Firewall VPN server using two Netgear FVG318 VPN firewalls.

Main Office:

192.168.203.X  network with 255.255.255.0 subnet - 192.168.203.1 is default gateway (netgear)
DHCP server is small business 2003 server and everything internally works fine

Branch Office:
172.28.112.X network with 255.255.255.0 subnet-  172.28.112.129 default gateway (netgear)
DHCP server is Netgear firewall

Firewall to firewall VPN is connected. VPN only works if two networks LAN subnets are different. Tried making both subnets the same and VPN connection broke.

Problem:
from branch office, I can successfully ping  across the VPN to the SBS2003 server inside main office network and any client in the main office network EXCEPT for the Novell Netware 5.1 server (192.168.203.10). The novell server is the ONLY node attached to the network that I cannot ping.

from inside the Main Office network, I can ping the novell netware server with absolutely no problems.

I have deduced that the issue is with the Novell server itself. There is some sort of networking or firewall rule that says only clients on the same subnet can connect to it. This thing is so old and I have zero experience with Novell.

So help!!!
I need help finding this rule with the guidance of a Novell guru

or..I need an idea for a better way of doing this VPN

clients on the branch side of the VPN have to have connection to this novell server in order to access their Foxpro accounting database...


HELP!!




Avatar of Jim P.
Jim P.
Flag of United States of America image

Netware 5.1 still had IPX/SPX as the primary protocol and TCP/IP was an afterthought. IPX isn't routable by default. I think that the you had to load the TCP/IP nlm manually.

It might be that the clients have IPX and when you ping from the NW server it loads the IP long enough to do the ping then unloads it again.

Do a "m TC*" from the console and make sure it is loaded. If not try
LOAD TCPIP.NLM

If that is good then check your TCPIP config with "inetcfg".
Avatar of ShineOn
Correcting jimpen -  NetWare, beginning with version 5.0 in 1998, used TCP/IP for its preferred protocol - it kept IPX for backward-compatibility.  IPX *is* routable by default, contrary to jimpen's opinion.  However, IPX is probably not an issue here.

The answer - NetWare is a Network Operating System, and by default is a multiprotocol router.  If you do not tell it what the route to the other network is, it will not respond to PING, because it's smart enough to know NOT to respond to requests from foreign networks that it does not know the route to.

How to configure the route to the other network depends on whether or not INETCFG was used to configure the networking components on the server.  If INETCFG was used, you use INETCFG to add a route, using the VPN router as the next-hop router address, and issue the "REINITIALIZE SYSTEM" command, which refreshes the networking components with the new settings.  If it wasn't, you'd have to edit some files on the server's SYS volume and restart the server, because REINITIALIZE SYSTEM only works if you use INETCFG.

You can use the PING.NLM program on the NetWare server to see if it can PING addresses on the other side of the VPN.
One additional tidbit, that does support jimpen's IPX theory in a sideways fashion - if you are trying to connect to the NetWare server via TCP/IP, you can only do so if you either use the Novell Client32 or have  NFAP/CIFS configured on the NetWare server for native-protocol access from Windows.

If you try to use the crapware(tm) client that comes with Windows, it *will* fail, because, although NetWare's been using TCP/IP for a decade, Microsoft can't go against their FUD party-line, so the client *they* supply only uses IPX/SPX.  It's deliberately-crippled crud that only lets you connect via an obsolete protocol that isn't even supported on Vista Cruiser.

On the branch-office PC's you will need to install the Novell Client32, custom (not typical) TCP/IP only (remove IPX if present), NDS, and unselect all optional components you don't use.  

If the tree name cannot be resolved by name to the NetWare server across the VPN you will also have to specify the server's IP address in the tree name and/or server name fields, when you use the client.

Search Experts-Exchange for Novell Client32 for more-detailed information on how to properly configure the client for optimal use.
Thanks ShineOn for not blasting me totally out of the water.

Its been a while since I even looked at anything below 6. And I wasn't a big hands on on 5 when we had it.
Oh, and WRT IPX and routability - it's not routable through a TCP/IP VPN unless it's tunneled (encapsulated in IP packets.)  It's routable through normal point-to-point router connections.  I think IOS still has IPX as a protocol option.

Since you're using a TCP/IP-based VPN rather than point-to-point, you aren't likely to be able to route IPX to/from the branch office, which is why you must use a TCP/IP-capable method to connect, like the Novell Client32 or by using NFAP/CIFS on the server to make it look like a Windows NT4 server (which is the version of Windows server contemporary of NetWare 5.x)

Interesting side note: FPNW, the Windows 2000 Server "equivalent" to NFAP/CIFS that makes Windows look like a NetWare server, makes W2K "look like" NetWare 3.x.  Hmmm....
Avatar of Tom-J-Lael

ASKER

Shineon...

I found the INETCFG portion but don't know the steps to create a new route. How do I do this?
ASKER CERTIFIED SOLUTION
Avatar of ShineOn
ShineOn
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yeah, NetWare v5.0 and later preferred TCP/IP, altho as late as NetWare v6.5 it still supports IPX.

The IPX-encapsulated-in-IP bit was called NetWareIP, or NWIP. Even if you can still find a copy, avoid it like the plague. Absolute garbage that should never been allowed to see the light of day. Usually caused far more problems than it solved.
Shineon,

I'll revisit this issue tomorrow. I'll let you know.

thanks,
Psi - NetWare/IP isn't the only way.  Certain VPN products will tunnel IPX in IP - BorderManager VPN for example.
>> Certain VPN products will tunnel IPX in IP - BorderManager VPN for example.

True, but it all sort of was lousy. I heard some companies kept IPX for years because of the routing issue. It made them less susceptible to being hacked. Hackers would get through whatever firewall, then be stumped because nothing was responding to their IP stack cracks.

But at a certain point you need to banish it. We had both IPX and TCP running at the same time for a while. We found that once we stopped the IPX we had a 30-40% drop in both LAN and WAN traffic.
I was in a company that kept IPX for years, using the BorderManager IP/IPX Gateway. Yes, that was sort of lousy.

That's not what I'm talking about.

Some VPN software and devices will tunnel IPX in its IP-based VPN "pipe."  Some will do it with routing, some will simply bridge.  Regardless, you can establish the routing using a NetWare server with two NICs and both networks bound.  It's not that hard to route IPX - just different.

As to it all sort of being lousy, again that depends on what you mean.  Yes, it will be a bit slower because the packets are encapsulated and have to be reassembled at the other end.  Yes, it will take more bandwidth overhead.  It's not the same as the IPX/IP gateway - and I think that might be what you're thinking of.  That required a crappy gateway client to be added to your PC, and that did cause all sorts of issues...

Once I convinced the PHB's that there was no real security in sticking with IPX-only on the LAN, we were able to get rid of the IPX/IP gateway.  We could still establish a BorderManager site-to-site VPN and tunnel IPX across if for legacy servers/apps, without the use of either the gateway or NetWare/IP.
Adding route on the Novell server did the trick.

I gave a B grade because after you pointed in the right direction, I was looking for actual steps to create the route as this was the first time I've ever touched a Novel server. The link you sent me to seemed like an extension of the discussion you were having in this thread.

I managed to thumb my way through it.
thanks!
Adding route on the Novell server did the trick.

I gave a B grade because after you pointed in the right direction, I was looking for actual steps to create the route as this was the first time I've ever touched a Novel server. The link you sent me to seemed like an extension of the discussion you were having in this thread.

I managed to thumb my way through it.
thanks!
Comment ID 17758297  in the linked PAQ had step-by-step stuff:

As to your questions - and some more advice (I was typing that last comment and had to leave my desk for a tad, which is why you responded before I hit "submit.")

1)  The "default IP address" is used within the "IP address management framework" feature to specify the default address certain server-based applications should use, like Apache, Tomcat, ExteND, DNS, FTP, MySQL and so forth.  It has nothing to do with the routing configuration of the server itself, so it's really moot.

2)  In inetcfg, protocols, TCP/IP, under the "LAN Static Routing" entry should be the routing table, which probably says "Select for list" or "Select to view or modify."  Not sure which.  Select it to get the static route table.

In that routing table, you should have a "Default route" entry with a "Next hop" address of the router (192.168.1.1) and a type of "passive."  If that's what you've already done, cool.

3)  If the first time you ran INETCFG it said it was copying the networking configuration, then you would've needed a reboot.  If it didn't say that, then it was already set up to use INETCFG and a REINITIALIZE SYSTEM should suffice.

4)  Do you have a) BorderManager or b) port filtering  running on this server?  If you're not sure, enter "M FILT*" on the server console - if FILTSRV.NLM shows up as loaded, you may have the ports or protocols blocked from non-local-LAN networks, and we should check your filter configuration.  That also would block PING.