Supported platforms

Vyatta documentation

Learn how to install, configure, and operate the Vyatta Network Operating System (Vyatta NOS) and Orchestrator, which help drive our virtual networking and physical platforms portfolio.

Show Page Sections

ALG configurations

This section describes the ALG configuration concepts and their behaviors.

Several Vyatta NOS ALGs share common configuration concepts.

In Vyatta NOS, all ALGs are enabled by default and automatically start detecting their respective packet flows if NAT is configured. You can control which ALGs are enabled or disabled by using the configuration system. You can dynamically enable or disable ALGs during run time.

For PPTP and ICMP, ICMP6 protocol detection takes place on the IP protocol of the packets. For all other ALGs, the detection takes place on the basis of UDP and TCP or the TCP destination port that matches configured control ports. When a packet is received with a destination port that matches a control port, the packet is forwarded to the correct ALG for processing.

ALG control ports

Information about ALG control ports and their configuration.

For port-based ALGs, the default configuration includes application ports as specified by the Internet Assigned Numbers Authority (IANA). The following table lists the default ports for port-based ALGs.

Table 1. ALG control ports
ALGIP ProtocolControl Port

Additional control ports can be added or removed by using the configuration system with the commands that are listed in the ALG commands section.

You can configure up to 32 additional control ports per port-based ALG. Each added control port must be unique throughout all configured ports for all port-based ALGs. For example, you cannot add port 4242 to both SIP and FTP protocols.

If you add additional control ports to a port-based ALG, the default port for that ALG will be replaced with the list of configured ports. If you wish to have both configured port and default control port, include the default port in your configuration.

When you remove all ports from the ALG configuration, the default port is enabled automatically.

Enabling and disabling ALG protocols

The commands that relate to enabling and disabling ALG protocols and additional information.

All Vyatta NOS ALG protocols are enabled by default. You can disable an ALG by setting the disable parameter in the configuration. For example, to disable the FTP ALG, use the following commands:
# set system alg ftp disabled
# commit
You can re-enable an ALG by deleting the disable parameter from the configuration. If the FTP ALG is in a disabled state, the following commands will re-enable the ALG:
# delete system alg ftp disable
# commit

When an ALG is disabled, the new packet flows are not forwarded to the ALG for processing. This means that the packet payloads are not translated and session connections are not established.

Note: The existing sessions continue to reference the ALG until the packet flow terminates.

Recommended additional RSH configuration

Additional RSH configuration recommendations from Ciena and the related commands.

The RSH server imposes strict requirements on client connections, which is why Ciena recommends that administrators create distinct SNAT rules to match expected RSH usage from the private side of the NAT gateway. The RSH protocol requires that client connections for the control and stderr connections use ports in a range from 512 through 1023. This range means that in an SNAT scenario, you can concurrently establish as many as 256 RSH connections for each translation address (each RSH connection consists of two connections to the same address: a control-port connection and a stderr-port connection).

Because of this limitation, Ciena recommends that administrators create an RSH-specific SNAT rule that contains an address and a port range to handle the expected number of concurrent connections. This rule must have a higher rule index than any other matching SNAT rule for the private side of the NAT gateway. This SNAT source rule must include the following configurations:

  • A matching TCP destination port of 514
  • A translation address range
  • A transport port range of 513 through 1023 for TCP

The size of the address range depends on the number of concurrent connections.

Note: There are no special requirements for DNAT rules.

The following example shows how to configure an SNAT rule that can be used for RSH traffic. This rule matches TCP packets that are destined for port 514 and modifies them to use the translation address and a port range of 512 through 1023.

Create an SNAT rule
vyatta@R1# set service nat source rule 22 description rsh
Configure the rule to match TCP packets destined for port 514.
vyatta@R1# set service nat source rule 22 destination port 514
Specify the outbound interface for the rule.
vyatta@R1# set service nat source rule 22 outbound-interface dp0s5
Configure the rule to handle TCP packets.
vyatta@R1# set service nat source rule 22 protocol tcp
Configure the rule to modify the packets to use the translation address and 512-through-1023 port range.
vyatta@R1# set service nat source rule 22 translation address
vyatta@R1# set service nat source rule 22 translation port 513-1023
Commit and view the configuration.
vyatta@R1# commit
vyatta@R1# show service nat source
source {
       rule 22 {
               description rsh
               destination {
                       port 514
               outbound-interface dp0s5
               protocol tcp
               translation {
                       port 513-1023