Page 1 of 1

Connecting to VPN server behind reverse TCP proxy

Posted: Sat Sep 07, 2024 9:37 pm
by hisoka
Hi all,

I have been using VPN client pro now since 2018 (!!). I originally had a OBFS profile setup, and tunneled all my traffic to a OBFS open VPN server, which itself was behind a nginx proxy in stream mode listening on port 443. Due to a variety of reasons (notably, being unable to get OBFS packages to work on newer distros, and a requirement to do SSL termination on nginx instead of stream passthrough), I had to stop using this OBFS configuration. I am now struggling, however, to find a good replacement for this setup. I am on a network with very strict outbound rules (only allowing port 80 and 443), so my VPN connections have been unable to get out of this network. Are there any supported non-OBFS configurations in open VPN pro that will allow me to encapsulate within a TCP https header so I can use nginx to reverse proxy this traffic to a VPN server on the backend? I dont really care if its openVPN, wireguard, or some other backend system, I just need to be able to tunnel all traffic from this restrictive network over a VPN connection.

If anyone has any advice or solutions please let me know. Thanks.

Re: Connecting to VPN server behind reverse TCP proxy

Posted: Sun Sep 08, 2024 8:14 am
by admin
Hello,

have you tried using OpenVPN's tls-crypt option?
This option makes the connection more secure and makes it harder to identify OpenVPN packets.

Alternatively you can try using the SSH Tun protocol. It basically uses an ssh connection to forward the packets. It's not very fast but should be harder to block.
You can find some suggestions here:SSH Tun protocol hints

Re: Connecting to VPN server behind reverse TCP proxy

Posted: Sat Sep 14, 2024 5:49 pm
by hisoka
Thanks for the tips. I will have to see if tls-crypt will work behind a reverse proxy. The issue here isnt the packet types, its the port, and I cant run another service on 443 (already have a reverse proxy running there). I did some initial research on tls-crypt, but it wasnt obvious if a redirection from caddy or nginx would break the tunnel, but I can always try and see!