Connection Limiting on Management Interface

Connection Limit connlimit restricts the number of concurrent connections from an IP address. The Connection Limit is supported only on ipv4 and ipv6 extended ACL. Connection Limiting is supported only on management interface for in band interface configuration and will work without impacting the interface's function.

To configure ACL rule with connection limiting and then apply it to the management interface.

device# conf term
Entering configuration mode terminal
device(config)# ip access-list extended check
device(conf-ipacl-ext)# permit tcp host 10.24.12.107 host 10.24.12.129 connlimit 3
device(conf-ipacl-ext)# end
device# conf term
Entering configuration mode terminal
device(config)# interface management 0
device(config-Management-0)# ip access-group check in
device(config-Management-0)# end
device#

When configured as above, only three incoming TCP connections are allowed from IP Address 10.24.12.107. Any more incoming request will be denied. In this example, 10.24.12.129 is the SLX management IP.

This example shows how to configure an ACL rule to restrict the number of SSH connections from a particular IP address 10.24.12.107 to 3 connections.

device# conf term
Entering configuration mode terminal
device(config)# ip access-list extended check
device(conf-ipacl-ext)# permit tcp host 10.24.12.107 host 10.24.12.129 eq 22 connlimit 3
device(conf-ipacl-ext)# end
device# conf term
Entering configuration mode terminal
device(config)# interface management 0
device(config-Management-0)# ip access-group check in
device(config-Management-0)# end
device#

This will allow only 3 concurrent SSH sessions from 10.24.12.107 IP address. Any additional SSH sessions from 10.24.12.107 server will be blocked. In the above example, 22 is the SSH port.

When connlimit is applied to a permit or a deny rule, it functions in a similar manner. When applied to a permit rule, it prevents additional connections to be made from the same IP. However, when applied to a deny rule, additional connections will be denied from the same IP address. In the above example, the permit rule of connlimit is 3, therefore, up to 3 connections from a specified IP address on the specified port can be made. The deny rule on connlimit is 3 and hence the 3rd connection will be denied from a specified IP address on the specified port.

HTTP and HTTPS connections are restricted to a maximum 25 connections per IP address. This is done using the QOS module which is inbuilt in the SLX HTTPS server. When the higher connection limit is configured for a specific IP Address, the SLX HTTPS server will restrict the maximum number of concurrent connections to 25 per IP address. Additionally, the SLX HTTPS server restricts concurrent incoming connections from the same IP to 30 connections.

Existing sessions are counted when the connection limit is applied to ACL.

Connection Limit is an addition to the existing ACL behavior, where the existing sessions are opened and the ACL rule with connlimit is applied after it. This restriction is enforced on the session which exchanges the traffic on the specified IP and port, hence if any one session is denied due to connection limiting, that session will be unresponsive. When the ACL is removed, the session will resume or timed out. When the session resumes, its duration will depend on the protocol used to negotiate the session and the specific message that was being exchanged between the client and the server when the connection limiting ACL restriction was applied on that session.

The legacy deny rule itself requires permit ip any any to deny the ACL to be configured for a particular IP Address. If the above ACL is not configured, all packets will be denied by default. The connlimit is an additional option to the deny rule and requires that the permit ip any any rule be configured.

Response to outbound sessions are considered as incoming connections and will be accounted when calculating the number of connections.

Existing sessions will be disrupted based on how the connlimit rule is applied.

When you apply an ACL with the same parameter and different connection limit value is applied and an ACL with the same configuration exists, the existing session will be disrupted.

Scenario 1: The following ACL configures a connection limit of 2.

seq 10 permit ip host 1.1.1.2 host 2.2.2.1 connlimit 2

This will allow 2 connections, only when the following ACL is also applied.

seq 20 permit tcp host 1.1.1.2 host 2.2.2.1 connlimit 1host 1.1.1.2 host 2.2.2.1 connlimit 1

When the second rule is applied, the 3rd session is open and the connection information is updated to 3, in the kernel table. Hence, this results in all the 3 opened sessions being unresponsive, as all the open session packets cannot hit any rule due to the Connection Limit. The default DROP rule will result in packet loss and hanging of the session.

Scenario 2: The following ACL configures a connection limit of 2.

seq 10 permit ip host 1.1.1.2 host 2.2.2.1
            connlimit 2

This will allow 2 connections, only when the following ACL is also applied.

seq 20 permit tcp host 1.1.1.2 host 2.2.2.1 connlimit 3

When the second rule is applied, the 3rd session is open and the connection information is updated to 3, in the kernel table. The existing sessions will become unresponsive, and all the 3 session packets hit the ACL with sequence 20.

When multiple sessions exist, and an ACL with a 'connection limit' with a value less than the number of existing sessions, then all the existing sessions will become unresponsive.

When a new rule is added to an existing ACL on the management interface, it takes a few seconds to restart the session after applying the rule. Meanwhile, if you try to telnet to the device immediately after applying the new rule, the device does not consider existing session and existing session will become unresponsive.

Therefore, it is recommended to wait till device receives packet from existing sessions, after applying a new rule, before starting your session.