EEPW论坛

In the scenario described in figure -3, when the local host sends a packet to a machine with the IP address 192.32.45.123, NAT replaces the source IP address in the packet (10.1.1.2), with its globally unique IP address (216.103.197.12) and transmits it. Since the source IP address has been modified in the packet, the response for this packet would be sent to the NAT. The NAT then replaces the destination IP address in the packet with the IP address of the local host and transmits the packet to the host in the stub domain. This address translation is totally transparent to the local host. Network Address Port Translators (NAPT) One of the drawbacks of the earlier solution is that the number of local machines that can be connected to the Internet simultaneously is limited to the availability of globally unique IP addresses in the NAT. To overcome this limitation, the NAT can be extended further to enable port translations as well, apart from address translations. This is known as masquerading or Network Address Port Translation (NAPT). In NAPT the port number of the local host in the TCP or UDP header is also translated before the packet is sent out of the stub domain to the Internet. Consider the following scenario. Machine “Local Host A” from the local stub domain having an IP address of 10.1.1.2 sends a packet to a machine with 192.32.45.123 as its IP address. Let us assume that the local machine uses port 1034 to initiate a TCP session with the machine at 192.32.45.123. Hence the source port in the packet would be 1034 and the destination port number would be 80 (HTTP request). Similarly, another machine from the local stub domain, say “Local Host B” with the IP address 10.1.1.3 initiates a TCP session to the machine at 192.32.45.123. Let the port that this machine uses to initiate this session be 1500. Hence the source port in the packet would be 1500 and the destination port number would be 80. When the source address alone of both these packets is replaced with the unique IP address of the NAT (216.103.197.12), an ambiguity would arise while mapping the response packets. The NAT would not be able to determine whether the response packet is destined for “Local Host A” or for “Local Host B”. To resolve this ambiguity, the source ports of the local machines are also translated before the packet is sent to the Internet. The port numbers that are used to replace the actual port numbers in the IP packet are unique for each session. In the above scenario, the port number of “Local Host A” could be changed from 1034 to say 5001 and that of “Local Host B” could be modified to 5002. When the NAT receives the response packets, it would be able to determine by checking the destination port number in the IP packet. If the destination port number is 5001, the NAT could conclude that the packet was actually destined for “Local Host A”. Whereas if the destination port number in the response packet was 5002, the NAT could map the packet to “Local Host B” by replacing the destination IP address and the destination port number to 1034(the port number used by “Local Host B” to initiate this session). Firewall Any device that controls network traffic for security reasons can be called a firewall. A firewall puts up a barrier that controls the flow of traffic between networks. The most basic firewalls are built on routers and work in the lower layers of the network protocol stack. Packets are first checked and then either dropped or allowed to enter based on various rules and specified criteria. Adding NAT and Firewall to the TCP/IP stack in VxWorks To add NAT and firewall to an existing TCP/IP stack in VxWorks, one should manipulate IP packets at the exit point between a local stub domain and the Internet. IP packets can be captured by hooking into the TCP/IP stack. The IP header and TCP/UDP headers can be stripped from the packet and checked against the firewall rules. Address translation needs to be performed on the packet before transmitting it to the Internet and before delivering it to the local network. Packet capturing in VxWorks VxWorks provides two hooks by which, we could capture packets in the network. These hooks are: EtherHook IpFilterHook VxWorks provides two libraries using which these hooks could be implemented. The EtherHook can be implemented using etherLib and the IpFilterHook can be implemented using ipFilterLib. EtherHook The EtherHook provides direct access to raw Ethernet packets. Incoming and outgoing packets can be examined or processed using the hooks etherInputHookAdd() and etherOutputHookAdd(). etherInputHookAdd(): This function adds a routine to receive all Ethernet input packets. Synopsis: STATUS etherInputHookAdd() ( FUNCPTR inputHook, /*Routine to receive Ethernet input packets*/ Char* pName, /*Name of device*/ Int uint /*unit of device*/ ) his routine adds a hook routine (inputHook) that will be called for every Ethernet packet that is received. The calling sequence of the input hook routine is: BOOL inputHook ( struct ifnet pIf, /*interface packet was received on*/ char *buffer, /*received packet*/ int length /*length of received packet*/ ) etherOutputHookAdd(): This function adds a routine to receive all Ethernet output packets. Synopsis STATUS etherOutputHookAdd ( FUNCPTR outputHook /*routine to receive Ethernet output*/ ) This routine adds a hook (outputHook) and this function would be called for every Ethernet packet that is transmitted. This routine is immediately called immediately before transmission. The calling sequence of the output hook routine is: BOOL outputHook ( struct ifnet pIf, /*interface packet will be sent on*/ char *buffer, /* packet to transmit*/ int length /*length of packet to transmit*/ ) After the processing the Ethernet packet, both the hook routines should either return true or false. The hook should return true if it has handled the packet and no further action should be taken with it. It should return false if normal processing of the packet should take place. IpFilterHook The IpFilterHook provides direct access to IP packets. The input hook can be used to receive, examine and process raw IP packets that are part of IP (Internet Protocol) protocols. This hook can be added using the IpFilterHookAdd() function that is provided in the ipFilterLib library. ipFilterHookAdd(): Synopsis STATUS ipFilterHookAdd ( FUNCPTR IpFilterHook /*routine to receive raw ip packets*/ ) This routine adds a hook routine that will be called for every IP packet that is received. The filter hook function will be executed in the context of tNetTask, which runs at priority 50. The calling sequence of the filter hook routine is: BOOL IpFilterHook ( struct ifnet *pIf, /*interface packet was received on*/ struct mbuf **pPtrMbuf, /*pointer to pointer to an mbuf chain*/ struct ip **pPtrIpHdr, /*pointer to pointer to IP header*/ int ipHdrLen /* IP packet header length*/ The hook routine should return TRUE if it has handled the input packet and no further action should be taken with it. If returning TRUE the ipFilterHook is responsible for freeing the mbuf chain by calling m_freem(*pPtrMbuf). If the IpFilterHook returns false, normal IP processing continues i.e., options processing, IP checksum computation etc. PtrIpHdr is a pointer to a pointer to a IP header. The pointer to the ip header is obtained by de-referencing pPtrIpHdr. The ip header is used to examine and process the fields in the ip header. The fields ip_len, ip_id and ip_offset in the ip header are converted to the host byte order from the network byte order before a packet is handed to the filter hook.

Our solution to NAT and Firewall Given the two possible solutions for NAT in VxWorks, our solution to NAT and firewall is by using the IpFilterHook. Why not EtherHook? There are a couple of disadvantages in using the ether hook. They are: Only certain VxWorks network drivers support ether hooks Requires IP checksum adjustment: If ether hooks are used, the packet is manipulated below the IP layer. Hence the IP checksum has to be adjusted accordingly. This is not required if the ipFilterHook is used as the IP layer performs this IP checksum computation once the packet is returned to the IP stack from the hook routine. Packet manipulation for NAT and Firewall Once the hook routine gets the IP packet, the NAT should strip the IP header and the TCP/UDP headers from the packet. The protocol field in the IP header of the packet is used to determine whether it is a TCP or a UDP packet. Fire walling and address translation is performed based on the information obtained from the headers. The NAT uses a mapping table to perform address translations. Whenever a machine in the local network initiates a new session is initiated, the NAT dynamically adds a new entry to the mapping table. This entry is used to perform address translation A typical mapping table used for NAT would look like the following: NAT Mapping Table Real Src IP addr Real Src port Dest IP addr Dest port NAT IP addr NAT port Manipulating outgoing packets: Since the firewall rules are based on local IP numbers, outgoing packets are checked against the firewall rules before performing address translation. If the firewall rules allow the packet to be transmitted, the local IP address (private IP address) is replaced by the globally unique IP address of the NAT and the source port number in the packet is replaced by a unique port number assigned by NAT for this session. The NAT first checks the mapping table to find an entry corresponding to this session. If such a mapping exists, the NAT replaces the source IP address and the source port number in the packet with the “NAT IP address” and the “NAT port number” specified in this mapping entry. If such a mapping is not available for this session, NAT creates one and uses it for address translation. Since the IP address and the source port number have been modified in the packet, the TCP/UDP checksum has to be recomputed accordingly. Manipulating incoming packets: For an incoming packet, address translation is done before checking it against the firewall rules. The NAT looks for an entry in the mapping table by comparing the destination IP, destination port, NAT IP and NAT port in the mapping table with the source IP, source port number, destination IP and destination port number in the IP packet. NAT replaces the destination IP address in the packet with the “Real Src Ip addr” entry and the destination port number with the “Real Src port” entry. Since the destination IP address and the port number have been modified, the TCP/UDP checksum is adjusted before sending the packet to the appropriate host in the local domain. Conclusion Even though the Network stack in VxWorks lacks NAT and Firewall modules, we can add them using the filter hook. Our small footprint implementation of NAT and Firewall modules when tested performed well. (The End)