Reason for Reset from Client
Hi Everyone,
I am trying to troubleshoot an issue where the client is sending a Reset packet absurdly. Background of the issue:-
--> Issue happens for multiple users randomly. --> User is trying to connect to a VPN (VPN connection with firewall gateway) and it just disconnects mostly in less than 5 minutes. The traffic from the user is going through a proxy but the gateway's IP is bypassed from the proxy and the connection for the VPN happens directly between Client and VPN gateway. --> The problem here is that it works fine when we remove the proxy. Although, the traffic for VPN gateway goes without proxy in the non-working scenario.
Taking a look at the Non-working captures, I see the client sending an RST packet randomly. I see the client send the reset in a few miro- milliseconds. In the second capture, I see that on 224, the client sends an out of sequence packet and the next packet we received from the client is Reset .
Another thing to notice in both captures is the ACK number sent from the client (which is very high). Is it an expected behaviour.?
Also, from a working capture for another user through the same proxy, there are no issues. Since the VPN works fine without proxy, we need to find a conclusion here.
Below is the link for the file (password - 'Password':-
Note - File is sanitized.
Regards, Harneet
"Resets are almost never a network issue..." Check this explanation .
It seems your captures are done on the VPN client system so it is the VPN client sending the RST.
Have you enabled logging on the client to see what caused it to do this?
@bubbasnmp - Thanks. I understand that it could not a network issue and getting an RST could be an issue with the client. However, my question was to understand more about the high "ACK Number" in the RST. Is that normal.?
Plus the RST is sent immediately after the response, which makes me think it could be an issue from the application side. However, I don't see any errors in the proxy logs (on the client side) and no errors given by the VPN logs (on the gateway).
Let's see if anyone else anything to add on here.
Is the behaviour from the "Not Working" szenario with the out of sequence packet always the same? Otherwise it's just a lost packet during the capture and can be ignored for troubleshooting.
The high ACK sequence number is not comply to RFC, becaue the ACK flag in this packet is not set. So the ACK field must be zero.
Would be good to see what happens on the server side during this issue. It's possible to capture on both sides until the issue occures?
Thanks @JasMan. Yes, the out of sequence was seen in 1 of the two captures and that's the reason I ignored it. Thanks for mentioning that ACK should be 0, but I think it could be the behaviour of the stack and that can be ignored here too, but I understand that it's not expected.
Regarding the captures on both sides, I don't have the services side captures as of now. But I plan to do that next as I am not able to figure out things with this data collected.
It's not clear where specifically your capture was taken. Was it on the client or on some middleware device?
The TTL values seen in the capture implies the capture was taken on the client but the presence of a middleware device (the proxy?) and capturing on it could confuse the issue.
I've seen first hand that packets arriving out-of-order at a linux NAT server can trigger TCP RSTs. In a nutshell in my case it appeared that Netfilter’s conntrack code was too strict about out-of-order packets, and would send a RST for some out-of-window segments. The workaround
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberalon the linux NAT server. This link goes into much more details on someone else's connection tracking issue.You asked about the ACK number seen in the RST packet. Interestingly it has the same raw value as the sender's raw ...(more)