Mobile network interfaces (MNIs)

A mobile network interface (MNI) is a component that you assign to a Mobile access service to define the dedicated virtual IP subnet through which SafeLinx Clients communicate with the Connection Manager. All of the IP traffic between the SafeLinx Server and these VPN clients flows through the MNI.

An IP subnet is a continuous range of IP addresses or groups of IP addresses. In a production environment, when you add a mobile network interface (MNI) to a mobile access service, you assign to it an IP address and a subnet mask. The subnet address serves as the SafeLinx Server's point-of-presence on your organization's internal network.

The MNI configuration determines the number and range of IP addresses to assign, how to assign them, and how traffic is routed to the internal network through the MNI. The number of available addresses determines how many of SafeLinx Clients and mobile devices can connect to the Connection Manager at one time.

Every SafeLinx Client or mobile device that uses a particular MNI is assigned an IP address from the defined range. All of the traffic between SafeLinx Clients and the Mobile access service travels through the IP interface that is provided by the MNI.

The SafeLinx Server supports a maximum of 256 MNIs on AIX®. A maximum of 32 MNIs is supported on Linux™ or Windows™. If more than 250 MNIs are defined, the SafeLinx Administrator displays only the first 250 MNIs in a random order as returned from the search query. The maximum number of MNIs is calculated by subtracting the currently active network interfaces from 256.

On Windows systems, all MNIs must use the same maximum transmission unit (MTU) value. This MTU value is set when the first MNI is first made available.

You must define at least one MNI for each Mobile access service to enable SafeLinx Clients to connect to SafeLinx Server and the internal network. If the number of client addresses that are needed can be supplied by the subnet that is defined for a single MNI, you might define one MNI only. However, if you need more client addresses, or must logically separate users within one SafeLinx Server, you can define more than one MNI.

Clients that connect through HTTP access services or Messaging services do not use MNI resources.

The methods that you can use to specify how an MNI assigns addresses differ among operating systems. For a SafeLinx Server that is installed on Linux or Windows, an MNI can use any of three methods to assign IP addresses to SafeLinx Clients. A SafeLinx Server that is installed on AIX is not configurable, and always uses the same method. The following list describes the different methods that an MNI uses to assign IP addresses to its clients.
Use an externally located DHCP server
Mobility Client addresses for the MNI are obtained from a dynamic host configuration protocol (DHCP) server. The server assigns addresses that are unique within the LAN and can be routed outside the subnetwork to any computer on the LAN.

This option requires that a specific network interface adapter is bound to the MNI. It is targeted for use in smaller installations because it requires ARP table and route table entries for each assigned address, which can diminish performance.

Use an external DHCP server with NAT
All SafeLinx Clients that use the MNI are assigned IP addresses from a range that is defined by a specified IP address and subnet mask. In a large organization, clients might be assigned private network addresses, which are unique within the MNI subnet only. To enable SafeLinx Clients to route packets to destinations beyond the MNI subnet, the SafeLinx Server uses network address translation (NAT). Under NAT, the original private network IP addresses on a source packet are replaced with routable IP addresses, which are unique across the organization, or even across the Internet. When the SafeLinx Server receives a packet from a SafeLinx Client on the subnet, it randomly assigns the original source address to a port number. The SafeLinx Server then changes the source address to a routable NAT address that it obtains from a DHCP server, and forwards the packet to its destination. The NAT service maintains a translation table that tracks the mapping between the packet's original source address, the port number, and the routable address. The mapping is preserved until the TCP session ends, or until a timeout occurs.

This option requires that a specific network interface adapter is bound to the MNI. It is targeted for use in installations where large numbers of routable addresses are not available to be assigned to the MNI. This adapter reduces the number of requests that are made to the DHCP server to one. Performance is impacted when there is a large user base with a high login rate.

Use a private subnet
All SafeLinx Clients that use this MNI are assigned an address from the range of addresses that are defined by the IP address and subnet mask that you specify. Computers on the internal network communicate with devices on the MNI subnetwork through the SafeLinx Server's IP address. To ensure connectivity, routing tables on the internal network must associate the SafeLinx Server's IP address with the subnetwork.

This setting applies to all SafeLinx Servers that are installed on AIX. It is also the default option for SafeLinx Servers that are installed on Linux and Windows.

When you specify the IP address and subnet mask for an MNI, use an address from one of the special address ranges that are reserved for private networks. Devices on an organization's internal network are not accessed directly from the internet, and do not require globally unique IP addresses. Instead, you can assign them addresses from one of three ranges that are designated for private networks. Table 1 lists the three classes of IP address ranges that are reserved for use on private stub networks.

Table 1. IP address ranges reserved for private use
Class Network range Subnet mask
A through
B through
C through

If you do not have an external DHCP server available, you need to define a private IP address range. Either create a network address translation resource or define static routes on all destination computers. In this case, you need to install the SafeLinx Server, then use SafeLinx Administrator to create the MNI.

If you do not want to define static routes on all destination computers, create a network address translator (NAT) resource and assign it to the MNI. For more information about using a NAT resource, see Network address translator.

You can optionally:
  • Set up network address translation so that the SafeLinx Server acts as an agent between a public network and a private network. This process is done by using fewer unique IP addresses to represent an entire group of computers. For more information, see Network address translator.
  • Define a routing alias to an MNI to act as a multihomed destination gateway to route data between the mobile access services and a specified subnetwork. For more information, see Routing aliases.
  • Set up filters to prevent or allow communication between IP addresses within an MNI. For more information, see Filters.
  • Redirect data to or from addresses in an MNI by using packet mapping, which modifies an IP header packet to redirect data. For more information, see Packet mapping.

Occasionally, the subnet mask that is applied to the MNI is too restrictive and the Mobility Clients that attach through that MNI require a wider subnet range. You can apply an alternative subnet mask to that MNI. The alternative subnet mask extends the range of addresses SafeLinx Clients can reach, possibly eliminating the need for a default route on the SafeLinx Client.

To make sure that your organization can access SafeLinx Clients and mobile devices, update the routing tables of your organization to include SafeLinx Server's point-of-presence on the MNI subnet.