Adding a mobile network interface

You add a mobile network interface (MNI) to a mobile access service to define the IP interface through which the service exchanges information with SafeLinx Clients.

Before you begin

You must add a mobile access service to the SafeLinx Server before you can add an MNI.

About this task

To support VPN connections from SafeLinx Clients, you must add at least one MNI to the mobile access service on the SafeLinx Server. When you add an MNI, you specify how IP addresses are assigned to the SafeLinx Clients that use the MNI, and how traffic from these clients is to be routed.

MNIs are required on deployments that support VPN connections through mobile access services only. Clients that connect through HTTP access services or Messaging services do not use MNI resources. To add a mobile network interface, complete the following procedure:


  1. From the Resources page of the SafeLinx Administrator, right-click the mobile access services to which you want to add a mobile network interface (MNI), and then click Add > Mobile Network Interface.
    The Add a New Mobile Network Interface wizard opens to guide you through the process of adding an MNI.
  2. In the field, Determine how IP addresses are assigned and how IP traffic is routed, click one of the following options:
    Use an externally located DHCP serve SafeLinx 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 a private subnet and create a NAT resource based on DHCP requested addresses 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 large organizations, clients are typically assigned private network addresses, which are unique within a subnet only. To enable SafeLinx Clients to route packets to destinations beyond the MNI subnet, you can enable network address translation (NAT). Under NAT, the original private network IP address on a source packet is replaced with a routable IP address that is 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 option is the default setting for SafeLinx Servers that are installed on Linux and Windows.

  3. To use a private subnet, type the IPV4 address that defines that start of the subnet range and specify the subnet mask.
  4. In the DNS negotiation and WINS negotiation fields, specify how the SafeLinx Server sends domain name system (DNS) or Windows Internet Name Service (WINS) configuration information to SafeLinx Clients that connect to this MNI. In each field, select one of the following options:
    • Disable
      The SafeLinx Server does not send DNS or WINS configuration information to Mobility Clients.
    • Retrieve using DHCP
      SafeLinx Clients that connect to this MNI receive name resolution services from a DNS or WINS server that is retrieved dynamically at the start of the session.
    • Static
      SafeLinx Clients that connect to this MNI receive name resolution services from the primary or secondary servers that you specify.

      If you select this option, specify the IP addresses of the primary and secondary servers.

      For DNS servers, in the Domain field, also specify the DNS domain suffix to append to the host name of connecting Mobility Clients.

    DNS configuration is used to resolve computer names into IP addresses. WINS protocol in combination with name query broadcasts is used to resolve computer names into IP addresses.
  5. In the Network filters fields, select filters to apply to this MNI.
    Filters specify whether the SafeLinx Client can use certain protocols and ports to send traffic. In this way, the SafeLinx Client can prevent bandwidth delays and possibly avoid unwarranted network charges. You can choose one of the default filters or create your own filters.
  6. To require SafeLinx Clients to use specific network or host routes to reach internal network resources, select Send routes to the SafeLinx Clients, and then specify pairs of IP addresses and subnet masks.
    At the start of the session, the SafeLinx Server sends routing tables that contain the entries that you specify to the SafeLinx Client. The routes that you define force SafeLinx Clients to use the VPN connections when they send data to the internal network.