Wireguard tunnel via TCP

Installing and Using OpenWrt Network and Wireless Configuration
1

Use case:
I am looking to use wireguard over TCP; wireguard doesn't support TCP natively and it needs to be integrated with other tools such as udptunnel or udp2raw to enable that feature.

my setup:
Configured wireguard client using luci-app-wireguard:
wireguard client EndPoint -- set to 127.0.0.1:3333
openwrt terminal -- I run the udptunnel/udp2raw command to listen on port 3333 and forward traffic to wireguard server.

This should be a simple use case but the traffic from lan is not making it to the server. The TCP tunnel gets stablished between openwrt-terminal and wireguard server but the udp traffic is not making it though.

Any guide or suggestion is greatly appreciated.

4

I posted the same thread, but it seems the udptunnel distributed in openwrt doesn't support it....?

1 Like
5

Here is it:

But this isn't WG as-is (kernel module and some userland for managing).

TunSafe is WG clone built only on userland. I'm using it on macOS and iOS.
But code isn't MIPS ready - ChaCha20 and Poly1305 isn't MIPS assembly optimized.

1 Like
6

I saw your thread; but unfortunately it got a lot of noises because people were asking too many whys instead of focusing on the problem. In this thread I have articulated the use case with the proper subject hoping for someone from dev to take a look and shed some light.
I believe we might need some sort of a loop back interface.... but i can't say for sure.

7

Example:
[Peer]
Endpoint=tcp://5.5.5.5:1234

8

TunSafe mentioned that "the code is still very experimental and untested, and is not recommended for general use"

Also, if we figure out how this can be done on openwrt it will open other possibilities that we can use to fix packet loss etc...

9

Actually code works very well. But it's abandoned...

10

WG intentionally doesn't use TCP for a variety of reasons. Probably the two most important factors are performance and stealth (it is not 'chatty' so it will never respond to probes or any packets unless the cryptographic payload is correct). Of course, WireGuard allows TCP to be turned within the UDP stream.

Wrapping TCP around the UDP WireGuard stream that encapsulates TCP+UDP data will reduce performance and negate part of the stealth component.

That said, you will not find a way to run WG via TCP in the native context. If you want to encapsulate the WG stream in TCP, you will need to have that connection established first (on both sides) and then you can initiate the WG connection. For example, if you were to use something like stunnel, your peers would have to first connect via stunnel and then open the WG session. This will make it considerably harder (or maybe impossible) to operate this on mobile OSs, but it could be done with desktop systems and/or another OpenWrt (or similar) system.

Returning back to your original ask -- can you describe why you want to do the TCP wrapper for your WireGuard setup? It is unnecessary in many/most contexts, but there are certainly outlier situations that may require a different approach.

1 Like
11

Due to ISP restriction I am looking to see if we can use the TCP wrapper. UDP is blocked.

12

I would guess the fact that encapsulating TCP packets in a TCP tunnel is problematic, because lost packets will trigger recovery/retransmission independently for the outer and the inner TCP connection, resulting in loads of duplicate data transfers that eat up bandwidth without delivering goodput... one could subsume this under "performance" but IMHO worth spelling out exlicitly, no?

2 Likes
13

Very much worth the explicit call out. Thanks for adding it.

14

If you're really need TCP-over-TCP then it's good to take one look on DSVPN:

and explanation how it works:
https://balaskas.gr/blog/2019/07/20/a-dead-simple-vpn/

But this is one-to-one VPN. One client connect to one server.

15

Than it would make more sense to use openvpn instead of a wireguard forced into TCP

5 Likes
16

Everyone here mentioned a good point; but let's think outside the box.
there are other values if we start thinking about how to accomplish this.
Openvpn cuts your bandwidth by 2/3 and it is terrible of handling packet loss. wireguard uses latest encryption and it's written in 4000 lines of code where openvpn it stacks up to 100,000 lines of code. I am looking for, is it possible to implement wireguard over TCP and if so how.... The rest we can debate once we identify a way of getting it done.

17

Thinking outside the box, how about a GRE tunnel to a VPS and wireguard over UDP inside of that tunnel? Unless your ISP only allows TCP that might work....

18

I like where this is going, but GRE is not encrypted and you'll need to add IPsec on top of it if you want the traffic to be encrypted. Also will GRE without IPsec allows the ISP to determine the protocol being used. I think so.

19

Your ISP blocks all UDP traffic? That seems excessive. What ISP is it?

20

Blocking UDP entirely would only disrupt important things such as DNS & NTP (for time sync).
So it makes sense if they (the ISP) won't interfere with that.

Instead of using TCP, why don't try to use UDP port 53 & UDP port 123?
I'm pretty sure it won't get blocked

1 Like
21

Well, the idea is to use GRE to get around your IPS UDP block. GRE is basically IIUC IP in IP, so instead of IP->UDP your ISP will see IP->IP->UDP and that might be enough to work around its filter rules. And if that works, you just use wireguard for the inner UDP traffic so that things are encrypted. Te outer IP header will have a fixed address pair, as will the inner IP header, and the UDP traffic will use (relatively) fixed UDP ports, so not much information that can leak to your ISP....

Using IPsec to transport wireguard encrypted packets, seems sub-optimal, because you are doing crypto twice then; I can construct scenarios in which double encryption might be a sane solution, but it is a stretch ;)....

22

That would be DNS and NTP, blocking UDP/53 would not affect clients since DNS falls back to TCP if UDP does not work and for NTP rate-limiting by the ISP would work (hopefully with a simply dropping policer and not with a traffic shaper+queue, but I digress).