wstunnel + wireguard with reverse proxy setup

[winner-schnitzel]

Describe the goal

Goal is to make wstunnel work behind a reverse proxy.

Describe what does not work

The wireguard handshake packet is twisted. This worked in the past, but it was long time ago. I added cloudflare recently but I don't think it changes the content of packets. Probably something changed in new versions.

The setup works until the wireguard packets are "decapsulated" from the wstunnel packet. The standard wireguard handshake initial packet have patterns, I'll list down what it should be and what I see. I will include 2 packets that are sent for handshake initiation. The 2nd packet is sent about 2s after the 1st packet.

bytes	wireguard pattern	packet 1	packet 2
first 4 bytes	01 00 00 00	a5 e6 db 7f	7d 51 dd c1
last 4 bytes mac2	00 00 00 00	a4 e6 db 7f	7c 51 dd c1

The payload length is correct, all payloads are 148 bytes long, as the length of handshake initiation payload. But the contents are obviously twisted. This looks like encryption but I don't know where this comes from.

Describe your wstunnel setup

I have a domain for my VPS and one subdomain is used for wireguard connection. When URI is for wireguard, Apache forwards everything to a predefined port on lo. Wstunnel listens to this port and do wstunnel stuff with it, then forwards it to wireguard port on lo. Wireguard should pick up from there. The setup has custom certificates with certbot. TLS 1.3 is used.

Desktop :

client:

• OS: Android
• Version 16
• Uses Termux

server:

• OS: Linux

[bytejedi]

If cloudflare in front of your wstunnel. You need to set wstunnel allow insecure.

And this flag
--tls-sni-override <DOMAIN_NAME>
Domain name that will be used as SNI during TLS handshake
Warning: If you are behind a CDN (i.e: Cloudflare) you must set this domain also in the http HOST header.
or it will be flagged as fishy and your request rejected

[winner-schnitzel]

If cloudflare in front of your wstunnel. You need to set wstunnel allow insecure.

And this flag --tls-sni-override <DOMAIN_NAME> Domain name that will be used as SNI during TLS handshake Warning: If you are behind a CDN (i.e: Cloudflare) you must set this domain also in the http HOST header. or it will be flagged as fishy and your request rejected

Thanks for the reply.

--tls-sni-override <DOMAIN_NAME> this solved my issue. I was under the impression that when I use my own domain name I don't need to add this. However, as it turns out, I do. But cloudflare didn't "reject" my request, just somehow scrambled it. I can see my packets on my VPS so I didn't think cloudflare is the problem.

I didn't allow insecure connection because I have my certificates setup for my domain.

[winner-schnitzel]

If cloudflare in front of your wstunnel. You need to set wstunnel allow insecure.

And this flag --tls-sni-override <DOMAIN_NAME> Domain name that will be used as SNI during TLS handshake Warning: If you are behind a CDN (i.e: Cloudflare) you must set this domain also in the http HOST header. or it will be flagged as fishy and your request rejected

unfortunately I need to reopen this issue because the connection established is extremely unstable. I need to reconnect on average 3 times before wireguard works properly.

I see on my phone errors and I don't know if they are related to the issue.

• error while reading from tunnel rx Connection reset by peer (os error 104). In this case, I get few packets through wireguard, but most of them are lost.
• sometimes the wstunnel log stays the same for minutes, sometimes it tries to reconnect rapidly. Sometimes I receive some kiB of data but the connection is mostly broken.

I recently reorganized my certificates using certbot but I don't think this has any impact on the above behavior.

[bytejedi]

Seems like firewall or ISP or Cloudflare reset your tcp