These are some quick n’ dirty instructions so people can get up and running fast.
I wish I had known this was possible sooner.
Instructions:
Check that your VPN supports port forwarding and you have it enabled.
Grab your VPN’s internal IP with ip a
Find the interface for your VPN. For me it’s called tun0.
Open up /etc/nginx/nginx.conf
You can back it up, or comment everything out, or pick what’s necessary. Here’s what my file looks like.
worker_processes 1;
include modules.d/*.conf;
events {
worker_connections 1024;
}
http {
server {
listen [VPN INTERNAL IP]:[VPN FORWARDED PORT];
server_name localhost;
location / {
root '[ABSOLUTE PATH TO YOUR WEBSITE ROOT FOLDER]';
index index.html; # Relative to your website root.
}
}
}
Make sure your permissions are correct. For me, the ‘other’ group needs read permissions to the root folder, including where it’s mounted.
Start nginx with systemctl start nginx
You can visit your website on your host machine in a browser at [VPN INTERNAL IP]:[VPN FORWADED PORT]. For me, using the internal IP is required to view the website on my host machine.
To view the website on other machines, you can use [VPN EXTERNAL IP]:[VPN FORWARDED PORT]. The only thing you need to change is the IP address.
I hope this works for you and you are inspired to selfhost and take back power from those who stole it from us.
You must log in or register to comment.
You you setup a proper domain and https for your website instead of having a random IP address and port.
Don’t visit http pages in 2025. It is a major security risk.
LOL. On the scale of risky things I’ve done today, visiting this guy’s http website barely rates a mention.
Someone posts about something they’ve learned and the best you can do is dump on them about whatever thing in order to demonstrate to everyone your superior knowledge.
Everyone starts somewhere.
Let’s be real, this guy has no knowledge. He’s just yet another security parrot who doesn’t even understand the why behind the things they’re regurgitating.
Thanks.
It’s my understanding that https provides encryption for the data sent between you and the server. If you’re not sending any sensitive data, then the encryption shouldn’t be necessary.
Don’t get me wrong, encryption is great even when it isn’t necessary. For my demonstration purposes though, I chose not to include it.
I also believe it’s possible to set up HTTPS encryption without a domain name, but it might result in that “we can’t verify the authenticity of this website” warning in web browsers due to using a self-signed certificate.
That is a pretty bad take as all data is sensitive. Https also provides integrity to prevent man in the middle attacks.
And that’s why even static sites like Hugo blogs or even simple pages like the one OP posted should have HTTPS. Source: Studied Distributed Systems at university.
Let’s Encrypt are rolling out IP-based certs, you may wanna follow its development. I’m not sure if it could be used for your forwarded VPN port, but it’d be nice anyhow
Edit: I believe encryption helps prevent tampering the data between the server and user too. It should prevent for example, someone MITM the connection and injecting malicious content that tells the user to download malware
Thanks. This is new to me and I’m going to be looking into it.
As I use docker for most of my deploys (as you should for websites exposed to the Internet anyway), I can wholeheartedly recommend traefik for this. Basically it has the functionality of nginx, but supports easy Let’s Encrypt certificates.
Let’s Encrypt are rolling out IP-based certs, you may wanna follow its development. I’m not sure if it could be used for your forwarded VPN port, but it’d be nice anyhow
It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.
I believe encryption helps prevent tampering the data between the server and user too. It should prevent for example, someone MITM the connection and injecting malicious content that tells the user to download malware
No, encryption only protects the confidentiality of data. You need message authentication codes or authenticated encryption to make sure the message hasn’t been
transportedtampered with. Especially stream ciphers like ChaCha (but also AES in counter mode) are susceptible to malleability attacks, which are super simple yet very dangerous.Edit: this post is a bit pedantic because any scheme that is relevant for LE certificates covers authenticity protection. But it’s not the encryption part of those schemes that is responsible.
Public key crypto, properly implemented, does prevent MITM attacks. TLS does do this, and that’s all that matters here
Public key crypto, properly implemented, does prevent MITM attacks.
It does, but modern public key crypto doesn’t encrypt any client data (RSA key exchange was the only one to my knowledge). It also only verifies the certificates, and the topic was about payload data (i.e. the site you want to view), which asymmetric crypto doesn’t deal with for performance reasons.
My post was not about “does TLS prevent undetected data manipulation” (it does), but rather if it’s the encryption that is responsible for it (it’s not unless you put AES-GCM into that umbrella term).
Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it’s all encrypted.
Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned). As long as that key was transferred securely and uses a good mode like CBC, an attacker ain’t messing with what’s in there.
I think you’re confusing the limitations of each building block with how they’re actually implemented together in TLS. The whole suite together is what matters for this thread.
Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it’s all encrypted.
I never said it isn’t, but it’s done using symmetric crypto, not public key (asymmetric) crypto.
Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned).
Not anymore, this was only true for RSA key exchange, which was deprecated in TLS 1.2 (“Clients MUST NOT offer and servers MUST NOT select RSA cipher suites”). All current suites use ephemeral Diffie-Hellman over elliptic curves for key agreement (also called key exchange, but I find the term somewhat misleading).
As long as that key was transferred securely and uses a good mode like CBC, an attacker ain’t messing with what’s in there.
First, CBC isn’t a good mode for multiple reasons, one being performance on the encrypting side, but the other one being the exact reason you’re taking about: it is in fact malleable and as such insecure without authentication (though you can use a CMAC, as long as you use a different key). See https://pdf-insecurity.org/encryption/cbc-malleability.html for one example where this exact property is exploited (“Any document format using CBC for encryption is potentially vulnerable to CBC gadgets if a known plaintext is a given, and no integrity protection is applied to the ciphertext.”)
As I wrote in my comment, I was a bit pedantic, because what was stated was that encryption protects the authenticity, and I explained that, while TLS protects all aspects of data security, it’s encryption doesn’t cover the authenticity.
Anyhow, the point is rather moot because I’m pretty sure they won’t get a certificate for the IP anyways.
It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.
They’re ‘shortlived’ 7 day certs, verified using a HTTP challenge. It doesn’t matter who owns the IP, it’s just a matter of who holds the IP.
Right, and for the challenge, you need to have access to a privileged port (which usually implies ownership), which you won’t get assigned.
Ah right, completely forgot about that (80 for HTTP-01, 443 for TLS-ALPN-01). Is a bummer unfortunately
It takes two seconds to get https and 10 bucks a year for a domain. Come on
I also believe it’s possible to set up HTTPS encryption without a domain name, but it might result in that “we can’t verify the authenticity of this website” warning in web browsers due to using a self-signed certificate.
Just create your own rootCA and IntermediateCA and sign your certificate with those, put the CA in your trust store of your system and get rid of this self-signed warning on every device and happily access all your service via: *.home.lab or whater ever local domain pleases you.
It’s my understanding that https provides encryption for the data sent between you and the server. If you’re not sending any sensitive data, then the encryption shouldn’t be necessary.
As others have pointed out, everything can be sensitive. If I’m self hosting nextcloud instance with chat that under British law should check for age… self hosting is now sensitive.
In addition to that, without a secure connection you’re stuck with HTTP/1.1 from 1999 instead of the modern 2 or 3 versions.
I also believe it’s possible to set up HTTPS encryption without a domain name, but it might result in that “we can’t verify the authenticity of this website” warning in web browsers due to using a self-signed certificate.
You can: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate
In addition to that, without a secure connection you’re stuck with HTTP/1.1
That’s not entirely true. A lot of requests, even with https, are send over HTTP/1.1. And this is kinda mind blowing that in 2025 we still rely on something so old and insecure…
Same goes with SMS and the old SS7 protocol from 1970… 2FA SMS is probably the most insecure way to get access to your bank account or what ever service promotes 2FA sms login.
I can’t believe SMS is still used for anything but sure OTP sent in text makes sure my account is secure Mr Bank.
Anyone with the ability to inject or modify packets in the network path between server and client can inject malicious javascript or browser exploits into an unencrypted HTTP TCP stream. The client’s User-Agent and other headers would allow the attacker to customize their attack to target that specific browser version, and compromise the client machine.
There’s no security risk viewing this bit of html lmao
How so?
Data send back isn’t validated so someone could tamper with the data. A bad actor could add some arbittary Javascript plus ISPs have been caught inserting marketing materials into pages.
From a privacy perspective it is also bad as not only does it include your user agent in plain text it doesn’t have any encryption on page contents which allows your ISP to snoop on what you are doing.
All of these reasons are while we moved to https. X.509 certs are free and trivial to setup with Caddy or any other Reverse proxy/web server. If https was crazy had to setup I’d be more understanding but it is very easy to do in 2025.
Do you really think someone is going to set up a MITM attack for the dozen people who visit this blog?
No, but governments and ISPs can and have historically done so for all http traffic.
It doesn’t matter the page. They just care about http.
I’ll bite.
The risk is training people in bad behaviors, and then having those people do stupid things like type in a password.
There’s no password entry on this site, and what people do on other websites is not OPs responsibility.
Is it not possible to set up https for just an ip address with no domain?
Buy a domain
They are pretty cheap especially compared to hardware
I absolutely respect rawdogging your website with just an IP
Thank you!
I’m sorry if this is dumb, but do I need to run the vpn on a dedicated machine? If so can I use a raspberry pi?
It’s not dumb at all! Don’t be afraid to ask. I’m not an expert and still learning myself.
The VPN is running on the same machine that I am hosting the website on. There may be some configuration you can do to perhaps have the connection routed through your raspberry pi with a VPN running on it to the machine that’s hosting the website, but I’m not sure how.
Otherwise, you should be able to at the very least run the entire setup on a raspberry pi.
Not sure how much you’re paying for your VPN, but a virtual private server can be had for about $5 per month. You’ll get a real IPv4 address just for you, so you won’t have to use non-standard port numbers. (You can also use the VPS as a self-hosted VPN or proxy.)
$5 per month doesn’t get you much processing power, but it gets you plenty of bandwidth. You could self-host your server on your home computer, and reverse-proxy through your NAT using the VPS.
You could even go the Oracle route on their free tier, probably has more compute than many $5/m VPS, although the learning curve is MUCH steeper than a simple VPS
