The Problem with NCP Protocol over NAT
Novell Cool Solutions: Feature
By Akos Szechy
Digg This -
Posted: 19 Apr 2006
OverviewThe question often arises about whether one can use the Novell Client over the Internet. Also, similar questions arise about servers: can there be multiple servers in the eDirectory tree across the Internet?
This document tries to explain a bit about the NCP protocol. It answers the most common questions about why is it not supported to use the Novell client and eDirectory over a NAT connection.
Novell eDirectory uses the NetWare Core Protocol (NCP), which is built on top of the TCP/IP infrastructure. NCP is used for communicating with the clients as well as with other eDirectory servers. NCP uses TCP and UDP port 524 by default; however, with eDirectory 8.8 you can run an eDirectory service on different ports as well.
Network Address Translation
Network address translation (NAT, RFC 1631) is often used on the Internet to translate multiple hosts to one IP address. This is also called masquerading.
Within the corporate network, people usually use internal IP addresses that are not routeable on the Internet; however, users still need to communicate with the rest of the world. A solution for this problem is NAT. With NAT, a server or router converts all the requests coming from the internal network to public IP addresses. It then sends the requests to the Internet as though they were its own requests. When it gets a reply, it forwards it to the internal client, based on its internal matching table.
This solution is great because it doesn't require a lot of public IP addresses. It also increases security, as the internal hosts are not directly visible to the Internet. On the other hand, it does have some limitations. However, every company uses one of these internal IP addresses; that way they don't have to worry if two machines at different companies are using the same address, such as 10.1.1.1.
Basically there are three different types of NAT:
- Dynamic NAT - This is the most common, where all the internal hosts automatically translated to a public IP address of the server or router
- Static NAT - There is a matching table set up on the server which tells which internal hosts should be translated to which external IP address. All the requests coming from different hosts are gets dropped.
- Mixed - All the machines existing in the matching table are translated to the appropriate public IP address, while the rest are dynamically translated to a predefined public IP address.
The NCP protocol was designed to run in IPX environment, so at that time there was no need for IP Address translations. In an IP environment, the NCP protocol uses the server's real IP address inside the packages. NAT, however, only changes the addresses in the IP header of the packet - it does not change the server's IP address in the NCP information. Therefore, if you have a server on the internal network with IP address 10.1.1.1, but you are sitting in a different network with your client and you want to connect to that server over the Internet, you have to go through a NAT connection. NAT routers usually do not allow you to use the NAT service to private addresses. This can be changed in some systems, but still you must be sure that you are not sitting in a network where 10.1.1.1 is routed to anywhere else than the NAT server/router.
The following examples show that when the client tries to log in, it will receive the information from the server. The internal IP address will appear in the NCP header, which of course the client cannot connect to, because our current NAT configuration does not allow private addresses to be used as destinations.
In these examples we use Ethereal to check what is going on the network. We are using a pretty simple configuration:
We have a client with IP address 10.1.1.2 and a default gateway of 10.1.1.1. The default gateway has two IP addresses - 10.1.1.1 and 172.16.63.17 - where we do dynamic network address translation. We have another server with IP addresses of 172.16.63.16 and 10.1.1.5, which simulates the server on the other side of the Internet.
Note: IP addresses are internal IP addresses - they are not used over the Internet.
Figure 1: Dynamic NAT server configuration
The first example does not actually use NAT - it's just to see how NAT works. We are pinging from the client to the second address and making a packet trace that shows all the traffic:
Figure 2: Packet trace for network traffic
In the figure above, the ping request is started from 10.1.1.2 to 172.16.63.16 (packet 1). The NAT service catches the packet, replaces the source IP address with 172.16.63.17 (the NATed address), and sends the ping request to 172.16.63.16 (packet 2). The destination server receives the packet as though it were from 172.16.63.16, so it replies to that host (packet 3). When the server performing the NAT receives the packet, it uses its internally built NAT connection table and checks where to forward the reply to - in this case, it's 10.1.1.2 (packet 4).
Let's get a bit deeper into NCP. In the following example we will see a trace that was taken as part of a login procedure. eDirectory has to resolve an object, which means it is querying the database for the server where the object can be found. The server being queried will return the addresses of the servers that hold replicas of the object (called Referrals).
Figure 3: Login trace
In the above diagram, the client tries to resolve a replica for the admin.services user from 172.16.63.17. In this case, we want to log in to the server which is doing the NAT service, not to the remote server. The Resolve Name operation returns the following results:
Figure 4: Results from Resolve Name
As you can see from the result, we can connect to two servers to get a real copy of the .admin.services object: 10.1.1.1 and 172.16.63.17.
This example shows what happens when we go through a NAT connection.
We do the same Resolve Name as we did in the previous example, but in this case we removed the replica from the login server. This way it will return only a server in the internal network with an address of 10.1.1.5, so if we want to log in we would have to go to that server:
Figure 5: Resolve Name for a specific server
You can see, as before with the PING packets, what is going on:
- The client asks the login server to resolve admin.services (packet 9).
- The NAT server forwards the request as its own (packet 10).
- The login server replies to the NAT server with the requested information (packet 11).
- The NAT server forwards the information to the client (packet 12).
- The client tries to connect to 10.1.1.5. As we have an address of 10.1.1.2, it will try to find it on the local network and it will fail because it cannot get through the NAT connection.
So, the result of the operation is this:
Figure 6: Failed client connection
Can you see now why is it a problem to connect over NAT? This address is part of the NCP header, so it will not be changed by the NAT service. The NCP header will always contain the internal IP address of the servers, so when the client or server tries to connect to those internal IP addresses, it will have to go through the NAT service. However, what happens if both networks contain the same IP address, or NAT is not allowed to translate internal IP addresses? Don't forget, we are connecting two different networks with a NAT connection, so both networks could be using the 10.0.0.0 address!
As you can see, the NCP over NAT connection is quite tricky and it does not work very well. Therefore, it is suggested that if you want to log in to your network or you want to connect multiple servers over the Internet, you should set up a VPN connection between the client and the server or between the servers to route the appropriate IP addresses.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com