Connection and transport profiles

A connection profile is a set of configuration properties that is assigned to an MNC. The connection profile controls the security and performance options between the MNC and SafeLinx Clients that connect to it.

When you create an MNC or edit its properties, you assign it a connection profile.

In the Default Resources OU, there are several example connection profiles:
  • CDPD (cellular digital packet data)
  • High-speed used for 802.11b and faster networks
  • IP - used with transport profiles

A transport profile is a set of transport-layer configuration properties that are assigned only to IP-based network connection profiles. These properties are settings that identify the type of network, such as the adapter name and the speed of the connection. Multiple network names can be associated with one transport profile and more than one transport profile can be assigned to an IP connection profile.

When the SafeLinx Server gets a login request from a SafeLinx Client on an IP-based network, it attempts to match the client's network name or network speed to a transport profile. When the SafeLinx Server finds a match, it applies the configuration properties that are associated with that profile. The SafeLinx Client proposes the values for the network name and network speed when it logs in or when it roams from one network to another.

When determining which transport profile to use, the SafeLinx Server first attempts to match the network name and speed that the SafeLinx Client is using. If no match is found for the exact network name and speed, then the exact name of the network is used. If no match is found, then the exact speed of the network is used. If no match is found, then a fuzzy search on the name is used and finally, if there was no match, the closest network speed is used.

If you are using an IP connection profile without any transport profiles that are assigned or if the SafeLinx Client configuration file has RequestTransportProfile set to 0, then a default transport profile is assigned. Make sure to set the default transport profile to a valid value for SafeLinx Clients that connect and that are not capable of negotiating configuration settings at connection setup time. For example, SafeLinx Client before version 5.1 is not capable of this. If no default transport profile is set, one is automatically assigned and is the first one alphabetically available from the list of transport profiles.

A connection profile specifies:
  • A descriptive name of the profile.
  • The speed of the network.
  • Whether the SafeLinx Client uses compression. Choose from:
    Mandatory
    Compression is required.
    Optional
    No compression type is required for this MNC and the SafeLinx Client is free to negotiate compression.
    ZLIB
    The data compression libraries that are based on the Lempel-Ziv-Welch algorithm as provided by ZLIB.
  • Whether IP header reduction is performed.

  • The key exchange algorithm that is used to validate SafeLinx Clients. The key exchange algorithm is assigned to an MNC and cannot be negotiated individually by SafeLinx Clients. All SafeLinx Clients that are connected through an MNC must use the same key exchange agreement.

    Some devices have serial numbers that are associated with their hardware, which can be used for identification. Users who connect using the SafeLinx Client that is configured for Password key exchange can have an extra level of security by taking advantage of device identifiers. Not all client platforms and devices support device identification. When it is available, the SafeLinx Client Help > About is updated to display the Device Identifier. If a user is configured to use device identification, the unique identifier is combined with the password during authentication. For more configuration information, see Using device identification with SafeLinx Clients.

    Choose from:

    None

    The SafeLinx Server accepts a connection that is initiated by any SafeLinx Client using any device. When you define a connection profile with no validation, the SafeLinx Administrator supplies a default user name, which is used for account logging. The user ID for No validation is the user ID seen in the account wg.acct file for all SafeLinx Clients that connect through an MNC using this profile. This option is one in which you do not need to define user IDs or mobile devices to the SafeLinx Administrator.

    There are two MNCs that support only No validation: simple network paging protocol (SNPP) and simple mail transport protocol (SMTP).

    Note: The SafeLinx Client must be configured on the Security tab of the SafeLinx Client Connections properties for None key exchange.
    Note: When you use a key exchange of None and the Client validation model is set to User validation, then the validation model setting is ignored.
    Two-party key distribution

    The SafeLinx Server is authenticated to the SafeLinx Client and the SafeLinx Client is authenticated to the SafeLinx Server.

    You can specify an extra type of authentication by selecting a Secondary authentication profile. If so, make sure that you define and choose an authentication profile other than the default System authentication profile.

    More authentication profiles may be added or chained to the Secondary authentication profile for extra layers of security. Select other Authentication profiles by selecting their respective check boxes in the Additional authentication profiles field.

    Note: The SafeLinx Client must be configured on the Security tab of the SafeLinx Client Connections properties for Password key exchange.
    Single-party key distribution

    The SafeLinx Client is authenticated to the SafeLinx Server.

    You can specify an additional type of authentication by selecting a Secondary authentication profile. If so, make sure that you define and choose an authentication profile other than the default System authentication profile.

    Additional authentication profiles may be added or chained to the Secondary authentication profile for additional layers of security. Select other Authentication profiles by selecting their respective check boxes in the Additional authentication profiles field.

    Note: The SafeLinx Client must be configured on the Security tab of the SafeLinx Client Connections properties for Password Key Exchange.
    Diffie-Hellman

    Both the SafeLinx Server and the SafeLinx Client are given the means to compute the same shared key. You do not need to define user IDs or mobile devices to the SafeLinx Administrator, however in this case, the client validation model must be set to None. Using Diffie-Hellman key exchange does not provide authentication. If you want to provide authentication, you must specify a Secondary authentication profile. If you use a key exchange of Diffie-Hellman and you want to use a secondary authentication method, set the client validation model to User, and make sure that the users are defined to the SafeLinx Administrator.

    Additional authentication profiles may be added or chained to the Secondary authentication profile for additional layers of security. Select other Authentication profiles by selecting their respective check boxes in the Additional authentication profiles field.

    Note: The SafeLinx Client must be configured on the Security tab of the SafeLinx Client Connections properties for Public Key Key Exchange.
  • A minimum level of encryption. Choose from: advanced encryption standard (AES), digital encryption standard (DES), RC5, or triple-DES.
  • Whether the SafeLinx Server periodically rotates the encryption key.

  • A client validation model that determines the validation level that is required when a SafeLinx Client initiates a connection with the SafeLinx Server. At connection time, the SafeLinx Server associates a user name with that client connection. This name is used for logging and can be identified in several ways: it can be entered at the SafeLinx Client as a user ID, derived from the identifier of the mobile device in use, or it can be a default value.

    Choose from:
    None
    No validation takes place.
    User validation
    When a SafeLinx Client initiates a connection, the SafeLinx Server requires a user ID and an optional password. The user ID must be defined to the SafeLinx Administrator. With a valid user ID, a person can initiate a session using any mobile device. If you select this option when the Key exchange algorithm is set to None, it is ignored.
    User and device validation
    When a SafeLinx Client initiates a connection, the SafeLinx Server first validates the mobile device identifier, then requires a valid user ID and an optional password. The SafeLinx Server checks whether this mobile device is associated with the supplied user ID. More than one mobile device can be associated with a user ID, and a device can be associated with more than one user ID. Use this model if you have devices that are assigned to more than one user, or if you have some devices that are assigned to one user and some shared.
    Device to user validation
    When a SafeLinx Client initiates a connection, the SafeLinx Server verifies the mobile device identifier, then derives the user ID that is assigned to that mobile device. Typically used for SafeLinx Clients that are configured not to display user IDs, this model requires that each mobile device is assigned to just one user ID. A user, however, can be assigned more than one mobile device. This model requires that you define mobile devices and user IDs to the SafeLinx Administrator.
  • A secondary authentication profile, which is required if you want clients to be authenticated when using Diffie-Hellman key exchange and optional for other key exchange algorithms.
  • Whether PPP clients, such as the Microsoft™ RAS Dialer or other generic PPP dialer programs, can connect to the SafeLinx Server.
  • On IP-based networks, the transport profiles that are associated with this connection profile. Note that you can assign multiple transport profiles to a single IP-based connection profile.
  • On networks other than IP-based, the maximum transmission unit settings, including:
    • The maximum size in bytes of the UDP packets that are sent over the network to the SafeLinx Client's MNC.
    • The maximum size in bytes of the UDP packets that are sent over the network from the SafeLinx Client's MNC.
    • The MTU value in bytes for the SafeLinx Client's mobile network interface (MNI). This MTU limits the size of raw IP packets that are sent from the client's IP stack to the SafeLinx Client code. It is also used by the TCP stack on the client to determine the maximum segment size (MSS). The MSS is announced during the establishment of a TCP connection to indicate to the partner the largest amount of data to send in one packet. The MSS is 40 bytes less than the MTU to account for the TCP/IP headers. Therefore, the MNI's MTU size affects the size of raw IP packets sent by the client's IP stack to the client and, for TCP connections, affects the size of packets that are sent by the remote host as well.
  • On networks other than IP-based, TCP optimization settings, including:
    • Whether TCP optimization is attempted and monitored and, if so, the transmit window size and the amount of time that retransmitted packets are blocked from delivery.
    • The amount of time that expires before an incomplete packet is discarded.
    • The maximum number of times that a single packet can attempt to be retransmitted before the packet is discarded and the session is reset.
  • On networks other than IP-based:
    • The amount of time that expires before an incomplete packet is discarded.
    • Whether fragments are evenly sized before they are transmitted over the network.
    • The amount of transmission delay that is created so that the SafeLinx Server can join multiple packets together to make more efficient use of the transport layer.
    • The maximum number of bytes of data that can be transmitted as a single chunk.
    • The minimum number of bytes of available space that should exist in the buffer before more data is added to it. The buffer contains the data that is transmitted as a single chunk.
    • Filters to apply. Selecting these filters prevents the SafeLinx Client from sending traffic using the protocol on the port number listed. In this way, the SafeLinx Client can prevent bandwidth delays and possibly avoid unwarranted network charges. Select from the filters that are provided in Default resources, or create your own.
A transport profile specifies:
  • A descriptive name of the profile.
  • Keywords or phrases that can be used to determine the match for a network name.
  • The speed of the network.

  • How the maximum transmission unit (MTU) setting is determined. MTU values determine the maximum size in bytes of a packet that can be sent over an interface. Multiple MTU configuration settings come into play when considering a TCP connection running over the VPN connection.

    Choose from:
    Negotiate
    The SafeLinx Server and the SafeLinx Client both use the MTU value as specified by the SafeLinx Client.
    Download to client
    The SafeLinx Server ignores what is sent by the SafeLinx Client and uses the values as specified. The values are also sent for the SafeLinx Client to use.
  • The maximum transmission unit settings, including:
    • The maximum size in bytes of the UDP packets that are sent over the network to the SafeLinx Client's MNC.
    • The maximum size in bytes of the UDP packets that are sent over the network from the SafeLinx Client's MNC.
    • The MTU value in bytes for the SafeLinx Client's mobile network interface (MNI). This MTU limits the size of raw IP packets that are sent from the client's IP stack to the SafeLinx Client code. It is also used by the TCP stack on the client to determine the maximum segment size (MSS). The MSS is announced during the establishment of a TCP connection to indicate to the partner the largest amount of data to send in one packet. The MSS is 40 bytes less than the MTU to account for the TCP/IP headers. Therefore, the MNI's MTU size affects the size of raw IP packets sent by the client's IP stack to the client and, for TCP connections, affects the size of packets that are sent by the remote host as well.
  • The interval in seconds between when the SafeLinx Client sends echo requests to the SafeLinx Server.
  • Whether data is compressed over the connection between the SafeLinx Client and the SafeLinx Server.
  • Whether the SafeLinx Client and the SafeLinx Server reduce the packet size by reducing the size of IP headers.
  • Whether fragments are evenly sized before they are transmitted over the network.
  • The amount of transmission delay that is created so that the SafeLinx Server can join multiple packets together to make more efficient use of the transport layer.
  • The maximum number of bytes of data that can be transmitted as a single chunk.
  • The minimum number of bytes of available space that should exist in the buffer before more data is added to it. The buffer contains the data that is transmitted as a single chunk.
  • Whether the SafeLinx Client transmits data to the SafeLinx Server by putting multiple packets together to decrease overhead and make more efficient use of the transport layer and vice versa.
  • Whether TCP optimization is attempted and monitored and, if so, the transmit window size and the amount of time that retransmitted packets are blocked from delivery.
  • The amount of time that expires before an incomplete packet is discarded.
  • The maximum number of times that a single packet can attempt to be retransmitted before the packet is discarded and the session is reset.
  • Filters to apply. Selecting these filters prevents the SafeLinx Client from sending traffic using the protocol on the port number listed. In this way, the SafeLinx Client can prevent bandwidth delays and possibly avoid unwarranted network charges. Select from the filters that are provided in Default resources or create your own.

There are several default profiles that come with the SafeLinx Administrator in the Default Resources OU. You can alter the default profiles or create other profiles, one for each set of properties that you want to assign to an MNC. If you delete a default resource, there is no way to restore it without reinstalling the SafeLinx Server.

To add a connection profile, from the Resources pane, right-click the OU in which you want to add the profile, and then click Add Resource > Connection profile > Profile type.

To view or modify one of the default profiles, click Default Resources to expand the folder, then double-click Connection profile or Transport profile. From the list of profiles, select the one you want to view or modify, then click Properties.