Applies To:
Show VersionsBIG-IP LTM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Overview: Using the FTP ALG Profile to Transfer Files
The File Transfer Protocol (FTP) application layer gateway (ALG) profile enables you to transfer files between a client and server. The FTP ALG profile supports both active and passive modes, where data connections are initiated either from an FTP server (active mode) or from a client (passive mode). You can transfer files using the FTP protocol by configuring an LSN pool, configuring an FTP profile, and then assigning the LSN pool and FTP profile to a virtual server. The FTP protocol is described in RFC 959.
Task summary
About the FTP profile
The File Transfer Protocol (FTP) profile enables you to transfer files between a client and server, using FTP connections over TCP. The FTP application layer gateway (ALG) supports the FTP protocol's active and passive modes, where data connections are initiated either from an FTP server (active mode) or from a client (passive mode).
You can configure the FTP profile settings, as needed, to ensure compatibility between IPv4 and IPv6 clients and servers, to enable the FTP data channel to inherit the TCP profile used by the FTP control channel, and to use a port other than the default port (20). Additionally, when used with Application Security Manager™ (ASM™), this profile enables the BIG-IP® system to inspect FTP traffic for security vulnerabilities by using an FTP security profile.
FTP Control Channels
Once established, the FTP control channel remains open throughout the FTP session. The FTP control channel and the FTP data channel must both originate from the same IP address.
FTP Data Channels
In active mode, the FTP server initiates data connections. A client informs the server as to what port the client is listening on, and the server connects to the client by using that port.
An example FTP active mode configuration
In this example, an LSN pool is configured with a translation IP address and prefix length of 10.33.1.0/24. The virtual server is configured with an FTP control port using a wildcard address and a specific port: 0.0.0.0:21. The FTP data port is configured to use port 20. The configured translation mode uses the values of the respective port range.
Translation mode | Port range |
---|---|
NAPT | 2000-3000 |
DNAT | 2000-2200 |
PBA | 2000-2150 |
In passive mode, the FTP client initiates data connections. The FTP server informs the client as to what port the server is listening on, and the client connects to the server by using that port.
An example FTP passive mode configuration
In this example, an LSN pool is configured with a translation IP address and prefix length of 10.33.1.0/24. The virtual server is configured with an FTP control port using a wildcard address and a specific port: 0.0.0.0:21. The FTP data port is configured to use port 20. In this example, the configured translation mode uses the values of the respective port range.
Translation mode | Port range |
---|---|
NAPT | 2000-3000 |
DNAT | 2000-2200 |
PBA | 2000-2150 |
Creating an LSN pool
Creating an FTP profile
Configuring a CGNAT iRule
Creating a virtual server using an FTP ALG profile
Creating an FTP ALG logging profile
Configuring an FTP ALG profile
Overview: Enabling FTPS on the FTP ALG profile
When creating an FTP application layer gateway (ALG) profile, you can enable file transfer protocol secure (FTPS) to allow FTP clients to issue the authentication transport layer security (AUTH TLS) or AUTH secure socket layer (SSL) commands, and encrypt FTP traffic between the client and server for that connection. The BIG-IP® system switches the connection to pass through mode, but does not participate in the encryption process.
Task summary
About the FTP ALG profile with FTPS enabled
When configuring the FTP application layer gateway (ALG) profile, after enabling File Transfer Protocol Secure (FTPS), ALG switches to pass-through mode. This allows for an encrypted control connection to proceed. Once the connection is encrypted, it cannot be inspected for control commands, and firewall policies cannot be applied to the contents of the connection. For this reason, you must configure another virtual server, a wildcard CGNAT virtual server, to support the passive data transfer connections. FTPS only supports passive mode data transfers.
The wildcard and FTP virtual servers must share the same LSN pool, and address persistence must be configured on the pool. This configuration ensures that source address translation is consistent for the control and data connections that make up the file transfer.
Creating an LSN pool
Creating an FTP ALG profile
Creating a virtual server using an FTP ALG profile
Creating a wildcard virtual server
Creating an FTP ALG logging profile
Overview: Using the TFTP ALG profile to transfer files
The Trivial File Transfer Protocol (TFTP) profile enables you to configure the BIG-IP® system to read and write files from or to a remote server. The TFTP application layer gateway (ALG) profile is associated with a UDP port 69 virtual server so that a listener is established for incoming TFTP traffic. This allows the protocol to operate across the BIG-IP system. You can transfer files using the TFTP protocol by configuring a TFTP profile, configuring an LSN pool, and then assigning the TFTP profile and LSN pool to a virtual server. The TFTP protocol is described in RFC 1350.
Task summary
About the TFTP ALG profile
The Trivial File Transfer Protocol application layer gateway (TFTP ALG) provides connection management for TFTP. The TFTP profile is configured on a UDP port 69 virtual server. The profile opens a server-side listener so that responses from the server can be returned to the client across the BIG-IP® system. ALG logging can be configured on the profile.
Creating a TFTP ALG profile
Creating an LSN pool
Creating a virtual server using a TFTP ALG profile
Creating a TFTP ALG logging profile
Overview: Using the SIP MRF ALG Profile
A carrier-grade network address translation (CGNAT) Session Initiation Protocol (SIP) application layer gateway (ALG) configuration, using message routing framework (MRF) functionality, enables SIP communication and associated media flow to cross an address translation boundary.
The SIP ALG profile provides the ability for subscribers to make and accept calls, and to store private contact information with a corresponding translated address and port. The lifetime and idle timeout for this entry differs from the flow that created it, enabling the entry to live after the flow expires. The SIP ALG uses the translated IP address and port to uniquely identify a subscriber, and to accept that subscriber's incoming calls. To enable this functionality, the LSN pool must pick an endpoint that is not reserved for the SIP ALG connections, and update the endpoint reservation time.
For calls between subscribers, a BIG-IP® device can hairpin media; however, it must not hairpin SIP signaling. Instead, the BIG-IP device must always deliver SIP signaling to an external proxy.
Additionally, for communication between subscribers, a BIG-IP device supports NAT44, NAT64, 464XLAT, and DS-Lite translation.
Finally, the SIP ALG profile supports media flow between a caller and callee.
SIP MRF ALG call scenarios include the following:
- Internal to internal calls, with SIP signaling through the proxy
- External to internal calls
- Internal to external calls
- Internal to external calls through NAT64
- Calls through DS-Lite tunnels on the
internal network, including the following:
- DS-Lite subscribers on different tunnels with the same name and IP address
- DS-Lite subscribers on different tunnels with the same name and different IP addresses
- DS-Lite subscribers on different tunnels with different names and the same IP address
Task summary
About the SIP session profile
A SIP session profile, assigned to a message routing virtual server, processes ingress and egress messages in accordance with the profile configuration. Multiple SIP session profiles can be assigned to a virtual server, as necessary, to manage SIP messages. Each SIP session ALG profile includes settings for the message size, message header count, and message header size.
About the SIP router profile
A SIP router profile, assigned to one or more message routing virtual servers, specifies an operation mode, static routes, traffic group, and connection mirroring, as well as session, media proxy, registration, and logging parameters.
For virtual servers that use a SIP router profile in an application layer gateway (ALG) operation mode, the SIP router profile binds the virtual servers together; however, routes are not configured. Instead, the local address of the originating flow is used as the remote address of the outgoing connection.
Creating a SIP session profile
Creating a SIP router profile
Creating an LSN pool
The carrier-grade NAT (CGNAT) module must be enabled with the appropriate settings before you can create large-scale NAT (LSN) pools.
LSN pools are used by the CGNAT module to allow efficient configuration of translation prefixes and parameters. You can configure the following types of LSN pools:
- NAPT
- Deterministic
- PBA
SIP ALG LSN modes and networks
A carrier-grade NAT (CGNAT) Session Initiation Protocol (SIP) application layer gateway (ALG) configuration supports certain large-scale NAT (LSN) modes and network configurations.
NAT Mode | Supported Network Configurations |
---|---|
NAPT |
|
DNAT |
|
PBA |
|
Creating a NAPT LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP system.
Creating a deterministic LSN pool
Creating a PBA LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP® system.
Configuring a SIP virtual server
Viewing reserved endpoints
Overview: Using the RTSP ALG Profile to Stream Media
The Real Time Streaming Protocol (RTSP) application layer gateway (ALG) profile enables you to establish streaming multimedia sessions between a client and a server. You can stream multimedia sessions by configuring an LSN pool, configuring an RTSP profile, and then assigning the LSN pool and RTSP profile to a virtual server. The RTSP protocol is described in RFC 2326.
Task summary
About the RTSP ALG profile
The Real Time Streaming Protocol (RTSP) profile enables you to stream multimedia content between a client and server, using RTSP connections over TCP. The RTSP application layer group (ALG) supports the RTSP protocol's control channel to an RTSP server, through which the client requests a file for the server to stream (and controls the streaming of that file with commands like play or pause). The client can request streaming over UDP and provide two listening ports for the server response. The RTSP server responds with a Real-Time Transport Protocol (RTP) data channel port, to stream the requested file, and a Real-Time Control Protocol (RTCP) control channel port, which provides a stream description and status.
You can configure the RTSP profile settings, as needed.
An example RTSP ALG configuration
In this example, an LSN pool is configured with a translation IP address and prefix length of 10.33.1.0/24. The virtual server is configured with an RTSP control port using a wildcard address and a specific port: 0.0.0.0:554. The configured translation mode uses the values of the respective port range.
Translation mode | Port range |
---|---|
NAPT | 2000-3000 |
DNAT | 2000-2200 |
PBA | 2000-2150 |
Creating an LSN pool
Creating an RTSP profile
Configuring a CGNAT iRule
Creating a virtual server using an RTSP ALG profile
Creating an RTSP ALG logging profile
Configuring an RTSP ALG profile
Overview: Using the PPTP ALG profile to create a VPN tunnel
The point-to-point tunneling protocol (PPTP) profile enables you to configure the BIG-IP® system to support a secure virtual private network (VPN) tunnel that forwards PPTP control and data connections. You can create a secure VPN tunnel by configuring a PPTP Profile, and then assigning the PPTP profile to a virtual server. The PPTP protocol is described in RFC 2637.
Task summary
About the PPTP ALG profile
With the point-to-point tunneling protocol (PPTP) profile, you can configure the BIG-IP® system to support a secure virtual private network (VPN) tunnel. A PPTP application layer gateway (ALG) forwards PPTP client control and data connections through the BIG-IP system to PPTP servers, and provides source address translation that allows multiple clients to share a single translation address.
The PPTP profile defines a Transmission Control Protocol (TCP) control connection and a data channel through a PPTP Generic Routing Encapsulation (GRE) tunnel., This manages the PPTP tunnels through CGNAT for NAT44 and DS-Lite. It also manages all translation modes, including Network Address Port Translation (NAPT), Deterministic, and Port Block Allocation (PBA) modes.
PPTP control channels
The BIG-IP system proxies PPTP control channels as normal TCP connections. The PPTP profile translates outbound control messages, which contain Call Identification numbers (Call IDs) that match the port that is selected on the outbound side. Subsequently, for inbound control messages containing translated Call IDs, the BIG-IP system restores the original client Call ID. You can use a packet tracer to observe this translation on the subscriber side or on the Internet side. You can also use iRules® to evaluate and manage any headers in the PPTP control channel.
PPTP GRE data channels
The BIG-IP system manages the translation for PPTP GRE data channels in a manner similar to that of control channels. The BIG-IP system replaces the translated Call ID from the Key field of the GRE header with the inbound client's Call ID. You can use a packet tracer to observe this translation, as well.
An example PPTP ALG configuration
Log messages
With the PPTP profile, you can configure Log Settings, specifically the Publisher Name setting, which logs the name of the log publisher, and the Include Destination IP setting, which logs the host IP address of the PPTP server, for each call establishment, call failure, and call teardown.
PPTP profile log example
This topic includes examples of the elements that comprise a typical log entry.
Description of PPTP log messages
PPTP log messages include several elements of interest. The following examples describe typical log messages.
"Mar 1 18:46:11:PPTP CALL-REQUEST id;0 from;10.10.10.1 to;20.20.20.1 nat;30.30.30.1 ext-id;32456" "Mar 1 18:46:11:PPTP CALL-START id;0 from;10.10.10.1 to;20.20.20.1 nat;30.30.30.1 ext-id;32456" "Mar 1 18:46:11:PPTP CALL-END id;0 reason;0 from;10.10.10.1 to;20.20.20.1 nat;30.30.30.1 ext-id;32456"
Information Type | Example Value | Description |
---|---|---|
Timestamp | Mar 1 18:46:11 | The time and date that the system logged the event message. |
Transformation mode | PPTP | The logged transformation mode. |
Command | CALL-REQUEST, CALL-START, CALL-END | The type of command that is logged. |
Client Call ID | id;0 | The client Call ID received from a subscriber. |
Client IP address | from;10.10.10.1 | The IP address of the client that initiated the connection. |
Reason | reason;0 | A code number that correlates the reason for terminating the connection. The
following reason codes apply:
|
Server IP address | to;20.20.20.1 | The IP address of the server that established the connection.
Note: If
Include Destination IP is set to Disabled, then the Server IP address uses the value of
0.0.0.0.
|
NAT | nat;30.30.30.1 | The translated IP address. |
Translated client Call ID | ext-id;32456 | The translated client Call ID from the GRE header of the PPTP call. |
Creating an LSN pool
Creating a PPTP profile
Adding a static route to manage GRE traffic
Perform this task when you want to explicitly add a route for a destination client that is not on the directly-connected network. Depending on the settings you choose, the BIG-IP system can forward packets to a specified network device, or the system can drop packets altogether.
Creating a virtual server using a PPTP ALG profile
Overview: Configuring IPsec ALG with IKE
You can configure CGNAT IPsec application layer gateway (ALG) functionality with Internet Key Exchange (IKE) security for LSN source address translation. A typical IPsec ALG configuration includes a wildcard virtual server listening on Internet Security Association and Key Management Protocol (ISAKMP) port 500, using IPsec tunnel mode. When the BIG-IP system receives the first IKE packet, it picks a translation address, and, after successfully completing the IKE negotiation, creates the IKE and IPsec flows.
An example configuration of IPsec ALG with IKE for source address translation
Virtual Server Configuration | Setting |
---|---|
Service Port | 500 (ISAKMP) |
Protocol | UDP |
IPsecALG Profile | Default ipsecalg profile, or custom IPsecALG profile |
Source Address Translation | LSN |
LSN pool | One of the following LSN pool modes applies:
Note: The BIG-IP® system must map a different translation address to each subscriber when two or
more subscribers connect to the same server. However, if each subscriber connects to a
different server, then each subscriber can use the same translation address, because the
server IP address distinguishes the traffic.
Important: If the pool of
translation addresses is exhausted when a new subscriber attempts to initiate an IKE
exchange with a server, the BIG-IP system logs an error and drops the IKE traffic from the
second client.
|
Task summary
About negotiation of security associations
The way to dynamically negotiate security associations is to configure the Internet Key Exchange (IKE) protocol, which is included in the IPsec protocol suite. When you configure the IKE protocol, two IPsec tunnel endpoints (IKE peers) open a secure channel using an ISAKMP security association (ISAKMP-SA) to initially negotiate the exchange of peer-to-peer authentication data. This exchange is known as Phase 1 negotiation.
After Phase 1 is complete and the secure channel is established, Phase 2 negotiation begins, in which the IKE peers dynamically negotiate the authentication and encryption algorithms to use to secure the payload. Without IKE, the system cannot dynamically negotiate these security algorithms.
About the IPSecALG profile
The IPSecALG profile provides network address translation and flow management for Internet Protocol Security (IPSec) and Internet Key Exchange (IKE) flows.
This profile enables you to specify an idle timeout value, where a connection is idle for the specified period before becoming eligible for deletion. You can also limit the number of pending Internet Key Exchange (IKE) connections, a maximum number of unacknowledged connections that a client can have, before being denied further requests, to prevent a single client from flooding all of the connections while establishing the connections. Additionally, you can apply an initial connection timeout value, which determines the maximum number of seconds to wait for a response from the server for an IKE or IPsec request.
Finally, you can configure a log publisher and logging profile for IPsec ALG functionality, as necessary, through the IPsecALG profile.
About IPsec Tunnel mode
Tunnel mode causes the IPsec protocol to encrypt the entire packet (the payload plus the IP header). This encrypted packet is then included as the payload in another outer packet with a new header. Traffic sent in this mode is more secure than traffic sent in Transport mode, because the original IP header is encrypted along with the original payload.
Creating a log publisher
Creating an IPsecALG logging profile
Creating an LSN pool
The carrier-grade NAT (CGNAT) module must be enabled with the appropriate settings before you can create large-scale NAT (LSN) pools.
LSN pools are used by the CGNAT module to allow efficient configuration of translation prefixes and parameters. You can configure the following types of LSN pools:
- NAPT
- Deterministic
- PBA
Creating a NAPT LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP system.
Creating a deterministic LSN pool
Creating a PBA LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP® system.
Creating an IPsecALG profile
Creating an IPsec ALG virtual server for IKE
Overview: Configuring IPsec ALG with manual keys
An example configuration of IPsec ALG with manual keys with NAT
Virtual Server Configuration | Setting |
---|---|
Service Port | 0 (* All Ports) |
Protocol |
|
IPsecALG Profile | Default ipsecalg profile, or custom IPsecALG profile |
About IPsec Tunnel mode
Tunnel mode causes the IPsec protocol to encrypt the entire packet (the payload plus the IP header). This encrypted packet is then included as the payload in another outer packet with a new header. Traffic sent in this mode is more secure than traffic sent in Transport mode, because the original IP header is encrypted along with the original payload.
Creating a log publisher
Creating an IPsecALG logging profile
Creating an LSN pool
The carrier-grade NAT (CGNAT) module must be enabled with the appropriate settings before you can create large-scale NAT (LSN) pools.
LSN pools are used by the CGNAT module to allow efficient configuration of translation prefixes and parameters. You can configure the following types of LSN pools:
- NAPT
- Deterministic
- PBA
Creating a NAPT LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP system.
Creating a deterministic LSN pool
Creating a PBA LSN pool
- The CGNAT module must be provisioned before LSN pools can be configured.
- Before associating a LSN pool with a log publisher, ensure that at least one log publisher exists on the BIG-IP® system.