Delays accessing target devices from dropped connections to port 8550
When trying to access target device using SSH or RDP access method there are significant delays.
This article is to better understand why the delays can occur and how to avoid them.
When trying to SSH (using Mindterm) to access a Linux machine, some machines show delay displaying the SSH Handshake and some show delay after the SSH handshake, some show delay at both points.
Release:
Component: CAPAMX
When trying to access target devices, regardless of whether you have Socket Filter Agent installed or not PAM will probe TCP port 8550 to see if Socket Filter Agent is running.
This check can cause delay if the firewall is blocking the port.
The tests below are based on a target server that does not have SFA running on the target device and firewall in place.
You can do some testing as demonstrated below to find which setting works best for your environment.
Before we go further, following is the basics of firewall(iptables)
There are ACCEPT and DROP "Policies"
There are ACCEPT, REJECT and DROP "Connection Responses"
* ACCEPT means the traffic flow is allowed.
* REJECT means the traffic is blocked but with a response to tell the client that firewall has blocked the traffic.
* DROP means the traffic is blocked with no response.
There are INPUT, FORWARD and OUTPUT Policy Chain where the INPUT represents incoming traffic.
[Handshake Message] mentioned below represents the time taken until you get to see the following screen.
[Complete login] represents the time taken until you are logged in and get a command prompt as shown below.
And the test environment details below.
[PAM1] 172.17.11.53 pam322t1.test.lab
[PAM2] 172.17.11.54 pam322t2.test.lab (not involved in this use case but appears in the firewall rules)
[RHEL65b] 172.17.10.2 (target device, Redhat Enterprise Linux 6.5, the firewall rules are set here)
You must always have TCP Port 22 open for all testing.
And depending on the test use case, TCP 8550 may be OPEN or FILTERED (meaning blocked, it is same for REJECT and DROP response)
Script filenames below are in the following format.
"[Policy]-[Response].sh"
accept-accept.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT ACCEPT
[Behaviour]
Handshake Message: No Delay
Complete Login: No Delay
accept-drop.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT ACCEPT
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 8550 -j DROP
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 8550 -j DROP
[Behaviour]
Handshake Message: 12 seconds Delay
Complete Login: No Delay
accept-reject.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT ACCEPT
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 8550 -j REJECT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 8550 -j REJECT
[Behaviour]
Handshake Message: No Delay
Complete Login: No Delay
drop-accept.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT DROP
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 8550 -j ACCEPT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 8550 -j ACCEPT
[Behaviour]
Handshake Message: No delay(around 1 second)
Complete Login: 20 seconds delay
drop-drop.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT DROP
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 22 -j ACCEPT
[Behaviour]
Handshake Message: 12 Seconds Delay
Complete Login: 20 Seconds Delay
drop-reject.sh
==========================
#!/bin/bash
iptables -F
iptables --policy INPUT DROP
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.17.11.53 -p tcp --dport 8550 -j REJECT
iptables -A INPUT -s 172.17.11.54 -p tcp --dport 8550 -j REJECT
[Behaviour]
Handshake Message: No Delay (around 1 second)
Complete Login: 22 Seconds Delay
The same concept applies to RDP Access Method.
Best performance would obviously be the "accept-accept" policy but this is less likely to be set in customer's production environment.
Next best performance was "accept-reject" use case.