Cannot login to NW5 after removing IPX

The only server in the tree is a NW5 with SP6a, Border Manager 3, SP3.

After removing IPX binding on internal LANs NIC on server, the clients can no longer login to the tree. They are able to ping the server but the NW client (ver 3.3) cannot see the tree or server.

We've tried to add the servers name/ip to the nwhost file
We've also tried to load slpda.nlm at the server and configure Service location tab at the clients.

Any ideas out there?
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Jsrb01Connect With a Mentor Commented:
The exceptions may already be there. First you need to confirm the problem is filtering. Have you unloaded IPFLT.NLM yet? If you do, and you are able to login, then filtering is most likely the problem.

If the below filters do not help, isolate the BM server on it's own segment with one client. Then SET TCP IP DEBUG = 1 on the console, and try to login.

(This is what it looks like when I block my Soldier of Fortune server packets)
RECIEVE:pktid:17128> ttl:128 (UDP) UDP:Source Port:1038Destination Port:28910
(DISCARD)- Reason(Filtering)

You will need to add whatever it's filtering during your login to the exception list.

Personally, I would jsut add an exception that states - <ANY> traffic from your local ( is allowed to you private interface, and vise-versa. Remember , the more filters you add, the more resources IPFLT will consume.

From TID: 10050135(allowed packets nw5)
TCP 524 - NCP Requests - Source port will be a high port (1024-65535)
UDP 524 - NCP for time synchronization - Source port will be a high port
UDP 123 - NTP for time synchronization - Source port will be the same
UDP 427 - SLP Requests - Source port will be the same (427)
TCP 427 - SLP Requests - Source port will be the same (427)
TCP 2302 - CMD - Source port will be a high port
UDP 2645 - CMD - Source port will be the same (2645)

Did you check the protocol order on the clients?? Perhaps you need to have NWHOST listed first with IPX deleted as an available protocol.
Also - when installing the clients, you are prompted for the Protocol to use (either IPX or IP or both) - if you originally selected IPX without IP, then you will have to reinstall the client software and select IP.  Even if you have TCP/IP installed on the workstation, unless you told the NetWare Client to use IP, it won't be able to connect to a Pure IP environment.
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

1610Author Commented:
Thanks for your response!

The clients are installed with IP only.
I haven't checked the Name resolution order, but I think the client puts the nwhosts first as default, then it uses SLP...? (This problem occurs on a site fare away, so I'm not able to check it)

In both ways, shouldn't it work with the settings in nwhost or the settings in Service location?

Is your BM config allowing authentication of IP packets in?Unload IPFLT.NLM. Then try.
set tcp ip debug = 1 ... see what requests (if any) are getting to the private interface, and what it's doing with them.

1610Author Commented:
Jsrb01 - thank you for your respons. I'm not any good on BorederMangaer or filtering of packets, but I will try what you suggest.

Is the filtering relevant, when I tell you that the server and the client is on the same LAN, in the same zone and no routers between them?

1610- Yes it could be relevant if you are authenticating via TCP/IP. BM(or netware for that matter) Can be configured to filter ANY packets from anywhere. Regardless of hops, etc. So if you sent a NCP login request to your private NIC, and filtering was enabled to prevent that, it would discard the packet, and the login request. It sounds like when you removed your private IPX interface binding, IPX was the only allowed protocol on your internal NIC/network.

You stated that your clients are all using IP only. And the problem occured when you removed the IPX binding? Why were you running IPX?

Why are you running BM?

1610Author Commented:

This server is running strictly as a firewall / gateway in the network. The reason IPX was active, was because of the ArceServe Manager. The earlier versions of ArcServe was operating on IPX, now it's able to use IP.

The users don't really have to log on to the server, only admin for administrative tasks.

I know the filters are set up to filter everything, with exceptions turned on. What packets do I need to allow?
technically, ARCserve Manager (ARCserve 7 for NetWare) cannot use IP.  The reason I say this is because you can have a host entry in your nameserver for your ARCserve server and ARCserve Manager can't see it.  However, if you put the exact same entry into your HOSTS file on your local workstation THEN ARCserve Manager can see it.

Go figure.

1610Author Commented:

Jsrb01 : Thanks, you cleared things up a great deal for me. I will try this, but I will not able to for at least a week.

Then I will get back to you all.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.