ABSTRACT:

QUESTION:

ANSWER:

EXPLANATION:

What is an IP Protocol ?

In the Internet Protocol version 4 (IPv4) there is an 8-bit field called "Protocol", to identify the next level protocol.

For a TCP datagram this field would be set to the value "6", and a UDP datagram would be "17". You can use the following link to determine all of the possible values that this field can represent  IP Protocols

For example an IP datagram constructed by a client when setting up a telnet session would have an IP Protocol number of type 6 (TCP), and a TCP destination port of 23 (Telnet)

So to make sure that you understand this lets look at some examples.
 

Example

1. A DNS query	The client builds a datagram of protocol type UDP(17) with a UDP destination port of 53 (DNS Daemon on remote host).
2. An ICMP ping packet	The client builds a datagram of protocol type ICMP(1) with no destination port (This packet is neither TCP or UDP and therefore does not have a destination port).
3. A telnet session	The client builds a datagram of protocol type TCP (6) with a destination port of 23 (Telnet Daemon on remote host).
4. SecuRemote Client IKE Key Exchange	The client builds a datagram of protocol type UDP (17) with a destination port of 500 (ISAKMP Daemon on remote host).
5. SecuRemote Client Encrypted Datagram	The client builds a datagram of protocol type ESP (50) with no destination port (This packet is neither TCP or UDP and therefore does not have a    destination port).

So I hear you ask yourself, why do some of the above have a destination port and others not ?

Well if a TCP or UDP header is required when assembling a datagram it is placed after the IP header to identify the service required on the remote host (as well as many other things). Some services running on remote hosts don't require a port number to determine what is included in the datagram, they just use the protocol number. For example if a host receives an ICMP echo request the TCP/IP implementation knows from examining the IP Protocol field that this datagram is for the ICMP daemon and passes the packet to the daemon for further processing.
If  a host receives an IP datagram and the IP Protocol field is set to "6"(TCP) it could be for one of many services (telnet, ftp, smtp, ssh etc.) and therefore needs a further field for identification.
This is where the source and destination (TCP/UDP) fields come in to play.

So to make sure that you understand this lets look at some examples
 

Example

1. A server receives an ICMP echo request packet	The server's TCP/IP drivers examine the "IP Protocol" field and find the value "1".This is an ICMP packet says the server. The TCP/IP drivers pass the datagram straight to the ICMP daemon who will determine what type of ICMP code is contained.
2. A server receives a Telnet datagram	The server's TCP/IP drivers examine the "IP Protocol" field and find the value "6".This is a TCP packet says the server. The TCP/IP drivers pass the   datagram to the next level in the stack (Transport Layer) which then examines the TCP header and find the "Destination Port" field set to 23 and passes the packet to the telnet daemon who is listening on this port number.
3. A server receives an IKE Key Exchange packet	The server's TCP/IP drivers examine the "IP Protocol" field and find the value "17" .This is a UDP packet says the server. The TCP/IP drivers pass the datagram to the next level in the stack (Transport Layer) which then examines the UDP header and find's the "Destination Port" field set to 500 and passes the packet to the ISAKMP daemon  who is listening on this port number.
4. A server receives an ESP encrypted datagram	The server's TCP/IP drivers examine the "IP Protocol" field and find the value "50".This is an ESP packet says the server. The TCP/IP drivers pass the datagram straight to the Firewall  daemon who will decrypt the datagram..

Why do I need to know all this ?  you ask yourself.

Well this is the key to understanding HIDE NAT.

How does HIDE NAT work ?

When many hosts hide behind one IP address the NAT device has to have some way of determining who is talking to who in order that the reply datagrams
can be routed back to the correct host. This is done using a connections table and goes something like this.

1.	Host Scully (10.0.0.1) connects to 216.33.41.80 with a browser.
2.	The server 216.33.41.80 will see packets arriving from the hide address of 195.166.10.10, Source Port of "1024", Destination Port of "80" and so will send reply packets back to address 195.166.10.10 with a  Destination Port of "1024" and Source Port "80".
3.	As the above address is a HIDE NAT address, how will it know which reply packets to send to which internal host ?
4.	From the table below it can be seen that the address 10.0.0.1 has a unique Translated Source Port of 1024 and so the HIDE NAT device will route the IP Datagram to this host.

 

As can be seen from the above connections table the "Source IP Address" and "Source Port/Translated Source Port" fields can be used to create a unique mapping between the host and the 216.33.41.80 web server by the HIDE NAT device.
 

So to make sure that you understand this lets look at some examples
 
 

Example

The HIDE NAT device receives an IP datagram with the Protocol field set to 6 (TCP) for host 195.166.10.10 with a TCP Destination Port of 1025 and a TCP Source Port of 80.	Which internal host is the datagram routed to ?
The HIDE NAT device receives an IP datagram with the Protocol field set to 6 (TCP) for host 195.166.10.10 with a TCP Destination Port of 1027 and a TCP Source Port of 80.	Which internal host is the datagram routed to ?
The HIDE NAT device receives an IP datgram with the Protocol field set to 50 (ESP) for host 195.166.10.10.	Which internal host is the datagram routed to ?

Question 3 above is different from the other examples that we have looked at so far.

The NAT device in this instance will have to use the "IP protocol" field  to create a unique mapping between each host on the internal network and the external encrypting gateway as there is no source or destination port when no TCP or UDP header is present.
 

Now look at the table below when we have four SecuRemote clients on the internal network behind the HIDE NAT device.
 

Source IP Address	Destination IP Address	Original Source Port	Translated Source Port	Destination Port	IP Protocol	Hide Address
10.0.0.1	195.166.72.1	NONE	NONE	NONE	50 ESP	195.166.10.10
10.0.0.2	195.166.72.1	NONE	NONE	NONE	50 ESP	195.166.10.10
10.0.0.3	195.166.72.1	NONE	NONE	NONE	50 ESP	195.166.10.10
10.0.0.4	195.166.72.1	NONE	NONE	NONE	50 ESP	195.166.10.10

The NAT device in this instance will have to use the "IP protocol" field  to create a unique mapping between each host on the internal network and the external encrypting gateway as there is no source or destination port when no TCP or UDP header is present.
Now consider the following scenario.
The host 10.0.0.1 sends an encrypted ESP packet to the Checkpoint Firewall 195.166.10.10.
The HIDE NAT device replaces the source address 10.0.0.1 with 195.166.10.10.
The Checkpoint Firewall sends a response datagram with a source address of 195.166.72.1 and a destination address of 195.166.10.10.
The HIDE NAT device receives this datagram and looks in the connections table for a unique mapping.
As there are currently four connections with ESP defined in the IP Protocol column the HIDE NAT device cannot dtermine which internal host to route the datagram to.

And now for the clever bit !!

If we take the ESP datagrams and encapsulate them inside a UDP datagram we will once again have a source and destination port to provide our unique mapping.
The SecuRemote client will take the ESP datagram and encapsulate it within a UDP datagram before sending this to the Checkpoint Firewall.
The HIDE NAT device connection table will now look like the table below.
 
 

Source IP Address	Destination IP Address	Original Source Port	Translated Source Port	Destination Port	IP Protocol	Hide Address
10.0.0.1	195.166.72.1	UDP 2746	UDP 1024	UDP 2746	17 UDP	195.166.10.10
10.0.0.2	195.166.72.1	UDP 2746	UDP 1025	UDP 2746	17 UDP	195.166.10.10
10.0.0.3	195.166.72.1	UDP 2746	UDP 1026	UDP 2746	17 UDP	195.166.10.10
10.0.0.4	195.166.72.1	UDP 2746	UDP 1027	UDP 2746	17 UDP	195.166.10.10

As can be seen from the above connections table we now have our unique mapping between the internal host and encrypting gateway using the UDP source and destination ports.

The Only problems that remain are ;
1. Getting the firewall to understand that UDP datagrams of destination port 2746 are actually ESP packets hiding within a UDP datagram. This is done with a change to the objects.C file on the firewall
2. Getting the SecuRemote client to encapsulate the ESP packets before sending to the firewall.

Both of the above can be be performed by reading the following document  kindly provided by PhoneBoy SecuRemote and NAT