Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to figure out whether the host network I am on is injecting TCP Resets into my VPN connection.

I have a personal OpenVPN server, and recently my attempts to connect over TCP port 1194 have been strangely interrupted by TCP reset messages, causing the OpenVPN client to enter a reboot-loop. I suspect the local network infrastructure does not like this, and is trying to block it. After changing the port to 1195 this issue disappears entirely, indicating this isn't just some bug in the openVPN client or server.

So my question is this: Is this mysterious injection of TCP resets a common trick to block unwanted connections? It seems a little strange -- why don't they just block the port or send other TCP control messages to terminate the connection? Last week, I was connecting over TCP to port 1194 without issue. The strange TCP resets just appeared this week.

Thanks in advance!

share|improve this question
up vote 4 down vote accepted

Yes, spoofed RST packets is a common method of cutting off undesired connections.

If you can clarify at what point in the connection the packet is received, that might help shed some light on the cause.

I've seen a few cases where this can happen:

  • A firewall simply blocking a port. It's responding on behalf of the destination host, sitting in-line; it will respond immediately to the client's SYN with a RST.
  • A firewall doing application protocol inspection or with some screwed up session timers. It may be watching the application protocol running on the port and think that it's needing to be cut off due to misbehavior, or it may simply be tracking connection state for NAT and lose track of your connection, then kill it when it sees traffic that it doesn't have a connection for. If this is the case, the connection will be killed some time after it has been established.
  • A web filter device of another kind. Some of these types of filters operate out-of-band, getting a copy of all traffic via a mirror or span port. In this type of situation, your connection will establish successfully but then have the spoofed packet kill the connection almost immediately afterward - say, within a second or so.
share|improve this answer
Interesting. It connects to the VPN just fine, then after about 5 seconds it receives the RST. It then reconnects, and after a few more seconds gets another RST, ad infitum. The strage thing is despite the RSTs, it still connects to the VPN (going to gives the IP of the VPN server) - it's just excruciatingly slow. Again, changing port to 1195 eliminates the issue altogether. – B. VB. Apr 16 '12 at 18:35
The client's probably re-establishing the connection and getting a bit of data through between every RST, causing that major slowness. Interesting.. I'd bet that it's option 3, some kind of filter that's seeing a copy of your traffic and spoofing a RST in an attempt to cut it off. Is the network you're on likely to have that kind of solution deployed? – Shane Madden Apr 16 '12 at 18:37
Very likely to. I wonder why a simple port change is all that's required - if their solution is so sophisticated, wouldn't it be able to detect the app-layer protocol without having to rely on well-known ports? – B. VB. Apr 16 '12 at 18:41
@B.VB. I've dealt with at least one product (Websense, but a much older version than current; things might have changed) that did exactly that; outside of HTTP traffic, no inspection was done on the protocol. Anything on allowed ports (443, 1935, etc) got through, no matter what the traffic was. – Shane Madden Apr 16 '12 at 18:47
I know for a fact websense is deployed in this case (see an earlier question of mine). I guess in this case it only does the inspection for the anticipated protocol for given ports, and just shovels through the data otherwise. Thanks for your responses! – B. VB. Apr 16 '12 at 22:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.