Running eDirectory / NetWare / OES across UDP-blocking firewalls

For security reasons, customers may have inter-departmental firewalls that block all UDP datagrams.

It is still possible to run NetWare / OES / eDirectory trees that span such firewalls, but customers should be aware of the issues outlined below, and be prepared for a deterioration in performance when compared with networks in which UDP is not being blocked.

TIMESYNC

NCP time synchronization uses UDP. Timesync.nlm v5.09 is NTP-compliant and can be configured on a Reference timesync server each side of the firewall to supply time to Primaries/Secondaries on their respective sides of the firewall. Although NTP uses UDP123, there should be no need for the datagrams to cross the firewall, but instead to get time independently of each other from public NTP (or local GPS) servers.


NCPIP

NCPIP simply responds with the same protocol to whatever client requests it receives. There is no need to implement a new set parameter to disable NCPIP from responding to UDP requests, in fact that would be undesirable as UDP communication on the local side of the firewall would be disabled.
Note: Engineering has a copy of NCPIP that can be used to turn off UDP responses, but as NCPIP actually prefers TCP (port 524) it should not be necessary.


NDS

NDS can run over TCP. If UDP has been blocked, there may be some -625 errors on the DSTrace screen connecting to a UDP address on the other side of the firewall, but that does not mean NDS is not working.
DSAPing is no different to any other request that NDS sends. It simply sends a request through Winsock on whatever protocol is available.
A -601 error does not mean that NDS is not functional. It simply means that a resolve failed to find the object requested. If the server does not hold the object this would be correct but the error will still be displayed on the DSTrace screen.


DNS

DNS uses UDP, and that will not change. Customers may consider writing bespoke solutions that, for example, use FTP to transfer DNS requests across the firewall.
The NW client uses DNS via UDP for name resolution, but can be configured to use SLP instead.

DHCP

The client optionally uses DHCP to get initial connection information. If there is a local DHCP server, there will be no need for UDP datagrams to cross the firewall. Alternatively, the client may instead use SLP or a manually configured IP address to discover the initial connection.

INSTALLATION OF NEW SERVER INTO TREE

NWConfig uses UDP for its initial connection, hence without UDP it is impossible to install a new server into the NDS tree when the master replica of root is on the far side of the firewall. A fix would require that new Java modules be inserted into the NetWare 5 build (not a Support Pack).

There are several ways that a customer could get around this problem:
- Install the new server into the tree whilst it is at the same site as the server holding the master of root, then ship it to its ultimate destination.
- Temporarily move the server holding the master of root to the site where the new server is to be installed.
- Temporarily open up UDP to the remote site for the duration of the initial NDS synchronisation and installation. The server could thereafter be set to use only TCP.
- Temporarily open up IPX and SAP to the remote site for the duration of the initial NDS synchronisation and installation. The server could thereafter be set to use only TCP.


IPX COMPATIBILITY MODE

CMD is necessary when an IP device communicates with an IPX device or when an application requires a direct IPX interface. All communication destined for an IPX device through a MA will use UDP2645. Devices querying the MA for information on services available and routes to those services will use the following protocols:
  NW5 server running SCMD to MA - TCP
  Client running CMD to MA - UDP
  MA to MA - UDP

CMD will not be enhanced to use TCP rather than UDP, so cannot be implemented across UDP-blocking firewalls.

These are the options available to overcome the problem:
- Use the client in IP-only mode. Althought it will be possible to map drives, access files & NDS, not all NetWare utilities and 3rd-party applications will work.
- Use the client in IP + IPX Mode and route IPX packets as well as IP packets.


SLP

All SLP conversations begin with multicasts or unicasts on UDP427. The UA will contact the SA or DA using UDP, and only if the response is larger than one packet can hold will the UA connect via TCP and re-request.

These are the options to overcome the problem:
- Update the client to allow static configuration of SLP Directory Agents. The client could then make TCP-only requests to the known DA.
- Don't use SLP. SLP is not required for the client to run. A DNS name or IP address can be specified for the preferred server and NDS name resolution started from there. With this solution the ability to use Bindery server names in an IP-Only environement is lost (e.g. displaying a list of servers in Network Neighborhood).

Formerly known as TID# 10014465
Formerly known as TID# 2948834