3.4 Virtual HUB Functions

PacketiX VPN Server 2.0 makes it possible to create a plurality of Virtual HUBs, and to separate administration objects and VPN session layer 2 communication between each Virtual HUB. This manual explains Virtual HUBs in two parts: general operations & administration methods, and security functions. First is an explanation of the general operations and methods for administration of Virtual HUBs.

3.4.1 Creating Virtual HUBs

Multiple Virtual HUBs can be created in the PacketiX VPN Server, but they can only be created or deleted by entire VPN Server Administrators. When the VPN Server creates a Virtual HUB, it is possible to delegate the authority for its administration to another party by providing them with the Virtual HUB administration password.

To create a new Virtual HUB, click on the [Create Virtual HUB] tab in the VPN Server Manager and enter the relevant details. Alphanumeric characters and some symbols can be used in the Virtual HUB name. It is also possible to designate a Virtual HUB administration password when creating the Virtual HUB (this can also be designated at a later date). Not designating an administration password makes it impossible to carry out remote administration connection to the Virtual HUB in Virtual HUB Administration Mode.

In the vpncmd utility, use the [HubCreate] command. When using the clustering function (refer to 「3.9 Clustering」), use either the [HubCreateDynamic] or [HubCreateStatic] commands instead.

Fig. 3-4-1 Create New Virtual HUB window

After creating the Virtual HUB, select it and display the Administration window to carry out administration. Double clicking on the Virtual HUB name in the VPN Server Manager opens a new window for the administration of that hub. In the vpncmd utility, the Virtual HUB can be selected using the [Hub] command. The following explanations of the Virtual HUB all assume that the Virtual HUB's Administration window is open or that the Virtual HUB being administered has been selected using the [Hub].

Fig. 3-4-2 Virtual HUB list display

3.4.2 Online & Offline Status

The Virtual HUB has both online and offline status. While the Virtual HUB is normally online, it can also be set to offline status when wishing to temporarily halt its functions.

To change the Virtual HUB status, open [Virtual HUB property] in the VPN Server Manager and select either [Online] or [Offline] from the [Virtual HUB status] window. In the vpncmd utility, use [Online] or [Offline] command.

3.4.3 Maximum Simultaneous Connections

It is possible to set the maximum number of sessions which can be simultaneously connected to the Virtual HUB. When this value is set, all VPN sessions exceeding the number designated in the Virtual HUB will not be able to connect (all subsequent sessions attempting to connect will be denied).

The number of maximum simultaneous connections does not include local bridge sessions, cascade sessions (virtual sessions created by the cascading side), SecureNAT sessions or virtual layer 3 sessions. That is to say, the maximum number of cascade connections from the VPN Server / VPN Bridge / VPN Client and regular VPN connections connected to the Virtual HUB are limited.

To set the number of maximum simultaneous connections, open the [Virtual HUB properties] window in the VPN Server Manager and check the box in [Limit Max VPN Sessions], then enter the desired value in the [Max Number of Sessions] box. In the vpncmd utility, use the [SetMaxSession] command.

Fig. 3-4.3 Settings window for maximum simultaneous Virtual HUB connection sessions

Where the max_sessions, max_sessions_client and max_sessions_bridge options have been set in the Virtual HUB Administration Options, these option values are always applied regardless of whether or not the number of maximum simultaneous connection sessions has been set. See 「3.5.12 Virtual HUB Administration Options」 for details.

3.4.4 Connection Mode

As explained in 「1.6.8 Client Mode Session」 and 「1.6.9 Bridge/Router Mode Session」, the two types of sessions connected to the Virtual HUB from the VPN source computer are the client mode session and the bridge / router mode session.

When using the PacketiX VPN Server product version (Standard Edition / Enterprise Edition), then the total number of client mode sessions and bridge mode sessions is related to the number of required licenses.

3.4.5 Session Management

It is possible to display a list of the VPN sessions currently connected to the Virtual HUB, to display detailed information on each of them, and to forcibly disconnect them.

Displaying Session Lists

A list showing the VPN sessions connected to the Virtual HUB and internally generated sessions can be displayed. Simply clicking on the [Manage Sessions] button in the VPN Server Manager displays a list of the sessions. A session list can also be obtained using the vpncmd utility with the [SessionList] command.

When connecting to a cluster controller using clustering, the sessions displayed in the [Session list] include all of the cluster member server sessions.

Fig. 3-4-4 Session administration window

The following information is shown when displaying a session list.

Distinguishing Session Types with Icons

The session types in the session list display can be differentiated by looking at [User] or by obtaining session information. When using the VPN Server Manager, it is possible to distinguish between session types using the small icons displayed together with the session name.

The following seven icon types are displayed in the session list.

Icon	Corresponding Session Type
	Indicates a general VPN session (i.e. a session created by receiving a routine VPN connection, and not a bridge / router mode or monitoring mode session).
	Indicates a bridge/ router mode session.
	Indicates a monitoring mode session.
	Indicates a local bridge session.
	Indicates a cascade connection session.
	Indicates a SecureNAT session.
	Indicates a virtual layer 3 switch session.

Obtaining Session Details Data

 Double clicking on [Session name] from the session list of the VPN Server Manager displays information relating to that session. The same information can be obtained in the vpncmd utility using the [SessionGet] command.

This enables the identification of detailed information for each session as well as information relating to the source computer (such as its VPN software version and OS).

Fig. 3-4-5 Session details data display window

Of the detailed session data, the following is important.

Forced Disconnect of Session

It is possible for Virtual HUB Administrators to forcibly disconnect a connected session. To disconnect a session, simply select the session to be disconnected in the VPN Server Manager and click the [Disconnect] button. In the vpncmd utility, use the [SessionDisconnect] command.

3.4.6 MAC Address Tables

As explained in 「1.6.5 Association with MAC Address」, the Virtual HUB supports the exchange of virtual Ethernet frames between sessions by automatically learning the MAC address table and associating the addresses with their corresponding connected session. The Virtual HUB Administrators can display the contents of the latest Virtual HUB MAC address table.

Displaying Virtual HUB MAC Address Tables

Clicking on the [MAC address Table List] button in the [Manage Sessions] window of the VPN Server Manager displays the MAC address tables. In the vpncmd utility, the table can be obtained using the [MacTable] command.

When requesting MAC address tables from the cluster controller in a cluster environment, the cluster controller responds with MAC address tables on all of the cluster member servers together.

Fig. 3-4-6 MAC address table administration window

The entries listed for each record (MAC address entry) in the MAC address table are as follows.

Deleting Virtual HUB MAC address tables

Although not normally required, the Virtual HUB Administrator can arbitrarily delete MAC address table entries. To delete a MAC address table entry, select the entry with the VPN Server Manager and click the [Delete selected entry] button. In the vpncmd utility, the entry can be deleted using the [MacDelete] command.

Listing the MAC Address Table associated with a Specific Session

In the VPN Server Manager's [Manage Sessions] window, select the desired session and click [MAC table of This Session] button. This displays a list of only those MAC address table entries associated with the selected session. It is also possible to designate a session and find out which MAC addresses are being used by the VPN client computer for that session. The same task can be carried out using the vpncmd utility by attaching the session name as an argument to the [MacTable] command.

Fig. 3-4-7 Session-specific MAC address table

3.4.7 IP Address Table

The Virtual HUBs automatically create and administer MAC address tables, but when the virtual Ethernet frames transmitted in the VPN are IP packets, they also automatically learn and session-associate not only the MAC addresses but also the IP addresses at the same time by reading the IP packet header. The internal table for this purpose is a database called the IP address table.

While the IP address table is not used for virtual Ethernet frame switching between sessions, it is possible to apply rigorous security policies to each user by supporting real-time data on which session sent packets based on which IP address thus far.

The Virtual HUB Administrators can display the contents of the latest Virtual HUB MAC address table. This makes it possible to find out at any time which VPN session computer is communicating using which IP address.

Displaying Virtual HUB IP Address Tables

Clicking on [IP Address Table List] button in [Manage Sessions] window of the VPN Server Manager displays the IP Address Table. In the vpncmd utility, the table can be obtained using the [IpTable] command.

When requesting IP address tables from the cluster controller in a cluster environment, the cluster controller responds with IP address tables on all of the cluster member servers together.

Fig. 3-4-8 IP address table administration window

The entries listed for each record (IP address entry) in the IP address table are as follows.

Deleting Virtual HUB IP Address Tables

Although not normally required, Virtual HUB Administrators can arbitrarily delete IP address table entries. To delete an IP address table entry, select the entry with the VPN Server Manager and click the [Delete selected entry] button. In the vpncmd utility, use the [IpDelete] command.

Listing the IP Address Table associated with a Specific Session

In the VPN Server Manager's [Manage Sessions] window, select the desired session and click [IP Table of This Session] button. This displays a list of only those IP address table entries associated with the selected session. This makes it easy to find out which IP addresses are being used by the VPN client computer for a designated session. The same task can be carried out using the vpncmd utility by attaching the session name as an argument to the [IpTable] command.

For VPN sessions where a router is connected at the session destination, all of the IP addresses of packets arriving from the other side of the router (such as the Internet) may be associated. This is because there is no way to distinguish whether each IP address in a Virtual HUB operating in layer 2 has been routed via a router or whether they have been transmitted from a node directly connected by layer 2.

Fig. 3-4-9 Session-specific IP address table

3.4.8 Confirming the Existence of IP Addresses with Poll Packets

As explained in 「3.4.7 IP Address Table」, the Virtual HUBs have IP address table databases to constantly administer which sessions are communicating using which IP addresses. Additionally, in order to check whether an IP address registered on the IP address table database actually exists on the layer 2 local segment to which the Virtual HUB belongs, poll packets to confirm the existence of the IP address (survey packets) are sent out at regular intervals using the ARP protocol, and those IP address table entries which respond have their expiration date updated, while those entries which do not respond are deleted from the IP address table database after a certain period (60 seconds), thereby maximizing the accuracy of IP address existence confirmation.

At this time, the Virtual HUB sends a unicast of the ARP request packet for the known IP address to the corresponding session based on the IP address table entry. The sending IP address for this ARP request packet is "172.31.0.0/16" and the destination IP address is the IP address subject to the survey.

This operation normally allows ongoing verification of IP address lists on the layer 2 segment, but some operating systems (including FreeBSD) receiving an ARP packet with the sending IP address of "172.31.0.0/16" simply do not respond or leave a warning message in their syslog etc. stating that they received an unauthorized ARP packet with a sending IP address of "172.31.0.0/16".

While there is typically no problem with ignoring such warning messages, it is possible to stop the poll packet confirming the existence of IP addresses when many computers running BSD exist on the same segment and complaints start to arrive from the Administrators. To stop the poll packet from confirming the existence of IP addresses in a Virtual HUB, rewrite the VPN Server's Configuration file as follows.

Because [false] is set as the default for [NoArpPolling] within the [Virtual HUB] [Virtual HUB name] [Options] nodes in the Configuration file, rewrite this to [true].

	declare Option
	{
		uint MaxSession 0
		bool NoArpPolling true
		bool NoEnum false
	}

Changing this setting as above stops the Virtual HUB from regularly unicasting poll packets using the ARP protocol.

Setting NoArpPolling to true means that there is no guarantee that the contents of the IP address database administered by the Virtual HUB are up-to-date. As such, it is possible that the following items from the user and group security policy items will not be applied correctly, and as such, the following security policy items should not be used when using the Virtual HUBs with NoArpPolling set to true.

Please refer to 「3.5.9 Security Policies」 for details on security policy items.

• [Enforce DHCP Allocated IP address] policy
• [Deny MAC Address Duplication] policy
• [Deny IP address Duplication] policy
• [Maximum Number of IP addresses] policy

3.4.9 Communicating in Bridge / Router Mode Session

As explained in 「1.6.7 VPN Session Connection Modes」, bridging and routing is denied for VPN Client-connected sessions in client mode sessions. Accordingly, it is possible to protect against actions such as unauthorized bridge connections and routing between the virtual Network Adapter and the physical network adapter connected to a VPN session on the computer on which the VPN Client is installed.

When the VPN Client enables the [Bridge / Router Mode] in the [Advanced Settings] connection settings tab or in the case of a cascade connection from the VPN Server / VPN Bridge, the session is connected using the Bridge / Router Mode. For sessions connected by the Bridge / Router Mode, basically all communication is permitted regardless of the size of layer 2 network to which it is bridged at that session destination (connection source side), when routed to the Internet and even when cascade connected to another Virtual HUB.

Please refer to 「4.4.17 Selecting the Connection Mode」 for specific methods to connect the VPN Client to a Virtual HUB in Bridge / Router Mode.

3.4.10 Communicating in Monitoring Mode Session

As described in 「1.6.9 Bridge/Router Mode Session」, when a monitoring mode session is connected to a Virtual HUB, all virtual Ethernet frames flowing within the Virtual HUB are automatically copied and distributed to the monitoring mode session. As such, it is possible to intercept all virtual Ethernet frames flowing within a Virtual HUB when connected to the Virtual HUB via a monitoring mode session. This comes in handy for Network Administrators when troubleshooting and setting up an IDS.

Although a monitoring mode session can receive all communication within a Virtual HUB, it can not transmit communication to the Virtual HUB.

Please refer to 「4.4.17 Selecting the Connection Mode」 for specific methods to connect the VPN Client to a Virtual HUB in monitoring mode.

3.4.11 Cascade Connection Functions

Cascade Connections

The mechanisms of and methods for creating cascade connections are very important in creating a site-to-site VPN using PacketiX VPN.

Using the cascade connection function enables the cascade connection of a Virtual HUB within the VPN Server to other Virtual HUBs operating on the same or separate computers.

When two Virtual HUBs are running on separate computers or even when they are running on the same computer, those hubs are originally not connected in any way so they are two completely isolated segments from the perspective of a layer 2 network. However, in many cases there may be a desire to run two Virtual HUBs as a single segment over a public IP network such as the Internet. For instance, a cascade connection is essential to build a site-to-site VPN (see 「1.4.8 Base-to-Base VPN of Ordinary Scale」). Using a cascade connection enables the connection of two or more Virtual HUBs as if connecting them with a very long network cable.

Cascading a remotely located Virtual HUB A with Virtual HUB B enables free layer 2 (Ethernet level) communication between a Virtual Network Adapter connected to A and a network computer locally bridged to A and a network adapter connected to B and a network computer locally bridged to B. In other words, the computers connected to each other's Virtual HUBs can communicate freely on a layer 2 level irrespective of the actual network topology, wherein that connection may be a virtual one by the VPN Client, or a physical network adapter's destination may be locally bridged to a Virtual HUB and that Virtual HUB is cascade connected to yet another hub so as to arrive at the destination computer.

Fig. 3-4-10 Cascade connection between Virtual HUBs

Cascading obviously requires the existence of two Virtual HUBs, i.e. a Virtual HUB to initiate the cascade connection and a Virtual HUB to receive it. From the perspective of the Virtual HUB receiving the cascade connection, the incoming connection is processed as a common VPN session (bridge / router mode session), in which case user authentication is required just as though a VPN Client were carrying out a VPN connection to a Virtual HUB.

Fig. 3-4-11 Initiating & receiving cascade connection

Creating a Cascade Connection

To create a cascade connection for a Virtual HUB to another Virtual HUB, click on the [Manage Cascade Connections] button in the VPN Server Manager. This displays [Cascade Connection on "Virtual HUB name"] window. Next click on [Create] and enter the relevant details for the VPN Server host name, Virtual HUB and user authentication. It is also possible to make the VPN connection via a HTTP or SOCKS proxy server in addition to using a direct TCP/IP connection when cascading.

The items to be entered when creating a new cascade connection are practically the same as those required for a creating a new VPN Client connection setting. Please therefore refer to 「4.4 VPN Server Connection Method」 for the meanings of each item.

All user authentication methods are available for cascade connections except smartcard authentication.

Fig. 3-4-12 Cascade connection create & edit window

Online & Offline Status of Cascade Connection

Upon creating a new cascade connection on a Virtual HUB, that cascade connection is offline. It is not possible to communicate on a cascade connection which is offline. To start communication using a cascade connection, select the desired cascade connection in the [Cascade Connection on "Virtual HUB name"] window of the VPN Server Manager and click the [Online] button.

Upon setting the cascade connection to online status, the Virtual HUB attempts to maintain the cascade connection as far as possible in line with the cascade connection settings. The cascade is successful once the connection to the destination VPN Server Virtual HUB is confirmed, and [Online (connected)] appears in the [Status] display. When an error occurs, the error code will appear in this [Status] display. When the cause of the error is attributed to an input error in the cascade connection settings, first take the cascade connection offline, correct the connection settings by clicking on the [Edit] button, and click the [Online] button once again.

As explained in 「2.1.3 Communication Efficiency and Stability」 on reconnect settings where the VPN connection fails or is disconnected during communication, an attempt to reconnect is made every 10 seconds when the VPN session connection fails or is disconnected while cascading. In this way, the Virtual HUB attempts to maintain a constant connection with the cascade destination Virtual HUB as far as the latter's network allows.

Any change in the cascade connection status is recorded on the VPN Server's server log and Virtual HUB security log. Regularly checking these logs provides knowledge on cascade connection success and failure records and enables an understanding of the line status. Please refer to 「3.10 Logging Service」 for details on how to view the VPN Server's server log and Virtual HUB security log.

Fig. 3-4-13 Cascade connection management window

Cascade Connection Security Policies

Security policies can be set as desired for cascade connection users so that the virtual Ethernet frames which travel over the cascade connection are subject to scrutiny on the hub receiving the cascade.

To apply security policies in relation to the virtual Ethernet frames which travel over the cascade connection on the hub initiating the cascade, click on the [Security policy] button in the cascade connection's connection settings window and set as desired.

Fig. 3-4-14 security policy settings applicable to Cascade sessions window

Creatable Number of Cascade Connections

A maximum of 128 cascade connections can be created in a Virtual HUB, although in reality, it is not necessary to connect a large amount of cascade connections from a single Virtual HUB.

Cascade Connection Status

The cascade connection status of the hub initiating the cascade can be obtained at any time. Selecting the desired cascade connection in the [Cascade Connection on "Virtual HUB name"] window of the VPN Server Manager and clicking the [Status] button displays the communication status for that cascade connection session in real time. The communication status displayed here is virtually the same as the connections settings' communication status shown in the VPN Client Manager. For details, please refer to 「4.5.2 Checking the Connection Status」.

The hub receiving the cascade connection recognizes it as being a Bridge / Router Mode session, which means that it is shown in the Virtual HUB session list. Note that the cascade is not automatically displayed in the [Cascade connection] list of the receiving hub. For details, please refer to 「3.4.5 Session Management」.

Points to Note when Performing a Cascade Connection

Cascading is a very convenient and useful function without which the value of the PacketiX VPN 2.0 software would be halved. However, the following points should be observed in order to use the cascade connection properly.

• Before creating the cascade connection, careful consideration should be given to the design of the VPN network topology and notes should be taken to ensure the connection is used in a suitable manner. For instance, where three Virtual HUBs are each attached to their own site and those sites are in turn locally bridged to a physical LAN, cascading each of the Virtual HUBs results in a looped layer 2 network topology which can cause communication paralysis and give rise to broadcast storms. As such, any actions which result in the creation of a layer 2 loop should definitely be avoided when using the cascade connection.
• The PacketiX VPN Server's cascade connection function does not support the Spanning Tree Protocol.
• It is necessary to create a cascade connection setting for the Virtual HUB performing the cascade connection and to put it online. It is necessary to predefine the users to receive the cascade connection on the receiving Virtual HUB.
• The hub initiating the cascade treats the cascade connection the same as it treats a VPN connection by the VPN Client, so the settings for creating a cascade connection are similar to those for creating a new connection on the VPN Client.

Creating, Deleting, Modifying & Controlling a Cascade Connection with the vpncmd Utility

To control the cascade connection with the vpncmd utility, use commands beginning with "Cascade". These commands enable the same tasks performed by VPN Server Manager's GUI settings to be carried out with the vpncmd utility. Please refer to 「6.4 VPN Server / VPN Bridge Management Command Reference (For Virtual HUB)」 for details on how to control a cascade connection using the vpncmd utility.

3.4.12 Server Authentication in Cascade Connections

Server authentication processing by the inspection of server certificates as explained in 「2.3 Server Authentication」 is also supported for cascade connections in a manner similar to that of a VPN Client connection, whereby it is possible to check whether the cascade destination VPN Server has the proper certification when connecting.

To register the destination VPN Server's certificate, click the [Specify individual Cert] button in the cascade connection settings' edit window and select an arbitrary X.509 certificate. When using signed certificate authentication, register a trusted root certificate (or intermediate certificate) in the cascade-initiating Virtual HUB's [Trusted certification authority certificates].

3.4.13 Local Bridge

The setting of the local bridge function as explained in 「1.4.5 Bridge Connection of Virtual Network and Physical Network」 can only be performed by the entire PacketiX VPN Server Administrator. It is therefore not possible to bridge a Virtual HUB and a physical network adapter of the computer running the VPN Server with Virtual HUB Administrator authority alone. For details on how to create and delete local bridges, please refer to 「3.6 Local Bridges」.

3.4.14 Administrator Connection

Multiple users and groups can be added to a Virtual HUB (please refer to 「3.4.3 Maximum Simultaneous Connections」 for specific administration methods). Remotely connecting to a Virtual HUB over a VPN typically requires the designation of a user name registered in advance by the Virtual HUB Administrator.

The exception to this is when a Virtual HUB Administrator designates  Administrator as the user and that Virtual HUB's Administrator password as the password to enable the VPN connection. This VPN connection is always possible even when no users exist on the Virtual HUB. Virtual HUB Administrators can therefore make a VPN connection to the Virtual HUB for which they are responsible at any time (cascade connections from the VPN Server / VPN Bridge are possible in addition to connection from the VPN Client).

The Administrator user is special and this user name cannot be manually added to a Virtual HUB.

The following security policies are applied to VPN connection to a Virtual HUB by the Administrator.

• [No Limit on Number of broadcasts] is enabled
• [Allow Monitoring Mode] is enabled

All other security policies therein are regarded as default security policies (please see 「3.5.9 Security Policies」).

Accordingly, Administrators can always make a VPN connection to the Virtual HUB with the minimum amount of limitations. VPN connections are also possible with [Monitoring Mode] enabled.

3.4.15 Obtaining Information on the Virtual HUBs

Virtual HUB Administrators can acquire the latest information on the Virtual HUBs by accessing [View status] in the Virtual HUB administration window. Clicking on the [Refresh] button provides an understanding of the Virtual HUB's status as it changes in real time.

In the vpncmd utility, Virtual HUB information can be obtained using the [StatusGet] command.

Fig. 3-4-15 Virtual HUB information display window

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