0

I have a client connecting to a server via a VPN tunnel. The connectivity is in place, I can ping the server and requests some other services (a curl request on an API for instance) through that tunnel.

One service on the client cannot bind to the respective service in the server. When doing a tcpdump, I see that the server replies with a RST to the initial SYN of the client connecting to the port of the service.

Who can issue this RST? Is it the network stack of the server (because of a firewall, of a malformed packet, in short anything related to pure networking), or can this also be the service itself (the one on the server which is supposed to respond to queries from the client)?

The aim of the question is to try to discriminate between a misconfiguration of the devices (OS, firewall, ...) and a misconfiguration/incompatibility of the services themselves. Specifically, I would like to understand if a high-level service can (possibly indirectly) close the connection to the requesting client in such a way that a RST is issued back to the client.

WoJ
  • 3,607
  • 9
  • 49
  • 79

2 Answers2

2

A RST could be issued by the server or a network device that is interacting with the traffic (such as firewall, VPN concentrator).

Depending on network device and its configuration, it could respond RST, or ICMP unreachable, or silently just silently drop.

A graceful closedown of an establised connection by the service/application should cause a FIN packet rather than an RST; you could get an RST if you attempted to connect to a port that wasn't listening.

Your best option is to perform packet sniffing at different points in the network; you could capture the traffic at server's NIC to see if it is generating the RST, then move the monitoring point toward the client ( VPN and firewalls can generally dump a packet capture or logs )

CGretski
  • 111
  • 2
0

RST flags are sent by the server's network stack, firewalls tend to drop packets silently if the port is filtered.

Here's a good article that expands on this a little: https://blogs.technet.microsoft.com/networking/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them/

To answer your specific question, it's not impossible that some other process could be closing your TCP connections, although this is usually done by terminating the process that is listening on that port. If the listening process is still open after the RST, it's unlikely that another process has tried to close the connection.

car1bo
  • 71
  • 5