3.7 Virtual NAT & Virtual DHCP Servers

The PacketiX VPN Server and PacketiX VPN Bridge Virtual HUBs feature SecureNAT functionality. This section will explain SecureNAT concepts, methods for setting them and precautions.

3.7.1 What is SecureNAT?

SecureNAT Overview

 The SecureNAT function is a hitherto unknown innovative proprietary technology developed for the PacketiX VPN, the use of which enables the creation of a more secure network.

The SecureNAT function is broadly divided into two parts: the virtual NAT function and the virtual DHCP server function. The Virtual HUB Administrator can enable either or both the virtual NAT and virtual DHCP server when SecureNAT is enabled.

Please refer to 「10.11 Using SecureNAT to Set Up a Remote Access VPN With No Administrator Rights」 for details on how to set up the SecureNAT function.

Virtualizing the Broadband Router Function

Many general broadband routers developed and commercialized for business and consumer applications integrate the NAT function and the DHCP server function, and connecting a computer internally to a broadband router enables access via NAT to global IP networks (such as the Internet) in addition to the automatic assignment of a private IP address to that computer.

The PacketiX VPN SecureNAT function virtualizes the NAT and DHCP server functions equipped in typical broadband routers and, by carrying out all processing just in user mode, enables the use of functions equivalent to a broadband router between a virtual and a physical LAN.

Fig. 3-7-1 SecureNAT function

SecureNAT Virtual Interface

The SecureNAT function can be set and enabled/ disabled for each Virtual HUB. Unlike the local bridge function, all settings of the SecureNAT function can be set by the Virtual HUB Administrators. Enabling the SecureNAT function creates a virtual VPN session called a SecureNAT session within the Virtual HUB and creates a virtual network interface (VNI) as if there were a single network adapter within that VPN session. This is called a virtual host network interface.

A virtual host network interface is layer 2 direct connected to the Virtual HUB. As such, from the perspective of other VPN client computers connected to the Virtual HUB and the perspective of cascaded or bridging destination computers when the Virtual HUB is cascaded or locally bridged to other Virtual HUBs or physical LANs, the SecureNAT function's virtual host network interface is recognized as being equivalent to a single computer. The virtual host network interface can also assign IP addresses.

Using SecureNAT with General User Authority

The SecureNAT function and virtual NAT / virtual DHCP server all run as user mode programs. In order to realize a complicated mechanism such as the one present in the virtual NAT in particular, it is usually necessary to use the kernel module within the operating system.

In order to realize the virtual NAT, the PacketiX VPN requires absolutely no special processing in the operating system's kernel mode nor the use of the kernel mode's NAT function. Accordingly, all SecureNAT functions including the virtual NAT function can be freely executed with general user authority.

Aims of SecureNAT Use

The SecureNAT function can be use for the following objectives.

• Use as a Simple Network Gateway
  Even setting up the VPN Server and Virtual HUB and remotely connecting to that hub only results in closed communication within the Virtual HUB, so it is possible to communicate with the physical network connected to the computer running the VPN Server. Using local bridging in this case commonly involves a layer 2 connection between the Virtual HUB and the physical network, but using the SecureNAT function enables communication with the network connected to the computer operating the VPN Server via the Virtual HUB's virtual host network interface. Therefore, it is possible to make use of SecureNAT's virtual NAT function when preferring not to use the local bridging function, or unable to use it due to not possessing the computer's System Administrator authority or due to use of a UNIX OS version of the VPN Server or VPN Bridge other than Windows, Linux or Solaris.
• As a DHCP Server
  Of the SecureNAT functions, it is possible to enable only the DHCP server. In other words, it is possible to use only the DHCP server function operating within the Virtual HUB Ethernet segment. This allows VPN Clients and local bridge destination client computers remotely accessing the Virtual HUB to receive IP addresses assigned by the virtual DHCP server.
  Normally, using DHCP automatic IP address assignment requires locally bridging that Virtual HUB to a separate network of the DHCP server or connecting to the Virtual HUB from the DHCP server with the VPN Client using the Virtual Network Adapter, but the SecureNAT function's Virtual DHCP server function eliminates this need.
• As a Simple Gateway to Remotely Access Remote Sites
  Remote access VPN to a remote site (for instance, sites on which equipment maintenance is to be carried out via the network) using the PacketiX VPN typically involves installing the VPN Server and VPN Bridge on that remote site's computer and connecting to it with a VPN Client or setting up a continuous cascade connection from that site to a VPN Server set up in a separate location, thus enabling communication with a computer node on that remote site using the PacketiX VPN. However, the SecureNAT function can be used as an alternative when a local bridge cannot be set up on a remote site's computer for security or costs limitations or when the OS does not support the PacketiX VPN local bridging function. Please refer to 「10.11 Using SecureNAT to Set Up a Remote Access VPN With No Administrator Rights」 for details on these methods of use.

Enabling the SecureNAT Function

This function is disabled in default mode. To enable the SecureNAT function, click on [Virtual NAT & Virtual DHCP Server (SecureNAT)] button in the VPN Server Manager and display the [Virtual NAT and Virtual DHCP Server function (SecureNAT) Setting] window (all subsequent explanations relating to SecureNAT assume that this window is open). Next click on [Enable SecureNAT].

 In the vpncmd utility, SecureNAT commands all begin with "SecureNAT", "Nat" and "Dhcp". To enable the SecureNAT function for example, use the [SecureNATEnable] command.

Fig. 3-7-2 Virtual NAT and Virtual DHCP Server function (SecureNAT) Setting window

3.7.2 Setting the Virtual Host Network Interface

The SecureNAT function enables setting of information relating to the VNI of the virtual node (virtual host) created inside the Virtual HUB.

 Click on [SecureNAT Configuration] in the VPN Server Manager and enter the relevant details in the [Virtual Host Network Interface Setting] entry. A list of the entries and default values which can be set is as follows.

Fig. 3-7-3 Virtual host administration window

3.7.3 Virtual NAT

Virtual NAT Function Settings

Set the [Use Virtual NAT Function] checkbox to enable status in the VPN Server Manager to use the SecureNAT's virtual NAT function. Contrarily, select disabled status when not using the function. When starting SecureNAT, the virtual NAT function is enabled by default.

A list of the entries and default values which can be set is as follows.

To set each option, use the VPN Server Manager to make the relevant entries in the [Virtual NAT Setting] box inside [SecureNAT Setting]. In the vpncmd utility, use the [NatSet] command.

Fig. 3-7-4 Virtual NAT function administration window

Using the Virtual NAT Function

TCP/IP and UDP/IP communication using the virtual NAT function is used as follows.

1. Make the appropriate settings and enable the SecureNAT and the virtual NAT function in the Virtual HUB. In particular, match the virtual host's IP address & subnet mask with the IP network address and subnet mask used in that Virtual HUB.
2. In the TCP/IP settings on a separate client computer on the Virtual HUB side (it does not matter whether this is connected by a physical local bridge and cascade connection or via the VPN Client), set the IP address of the SecureNAT virtual host running on the Virtual HUB as the default gateway (combining with the virtual DHCP server function described below also enables automatic settings).
3. When the client computer attempts to perform TCP/IP or UDP/IP communication, the virtual NAT operates entirely as a single router with NAT functionality enabling access to a physical network's host via the computer running the Virtual HUB using that computer's existing network interface. A new session is registered on the virtual NAT function's NAT session table at that time. To display the NAT session table, click on the [Virtual NAT Router Status] button in the VPN Server Manager. In the vpncmd utility, use the [NatTable] command.

Operating Principles of the Virtual NAT Function

 The virtual NAT function realizes IP routing and NAT (IP masquerade) processing, typically carried out in kernel mode, in user mode.

The hierarchical relationship of the network protocol stack on a system with NAT functionality in kernel mode is shown in the figure below.

Fig. 3-7-5 Stack diagram of network modules in combined normal kernel mode NAT & PacketiX VPN NAT

The area in red in the diagram above denotes those operating in kernel mode. Achieving functions equivalent to these areas typically required kernel mode programming. However, the likelihood of increased fatal vulnerability in terms of security when executing programs in kernel mode and the possibility of entire system instability due to a program bug suggests that all processing should be carried out in User Mode wherever possible.

To enable these processes in user mode, SoftEther Corporation developed a proprietary TCP/IP stack for exclusive use with the SecureNAT function and succeeded in implementing it in user mode. SecureNAT's virtual NAT function receives TCP/IP and UDP/IP packets from the virtual network as a router and administers those packets to each session, interpreting them properly in the layers up to the transport layer. For TCP/IP protocol, the TCP/IP stream is reconfigured based on the sequence number within that connection. These reconfigured payload data are forwarded to the target host as fast as possible using the socket API of the operating system running the VPN Server VPN Bridge, in addition to being internally stored in the FIFO buffer. Data received from the destination host also travels this route but in the opposite direction, returning to the Virtual HUB's virtual network. The TCP/IP stack running in user mode is also used at this time, and the data is automatically put into datagram format by recovery and flow control algorithms conforming to TCP/IP protocol standards. SecureNAT's virtual NAT function is realized by way of this extremely complicated processing, although general users do not have to be aware of these operating principles.

Fig. 3-7-6 Stack diagram of network modules in SecureNAT's virtual NAT function

3.7.4 Points to Note when using Virtual NAT Function

 While virtual NAT is a very convenient function, the following precautions should be taken when using it.

• Using Virtual NAT
   The use of virtual NAT is recommended for environments running the VPN Server / VPN Bridge without System Administrator authority or OS support for local bridging, i.e. when a computer in the Virtual HUB's layer 2 segment is unable to use the local bridge function and needs to access a physical network host via the physical network interface of the computer actually running the Virtual HUB (particularly where the uses given in 「10.11 Using SecureNAT to Set Up a Remote Access VPN With No Administrator Rights」 are applicable).
  Where local bridging can be used to connect a Virtual HUB and a physical network and in the absence of security issues, it is not necessary to connect a virtual network to a physical network using the virtual NAT function.
• Preventing Connections causing Infinite Looping of Packets
  Where a computer with VPN Client installed connects to a virtual NAT-enabled Virtual HUB either from the Virtual Network Adapter of its own Virtual HUB or by local bridging to said hub from a physical Network Adapter, and where the default gateways for those Network Adapters designate IP addresses assigned by the Virtual HUB’s SecureNAT virtual host network interface, communication attempting to connect to an arbitrary IP address tries to use the Virtual HUB's Virtual NAT, which in turn tries to communicate with the destination IP address by calling the operating system's network communication API, resulting in the connection packet falling into an infinite loop. The virtual NAT function is not typically used at the same time as local bridge connections and VPN connections to localhost using the VPN Client. If these types of connections are being made then there is a likelihood that the network design is incorrect.
• Precautions relating to Performance
  By possessing an internal virtual TCP/IP stack, SecureNAT performs the highly advanced process of reassembling the TCP/IP stream packetized once by the TCP/IP stack and further TCP/IP packetizing via the operating system. The overhead resulting from these processes is large, such that throughput via the virtual NAT is considerably decreased when compared to physical maximum throughput, even when using a computer with sufficiently high speed. That is why virtual NAT should not be used for performance-centric applications. As previously stated, virtual NAT is a function which can be used as an alternative when the local bridge function cannot be used for security or technical reasons. Where high-speed methods such as local bridging are available, those methods should be used.
• Handling ICMP Packets
  When virtual NAT is enabled, sending ICMP packets via IP addresses assigned by a virtual host network interface as routers, and further sending said packets to a separate host results in the virtual NAT returning dummy ICMP echo response packets to all ICMP echo request packets. This is a specification of the PacketiX VPN whereby this operation becomes inevitable because most operating systems do not allow the transmission of arbitrary ICMP packets in network APIs which can be called up with user authority. When using Virtual NAT it is therefore impossible to confirm the existence of a host on the other side of a Virtual NAT router using ICMP packets.
• DNS Redirect
  When Virtual NAT is enabled, UDP 53 port destination packets (DNS packets) to the IP address of the virtual host network interface are automatically forwarded to the DNS server being used as the DNS Server by the computer running the Virtual HUB. This is the same operation carried out by typical broadband routers.
• Unsupported Functions
  The User Mode TCP/IP stack used internally by Virtual NAT is not equipped with some sophisticated TCP/IP functions such as the Window Scale option, Selective ACKs and Nagle algorithms. In addition, the nature of Virtual NAT means that IP routing and NAT between virtual networks is not supported. The virtual layer 3 switch function should be used for inter-virtual network IP routing.

3.7.5 Virtual DHCP Server

The Virtual DHCP Server Function

The Virtual DHCP Server function can be used in SecureNAT. Depending on the method of use, there is also no problem in using the DHCP Server without using SecureNAT. The DHCP Server enables a computer connected to a Virtual HUB layer segment to receive an IP address distributed from the DHCP Server and temporarily use that IP address.

The Virtual DHCP Server allocates IP addresses in much the same way as a physical computer DHCP server program. However, it does not offer detailed functions to set numerous options like those included in the Windows Server versions.

The Virtual DHCP Server enables simple DHCP address allocation rather than being a fully fledged DHCP server. The function is most suitable when setting up a Virtual HUB and seeking to automate IP address assignment to that Virtual HUB's computer using the DHCP protocol, but being prevented from doing so due to the effort required to run the DHCP server software on the same segment as the Virtual HUB.

While the DHCP Server function is simplistic, it is able to set IP address expiration dates, administer lease tables and allocate several essential options without problems.

Fig. 3-7-7 Virtual DHCP Server function

Virtual DHCP Server Function Settings

Set the [Use Virtual DHCP Server Functions] checkbox to enabled status in the VPN Server Manager to use the SecureNAT's Virtual DHCP Server function. Contrarily, select disabled status when not using the function. When starting SecureNAT, the Virtual DHCP Server function is enabled by default.

A list of the entries and default values which can be set is as follows.

To set each option, use the VPN Server Manager to make the relevant entries in the [Virtual DHCP Server Setting] box inside [SecureNAT Setting]. In the vpncmd utility, use the [DhcpSet] command.

Fig. 3-7-8 Virtual DHCP Server function administration window

Obtaining IP Address Lease Table

A list of the IP addresses assigned by the Virtual DHCP Server (IP Address Lease Table) can be displayed at any time. To display the IP Address Lease Table, click on the [Virtual DHCP Server Status] button in the VPN Server Manager. In the vpncmd utility, use the [DhcpTable] command.

Fig. 3-7-9 Virtual DHCP Server IP Address Lease Table display window

3.7.6 Points to Note when using the Virtual DHCP Server

While Virtual DHCP Server is a convenient function, the following precautions should be taken when using it.

• Using the Virtual DHCP Server
  The Virtual DHCP Server provides simple DHCP server functions, and does not require System Administrator Authority to operate. The use of authentic UNIX or Windows DHCP server software is recommended where the Virtual DHCP Server functions are insufficient.
• Effective Range of DHCP Scope
  The scope (range) within which IP addresses allocated by the Virtual DHCP Server can be received is limited by the layer 2 segment of the Virtual HUB on which the SecureNAT is operating. Accordingly, where there is no connection to a physical LAN by local bridging in particular, it is possible to limit the range affected by that DHCP server to within the Virtual HUB and to enable only the computer VPN-connected to the Virtual HUB to receive the IP address from the Virtual DHCP Server. The LAN connected to the computer actually running the Virtual HUB is not affected (this does not apply in the case of local bridging). Needless to say, the entire layer segment is subject to IP address assignment from the DHCP server in the case of cascading between Virtual HUBs or bridging with a separate site.
• Note on Initial Settings
  The Virtual DHCP Server function's default settings assign the address space 192.168.30.0/24 to the client computer, and attempt to set the default gateway and DNS server address under the assumption that the Virtual NAT function is to be used concurrently. Not using the Virtual NAT function renders the default gateway and DNS server address default settings meaningless, so be sure to modify them.
• Allocating IP Addresses only without Allocating Default Gateway & DNS Server Addresses
  When wishing to use the Virtual DHCP Server to simply allocate an IP address to the client computer without allocating client default gateway and DNS server settings, leave the [Default gateway address] and [DNS server address] boxes in the client-assigned options blank. In this case, the client computer to which the IP address is assigned does not modify the router or DNS server it uses.
  Please note that there have been reports of a problem for client computers using Windows, wherein the options relating to the default gateway and DNS server received upon the previous assignment from the DHCP server are cached, and when these values are left blank on the subsequent connection, these previous ones are applied. While this appears to be a Windows OS specification, we recommend trying to connect to a separate DHCP server once in an attempt to overcome it.

3.7.7 SecureNAT Sessions

When the SecureNAT function is operating on the Virtual HUB, a special virtual session called a SecureNAT session is registered on the Virtual HUB session list. The SecureNAT-operated virtual host VNI is virtually (software-wise) internally connected to this session.

The Virtual HUB Administrator can obtain information on this session in the same way as a normal session.

3.7.8 Logging SecureNAT Status

The entire status of SecureNAT's Virtual NAT and Virtual DHCP Server functions are saved in the Virtual HUB's security log. Below is an example of a saved log.

PacketiX VPN 2.0 Online Manual 2.20.5320
Copyright © 2004-2007 SoftEther Corporation. All Rights Reserved.
 Contact Plat'Home for inquiries. | Support | Notes