Connection and transport profiles

A connection profile is a set of configuration properties that is assigned to a mobile network connection (MNC) to control security and performance between an MNC and the SafeLinx Clients that connect to it. When you create an MNC or edit its properties, you assign it a connection profile.

Some transport-layer configuration properties, such as compression, header reduction or TCP optimization, are negotiated by using connection and transport profiles.

You add connection profiles to an OU from the SafeLinx Administrator. The SafeLinx Administrator provides a set of default connection profiles and transport profiles. 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.

Connection profiles

Table 1 lists some of the key properties that you can specify in a connection profile.

Table 1. Connection profile properties
Property	Description
Compression algorithm	Specifies the type of compression that the SafeLinx Client uses when it communicates with the SafeLinx Server. The following options are available: Mandatory Compression is required. Never No compression is used. When a transport profile is enabled for compression, it is not used as it was never negotiated. Optional No compression type is required for this MNC and the SafeLinx Client is free to negotiate compression. If it is negotiated, the transport profile setting determines whether it is used. This option is the default. ZLIB The data compression libraries based on the Lempel-Ziv-Welch algorithm as provided by ZLIB.
Protocol header reduction	Specifies whether header reduction is supported when clients connect through this MNC. You can enable or disable header reduction on individual transport profiles.
Transport profile	You can specify the transport profiles that are associated with this connection profile. You can assign multiple transport profiles to a single IP-based connection profile.
Default transport profile	A default transport profile specifies the transport profile to assign to SafeLinx Clients that are unable to negotiate configuration settings at connection setup time. One reason that a SafeLinx Client might not be able to negotiate connection settings is if the value of the RequestTransportProfile setting in its configuration file is set to `0`. If the Connection profile does not specify a default transport profile, the first entry in the list of transport profiles is automatically assigned.
Key exchange algorithm Note: Configure SafeLinx Clients that connect through MNCs that use this connection profile to use the key exchange option that you specify here. To specify the key exchange setting on a SafeLinx Client, open the properties for a connection to the Security page and then select a value in the Key exchange field.	Specifies the key exchange algorithm that is used to validate SafeLinx Clients that connect through MNCs that use this connection profile. 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 associated with their hardware which can be used for identification. Users whose SafeLinx Clients are configured for Password key exchange can take advantage of increased security if they use device identification. If a SafeLinx Client is configured for device identification, the unique device identifier is combined with the password during authentication. For more information about configuration device identification, see Using device identification with SafeLinx Clients. You can specify one of the following key exchange options: None The SafeLinx Server accepts a connection that is initiated by any SafeLinx Client that uses any device. When you define a connection profile with no validation, the SafeLinx Administrator supplies a default user name (generic) 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 that use this profile. This option is one in which you do not need to define user IDs or mobile devices to the SafeLinx Administrator. Only the following MNCs support the No validation option: simple network paging protocol (SNPP) and simple mail transport protocol (SMTP). 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 add another type of authentication by choosing a profile in the Authentication profile field. If you add another authentication profile, choose a profile other than the default System authentication profile. Single-party key distribution The SafeLinx Client is authenticated to the SafeLinx Server. You can add another type of authentication by choosing a profile in the Authentication profile field. If you add another authentication profile, choose a profile other than the default System authentication profile. 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. You can configure authentication by choosing a profile in the Authentication profile field. 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. Then, make sure that the users are defined to the SafeLinx Administrator.
Client validation model Note: If you set the value in this field to User validation, but the value in the Key exchange algorithm field is set to None, then the value in this field is ignored.	Specifies 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 currently in use, or it can be a default value. 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 by 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. The SafeLinx Server then derives the user ID that is assigned to that mobile device. Device to user validation is typically used for SafeLinx Clients that are configured not to display user IDs. Under this model, each mobile device can be assigned to a single user ID only. However, a user can be assigned to more than one mobile device. This model requires that you define mobile devices and user IDs to the SafeLinx Administrator.
Authentication profile	Specifies the authentication profile to apply to this connection profile. An authentication profile is required for Diffie-Hellman key exchange, but is optional for other key exchange algorithms.
Additional authentication profiles	For greater security, you can require that this connection uses multiple authentication profiles. Select one or more authentication profiles to apply to this connection after the profile specified in the preceding field is processed. If you select multiple authentication profiles in this field, they are processed in random order.
DHCP group	Specifies the pool of addresses to assign to accounts that connect anonymously and use either Diffie-Hellman key exchange or no key exchange. You cannot specify DHCP group assignments from a connection profile that uses Two Party Key Distribution Protocol (TPKDP). The reason for this is that the use of TPKDP implies that an HCL SafeLinx account exists within the configuration store. In this case, the DHCP group is set by account. Configuring to use Diffie-Hellman Key Exchange allows for secondary authentication and automatic account generation. The only way to associate a DHCP group when no local account exists is through the connection profile.
Minimum level of encryption	Specifies the minimum level of encryption that SafeLinx Clients must use when they connect through an MNC that uses this connection profile. SafeLinx supports the use of different levels of the advanced encryption standard (AES). For more information, see Encryption between the mobile access services and SafeLinx Clients.
Key rotation interval (minutes)	Specifies the time in minutes after which the SafeLinx Server renegotiates the encryption key. By default key rotation is disabled (value is set to 0).
Allow generic PPP negotiation	Specifies whether PPP clients, such as generic PPP dialers can to connect to the Connection Manager.

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 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 a SafeLinx Client logs in, or when it roams from one network to another, it transmits to the SafeLinx Server information about its network name and network speed. Upon receiving a login request, the SafeLinx Server attempts to match the network name and speed of the client to a transport profile. The SafeLinx Server then applies the configuration properties that are associated with the profile that it selects.

If no match is found for the exact network name and speed, then the exact name of the network only is used. If no match is found on the network name, then the exact speed of the network is used. If there is still no match, then a fuzzy search on the name is used. If there is no match on the fuzzy search, then transport profile that provides the closest match to the network speed is used.

A transport profile inherits its access control list (ACL) from the connection profile to which it is assigned.

Table 2 lists some of the key properties that you can specify in a transport profile.

Table 2. Transport profile properties
Property	Description
Associated network name keywords or phrases	Strings that the matching algorithm uses to pair network names with this transport profile.
Data throughput rate	The network speed in bits per second (bps)
Maximum Transmission Unit	Specifies 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 that runs over the VPN connection. The following options are available: 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.
Client IP stack MTU	If the option Download to client is set in the preceding field, this value specifies the MTU size in bytes for the mobile network interface (MNI) of the SafeLinx Client. 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, the MTU size affects the size of packets sent by the remote host.
Client MTU	The maximum size in bytes of the UDP packets that can be sent over the network from the MNC of the SafeLinx Client.
Default MTU	The maximum size in bytes of the UDP packets that can be sent over the network to the MNC of the SafeLinx Client.
Compress data	Select this field if you always want to compress the data that is sent between the Mobility Client and the SafeLinx Server.
Reduce IP headers	Select this field if you want the SafeLinx Client and the SafeLinx Server to reduce packet size by reducing the size of IP headers.
WLP-LCP keepalive timer	The interval in seconds between when the SafeLinx Client sends echo requests to the SafeLinx Server.
Balance size of PDU fragments	Select this field if you want protocol data unit (PDU) fragments to be evenly sized before the SafeLinx Server transmits them to SafeLinx Clients.
Outbound transmission delay	The amount of time in milliseconds that the SafeLinx Server delays the transmission of packets to the SafeLinx Client. Transmission delays enable the SafeLinx Server to join multiple packets and reduce the number of acknowledgments.
Enable client-side multi-packet buffering	Select this field if you want SafeLinx Clients to join multiple packets together when they transmit data to the SafeLinx Server. Joining packets decreases the total number of packets and makes more efficient use of the transport layer.
Enable server-side multi-packet buffering	Select this field if you want the SafeLinx Server to join multiple packets together when it transmits data to SafeLinx Clients. Joining packets decreases the total number of packets and makes more efficient use of the transport layer.
Maximum size of a multi-packet buffer	The maximum number of bytes of data that can be transmitted as a single chunk.
Minimum free space required to load packets	The minimum amount of space in bytes that the buffer must contain before more data is added to it. The buffer contains the data that is transmitted as a single chunk.
TCP protocol optimization	Select this field if you want SafeLinx Clients that connect through an MNC that uses this transport profile to attempt TCP optimization.
TCP retransmit suppression timer	If TCP optimization is enabled, this field specifies the amount of time that retransmitted packets are blocked from delivery.
Packet burst rate	The number of packets that are transmitted before the SafeLinx Server waits for acknowledgment. Transmission resumes after an acknowledgment is received.
Maximum number of retransmits	The number of times that a packet can be retransmitted before it is discarded and the session is reset.
TCP receive window size	The maximum amount of data, in bytes, that can be transmitted before an acknowledgment is received.
Network filters	Select filters to 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.
TCP-Lite service	Select an option in this field if you want to use a TCP-Lite service as the transport for SafeLinx Clients that connect through an MNC that uses this profile. TCP-Lite services provide more efficient communication in high-latency, low-bandwidth networks. If you do not select a TCP-Lite option, the standard transmission control protocol (TCP) is used.