Host network injecting resets into my TCP connection?

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!

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.

Check more discussion of this question.