I’m trying to use a VPN on an unreliable network that blocks UDP and randomly kills TCP connections (by spoofing RST packets). With OpenVPN this is tough because all the tunnel traffic gets sent through a single TCP connection. When that connection gets killed, the client has to open a new connection and start a new session, and the overall connection speed suffers.

I think if there were several TCP connections available for tunnel traffic, then when one of them goes down, the traffic could be sent through the others without disrupting the VPN session. I could implement something like this myself by writing a simple muxer/demuxer on the client/server, rewriting packet headers and then splitting them up across connections.

But I haven’t heard of this being done with VPNs before, so I’m wondering if it will break the VPN somehow, or have other unexpected downsides? Or maybe if it won’t work with OpenVPN, is there another VPN protocol it would work with?

  • It sounds like you have a firewall admin that imposes a time limit on long-lived TCP connections, and sends RSTs to tear them down. Not a typical use case for most tunneling software. Maybe the best impedance match would be for you to run a cloud (AWS?) linux server which is an OpenVPN endpoint, and then you worry about writing code that can reliably get your traffic to that linux server even in the presence of annoying RSTs. Also, separate point, if you typically see that after 90 seconds a connection gets torn down, maybe you'd like to cycle connections every 80 seconds?
    – J_H
    Oct 4, 2023 at 1:46
  • If you control both ends of the VPN link you just need to bond the two VPN connections - however this question is probably off topic here you may be better off with networkengineering.stackexchange.com
    – DavidT
    Oct 4, 2023 at 2:20
  • @DavidT I agree Network Engineering seems like a better fit, but they consider all protocols above OSI layer 4 to be off-topic, so I guess I can't ask questions about VPNs there.
    – moriarty
    Oct 4, 2023 at 3:08
  • @J_H Yes, you've summarized my situation well. My question is about the writing of that code - are there any gotchas I need to worry about or is it as simple as muxing/demuxing the TCP connections?
    – moriarty
    Oct 4, 2023 at 3:10
  • @moriarty, I feel it is the traditional "small matter of programming". :-) Maybe a weekend's worth of hacking?
    – J_H
    Oct 4, 2023 at 3:36

1 Answer 1


I understand that that you can't use a single TCP socket because of the "hostile" environment that the connection is running through.

However you are fundamentally solving the same problem that a TCP socket solves:

  • You are sending packets that might not arrive.
  • You need some mechanism to confirm they arrived.
  • If they don't arrive you need to re-transmit them.
  • If packets arrive multiple times and/or out of order you need to de-dup them and sort them into order.

Where "packets" are just blocks of data you have read off the primary/incoming socket and are forwarding.

You could implement this logic on top of TCP - where you also need manage the state of multiple TCP connections (detect when they are killed etc). However you may be better off just using UDP for the transport layer.

If your custom transport layer provides a clean TCP connection - i.e. that all bytes are delivered in the correct order.

There are only two issues I can think of, that may cause issues:

  • Performance - it's possible the VPN has some timeouts that may cause a problem.
  • IP/Identity - one side may use the IP address of it's partner for identity security.

Hence in both cases you may need to play with the config of the VPN.

  • Thank you for your answer! UDP would be the ideal choice, but unfortunately all UDP packets are blocked in this environment.
    – moriarty
    Oct 4, 2023 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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