Ошибка connection closed by peer

I solved my problem — I needed to use a certificate with 10.0.2.2 as the common name (CN) so it matched Android localhost ip address of 10.0.2.2 instead of ‘localhost’ or ‘127.0.0.1’.

Edit: you could probably create a certificate with localhost as the CN and ‘127.0.0.1’ and ‘10.0.2.2’ as Subject Alternative Names (SAN).

Once I created 10.0.2.2 cert and private key pem files, I was able to hit my server running with the following command:

openssl s_server -accept 8888 -cert 10.0.2.2-cert.pem -key 10.0.2.2-key.pem  -state -www

If you want to force the client to provide a certificate (though it won’t be checked), add the flag -Verify 1 to the command above.

To test the server at the command line you can use the following (note openssl is able to connect via 127.0.0.1):

openssl s_client -connect 127.0.0.1:8888

And to add a client cert if the server requires it, add the flags -cert client-cert.pem -key client-key.pem

In my Android client I used the following code to connect (error checking removed):

// use local trust store (CA)
TrustManagerFactory tmf;
KeyStore trustedStore = null;
InputStream in = context.getResources().openRawResource(R.raw.mycatruststore); // BKS in res/raw
trustedStore = KeyStore.getInstance("BKS");
trustedStore.load(in, "insertBksPasswordHere".toCharArray());
tmf = TrustManagerFactory.getInstance("X509");
tmf.init(trustedStore);

// load client certificate
KeyStore clientKeyStore = loadClientKeyStore(getApplicationContext());
KeyManagerFactory kmf = KeyManagerFactory.getInstance("X509");
kmf.init(clientKeyStore, "insertPasswordHere".toCharArray());

SSLContext context = SSLContext.getInstance("TLS");

// provide client cert - if server requires client cert this will pass
context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
HostnameVerifier hostnameVerifier = org.apache.http.conn.ssl.SSLSocketFactory.STRICT_HOSTNAME_VERIFIER;

// connect to url
URL u = new URL("https://10.0.2.2:8888/");
HttpsURLConnection urlConnection = (HttpsURLConnection) u.openConnection();
urlConnection.setSSLSocketFactory(context.getSocketFactory());
urlConnection.setHostnameVerifier(hostnameVerifier);
urlConnection.connect();
System.out.println("Response Code: " + urlConnection.getResponseCode());

You should get a response code of 200, and can dissect the response from there.

Here’s the code to load the client credentials, which is identical to loading the server key store but with a different resource filename and password:

private KeyStore loadClientKeyStore(Context context) {
    InputStream in = context.getResources().openRawResource(R.yourKeyStoreFile);
    KeyStore trusted = null;
    trusted = KeyStore.getInstance("BKS");
    trusted.load(in, "yourClientPassword".toCharArray());
    in.close();
    return trusted;
}

ВНИМАНИЕ! КОММЕНТАРИИ ПЕРВОГО УРОВНЯ В ВОПРОСАХ УПОРЯДОЧИВАЮТСЯ ПО ЧИСЛУ ПЛЮСИКОВ, А НЕ ПО ВРЕМЕНИ ПУБЛИКАЦИИ.

Только зарегистрированные и авторизованные пользователи могут оставлять ответы.

Залогиниться

Зарегистрироваться

The “Connection reset by peer” error occurs during a network connection when the other end or server closes the connection without reading the transferred data. The peer will return the data packet you sent while sending the RST (reset) bit and forcefully terminate the connection.

This issue usually happens if you are being blocked by the Firewall on any point in the route. But it can also happen due to other reasons. In this article, we mention different causes for the error along with how you can resolve it in each scenario.

Causes for Connection Reset By Peer

First, make sure your system is not too busy. If you have high usage of CPU, memory or network, you’ll experience issues while setting up a new connection.

Also, try restarting the session and retry the attempt to make the connection. Then move on to the possible solution we have provided below.

Most of the steps we have mentioned are for a Debian based Linux server. If you have any other system, you can apply similar steps by searching on the internet for the exact process. Some commands also vary between the different Linux systems. So look out for those as well.

Check Logs

First, you need to check the logs or error messages to narrow down the reason for the error.

If you have access to the server, you can check the server-side logs as well.

For example, if you are experiencing this issue while setting up an ssh connection, you need to check the /var/log/auth.log file. To do so,

1. Open the Terminal.
2. Enter tail -f /var/log/auth.log.

It shows the logging information sent by the SSH daemon during the authentication attempts of your remote system.

Check Internet Connectivity and Routing

The next thing you should do is check for internet connectivity issues. You can check if the public or private server has gone down using IP lookup or similar websites.

You can also use use traceroute or tracert to trace the route between the two endpoints and check which access point is resetting your connection. The syntax is:

• On Linux: traceroute [domain/IP]
• On Windows: tracert [domain/IP]
  

If the public server or access points are down, you need to wait until they are up again. For issues with the private server, you can contact the system admin or restart it if you have access.

Check for IP Ban

One major reason for this issue while connecting to public servers is your IP being blacklisted by major security service providers. Most public servers ban IP addresses while conforming to these server’s database.

To check whether your IP address is blacklisted,

1. Open the MX Toolbox Supertool webpage.
2. Set the yellow drop down box to Blacklist Check.
3. Enter your IP address on the text box and click Blacklist Check. If you don’t know you IP address, search for “What is my IP” on Google.
   

If the public server or access points are down, you need to wait until they are up again. For issues with the private server, you can contact the system admin or restart it if you have access.

Check for IP Ban

One major reason for this issue while connecting to public servers is your IP being blacklisted by major security service providers. Most public servers ban IP addresses while conforming to these server’s database.

To check whether your IP address is blacklisted,

1. Open the MX Toolbox Supertool webpage.
2. Set the yellow drop down box to Blacklist Check.
3. Enter your IP address on the text box and click Blacklist Check. If you don’t know you IP address, search for “What is my IP” on Google.
   

If your IP is blacklisted on multiple security networks, or important ones like BARRACUDA, BLOCKLIST.DE, Nordspam BL, etc., most servers or security filters will also ban you.

The only thing you can do is talk your ISP and have them contact the server admin to remove the ban.

You can also try changing your IP address using VPN to bypass this issue.

Check Firewall and Network Security Filters

The “Connection reset by peer” error occurs mostly due to Firewalls blocking access to the server.

If you have access to the private server you are trying to connect to, you can check if the firewall is actually blocking access to your IP. To do so on Linux,

1. Open the Terminal
2. Enter sudo iptables -L --line-number
   
3. Check for authentication attempts of your IP address and check if the target accepts or rejects the connection.

You can also check other security filters available on the server. The steps may vary between the respective programs, so check the official website or documentation for the methods.

Then, you need to whitelist your IP address on intrusion prevention apps like Fail2ban, DenyHosts, and so on, to make exceptions to the Firewall rules. The necessary steps to do so on Fail2ban is as follows:

1. Open the Terminal and enter sudo nano /etc/fail2ban/jail.conf
2. Remove the # symbol in front of ignoreip = and add the IP addresses you want on the line.
3. For instance, the line can be ignoreip = 10.10.10.8
4. Save and exit.

Warning: Practices such as disabling Firewall or making exception for all IPs on the firewall is not recommended. Firewalls and security filters exist to protect your system. So rather than compromising the security, it’s better to search for a workaround.

Restart Services and Daemons

If you encounter this issue on a private network, it is possible that the server admin has changed the rules for the connection without restarting the daemon services. This causes the service daemons to get stuck as it is still want to conform to the previous settings.

1. Contact the server administrator and ask them to restart the service and the daemons in such scenario.
2. If you have access to the server, you can do it yourself. First, verify that the services and the daemons are running using systemctl command.
3. Restart the relevant daemons. The command you need for this process in a debian-based system is
   sudo systemctl restart “daemon name”

For instance, if you are setting up a FTP connection using samba share, you need to use the command sudo systemctl restart smbd. Since SSH service is available on almost all distros of linux, you don’t have to install any service package for it. So, for SSH connection, the command is sudo systemctl restart ssh.

And if you are using any other hosting services to set up the connection, you need to restart their daemons as well.

Edit Hosts File

Hosts files allow you to permit or deny access to particular IP addresses or hostnames. If you have access to the server, you should also check these files and make sure your IP address can establish a connection to the server.

To do so for a Debian System,

1. Open the Terminal and enter sudo nano /etc/hosts.deny
   
2. Search for your local IP or host name on the file.
3. If it’s there, comment it out by typing # before the line. You can also remove the line altogether.

You can also add your IP address on the hosts.allow file to force the connection. The process is similar to the above.

1. Open the Terminal and enter sudo nano /etc/hosts.allow.
2. Enter your IP address using the syntax is daemon_list : client_list [: command]
3. Save and exit.

The daemon for FTP is usually vsftpd and for ssh, scp, and sftp is sshd. So, to allow ssh connection with local address, 10.10.10.8, you need to add sshd : 10.10.10.8 , LOCAL

It is also possible to edit the hosts file on Windows based server. You can refer to out article on editing hosts file on Windows for more to learn the necessary process.

Increase Timeout or Send Keepalive Packets

Many networking tools drop idle TCP and FTP connections after a certain period of inactivity.

There are two ways to prevent this issue:

• Increase the timeout period.
• Send periodic heartbeat data.

The first option is not a good solution. Keeping the timeout long can affect the server’s connections to other networks as they have to wait longer before attempting to set up a connection. You also need to increase the timeout on both ends, which is not always possible.

So, the better solution is to send regular heartbeat or keepalive packets. This prevents the connection from being idle and keeps the session alive for longer period.

Some connections allow sending keepalive packets but you have to enable this process for others. Here’s how you can enable the process of sending such packets:

On Linux

1. Open the Terminal and enter sudo nano /etc/sysctl.conf
2. Add the following lines while changing the values (in seconds) per your preference:
   • net.ipv4.tcp_keepalive_time = 300
   • net.ipv4.tcp_keepalive_probes = 9
   • net.ipv4.tcp_keepalive_intvl = 10
     
   • Search for your local IP or host name on the file.
   • If it’s there, comment it out by typing # before the line. You can also remove the line altogether.

You can also add your IP address on the hosts.allow file to force the connection. The process is similar to the above.

1. Open the Terminal and enter sudo nano /etc/hosts.allow.
2. Enter your IP address using the syntax is daemon_list : client_list [: command]
3. Save and exit.

The daemon for FTP is usually vsftpd and for ssh, scp, and sftp is sshd. So, to allow ssh connection with local address, 10.10.10.8, you need to add sshd : 10.10.10.8 , LOCAL

It is also possible to edit the hosts file on Windows based server. You can refer to out article on editing hosts file on Windows for more to learn the necessary process.

Increase Timeout or Send Keepalive Packets

Many networking tools drop idle TCP and FTP connections after a certain period of inactivity.

There are two ways to prevent this issue:

• Increase the timeout period.
• Send periodic heartbeat data.

The first option is not a good solution. Keeping the timeout long can affect the server’s connections to other networks as they have to wait longer before attempting to set up a connection. You also need to increase the timeout on both ends, which is not always possible.

So, the better solution is to send regular heartbeat or keepalive packets. This prevents the connection from being idle and keeps the session alive for longer period.

Some connections allow sending keepalive packets but you have to enable this process for others. Here’s how you can enable the process of sending such packets:

On Linux

1. Open the Terminal and enter sudo nano /etc/sysctl.conf
2. Add the following lines while changing the values (in seconds) per your preference:
   • net.ipv4.tcp_keepalive_time = 300
   • net.ipv4.tcp_keepalive_probes = 9
   • net.ipv4.tcp_keepalive_intvl = 10
     
3. Save and exit.
4. Enter the command sysctl --load=/etc/sysctl.conf

The above lines specify that the system waits for 300 seconds before sending the first keepalive packet. Then, it keeps sending the packet every 10 seconds. If it doesn’t receive ACK (acknowledgement) signal for 9 successive times, the connection is dropped.

Increasing the Keepalive period for SSH connections might compromise security as it remains open for a longer time. This connection is supposed to be very secure, so it’s not recommended to make any changes to the keepalive settings for ssh.

On Windows

1. Open Run and enter regedit.
2. Navigate to ComputerHKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
   
3. Right-click on Parameters
4. Add the following DWORD entries along with the respective values (in milliseconds) as you see fit:
   • KeepAliveTime – 300000 (in Decimal)
   • KeepAliveInterval – 1000
5. To add an entry, right-click on Parameter, select New > DWORD (32-bit) Value and enter the name.
6. Then, double-click on the entry to change its Value data.

Note: You must also enable TCP keepalive packets in your TCP/FTP client.

Check sshd_config File

The sshd_config file configures all settings an SSH (Secure Shell) connection uses. So, if possible, you need to check this file on the server and make sure everything is alright.

1. Open the file using the command sudo nano /etc/ssh/sshd_config .
   
2. Right-click on Parameters
3. Add the following DWORD entries along with the respective values (in milliseconds) as you see fit:
   • KeepAliveTime – 300000 (in Decimal)
   • KeepAliveInterval – 1000
4. To add an entry, right-click on Parameter, select New > DWORD (32-bit) Value and enter the name.
5. Then, double-click on the entry to change its Value data.

Note: You must also enable TCP keepalive packets in your TCP/FTP client.

Check sshd_config File

The sshd_config file configures all settings an SSH (Secure Shell) connection uses. So, if possible, you need to check this file on the server and make sure everything is alright.

1. Open the file using the command sudo nano /etc/ssh/sshd_config .
   
2. Look at the options we have provided below and change accordingly. You may also change other options depending on your connection. We recommend checking out the sshd_config documentation for more information.
3. After changing these values, save and exit.
4. Restart sshd using the command sudo systemctl restart ssh

Some of the options are:

MaxStartups

The MaxStartups value determines the maximum number of possible unauthenticated connections to the SSH daemon before the connections start dropping.

It has the format MaxStartups 10:30:100, where,

• 10: Number of unauthenticated connections the dropping starts
• 30: Probability of dropping after reaching the maximum unauthenticated number
• 100: Maximum number of connections possible before dropping all of them

If your remote client needs to make more number of connections concurrently, you need to change these values.

Subsystem sftp

On a secure FTP connection using openssh package, the default value of Subsystem sftp is set to /usr/lib/openssh/sftp-server. However, sometimes, the openssh binary is available at /usr/lib/ssh/sftp-server instead. So you can alter this value and check if it works. If it doesn’t, revert it to the previous path.

ClientAlive

ClientAlive is a more secure keepalive setting. You can change the ClientAliveInterval and ClientAliveCountMax values in sshd_config to enable this setting.

ClientAliveInterval determines the interval of inactivity after which sshd sends an encrypted message to the client. And ClientAliveCountMax determines the max number of times sshd sends this message before dropping the connection if it doesn’t get any response.

Check Support for SSL

If the host server has enabled SSL (Secure Sockets Layer) but you haven’t enabled this service on your end, you can’t establish a connection.

So, you need to check the support for SSL on your TCP or any other network client and enable it. If it doesn’t support SSL, you need to use another client.

You also need to check your certificates and make sure you don’t have any malformed keys or certificates.

Change Open Connection Limit

Establishing a network connection also creates a socket, which is the logical window the client uses to communicate with the server. However, a server has a limit on how many sockets it can open at the same time.

If the server has already reached this limit, any new connection causes the server to drop the idle old connections. You can refresh or restart the session to renew the session. However, you can also increase the limit on the server side to facilitate more open connections.

If you want to change the limit for only the current session, you can use the command ulimit -n 65535, while replacing the number depending on your requirement.

To change it permanently,

1. Open the Terminal and enter sudo nano /etc/security/limits.conf
2. Add the following lines while changing the value of the limit if you want:
   • * soft nofile 65535
   • * hard nofile 65535
     
3. Save and exit. Then, restart the daemons and the session.

For Debian and Ubuntu systems, you need to enable PAM user limits as well. To do so,

1. Enter sudo nano /etc/pam.d/common-session
2. Add required pam_limits.so
3. Add this command on /etc/pam.d/common-session-noninteractive as well.
4. If you are using a SSH connection, add the line to /etc/pam.d/sshd

Debug Your Scripts and Configurations

Many users have encountered this issue while creating their own connection applications. In such scenario, any bugs in the scripts or configuration that unnecessarily close the connection or don’t conform the connection with the protocol will cause this error.

So, we recommend carefully looking through the program. Some protocols have quit or close commands that makes the host server close the connection.

You also need to close all forked child processes before exiting to prevent zombie processes. The zombie processes stay in the process table even after terminating the child. If there are too many zombie processes, the process table gets full. This way, the system fails to create new processes, disrupting the connection.

If you have trouble debugging your program, we recommend getting help from technical forums such as stackoverflow while providing the source code.