Same concept. Difference would be that you don’t have to rely on a third-party for your authentication and can self host it yourself. Plus they both have multitudes of other verifications, rules, etc. so in general I think it’s much more configurable.
I understand that using UDP in this way is very slightly more secure, because if a random person on the internet sends a packet to your port and doesn’t see a response, then they have no idea whether there is a program listening on that port. Whereas with TCP, they can know for sure that there is something listening, because they would be able to establish a TCP connection, even though they wouldn’t know what it is that’s listening unless the program responds with an error.
This is how Shadowsocks/Outline is more secure, at least. The Great Chinese Firewall needs to resort to active probing techniques (like replay attacks) to figure out what such a host is and what it does, and if it consistently replies to the replayed packets but not too generated ones then the GFW is likely to block it.
Wireguard won’t reply to requests from an unauthenticated client. UDP by nature does not require a connection to be established before exchanging any data. With TCP, simply replying to a syn request during connection establishment is enough to let someone know that something is listening on that IP.
From wireguards site:
We require authentication in the first handshake message sent because it does not require allocating any state on the server for potentially unauthentic messages. In fact, the server does not even respond at all to an unauthorized client; it is silent and invisible. The handshake avoids a denial of service vulnerability created by allowing any state to be created in response to packets that have not yet been authenticated.
So, if I understand correctly, you agree that the presence of a tunnel between the reverse proxy and home network does not do much in terms of negating threats, as the destination (a potentially vulnerable app) remains the same?
After reading through your response and the edit in your original post, I’ve realized I didn’t answer your actual question.
You’re correct in that you’re still exposed at the VPS level, while the traffic from the VPS to your home server via Wireguard is encrypted/safe.
At that point, you’re really just gaining the benefits of hosting through a VPS (IP obfuscation, better DDoS protection, etc.).
So? Who says you need to initiate the tunnel from the home network side? It is a two-way connection after all.
-
Some ISPs won’t allow you to host your stuff (actually they will block incoming connections to 80/443). Tunnel solves this
-
Your home IP would have to be static, and…
-
it could be ‘tied’ to your identity (say, if you put the cloud onto johnsmith.example.com, everybody may learn your IP and thus where you live - at least approximately)
I mean in the end, I only make sites accessible to the web when I WANT people to use them, so I don’t really need authentik or something like that. And there’s no point of authentik for local services
this is correct, if someone uses nmap for example to scan a TCP port you will be able to tell if its filtered/blocking connections or probes but with UDP it will be crickets because UDP is not a stateful protocol
I believe I misunderstood the original comment somewhat. Yeah it makes sense to use UDP, and there won’t be transport layer replies. The primary purpose of UDP usage though is to reduce overhead. The potential security implications are a bonus.
However it’s up to the application to decide not to respond. That’s a a security implementation on Wireguard’s end.
It does mitigate some threats like potentially DDoS, IP address exposure etc. It has some utility for people stuck behind CGNAT.
But no, it’s not a silver bullet solution to security. No method is. Security is defense in depth. You don’t configure one mitigation and say “job well done.” You add as many measures as practically possible and secure every layer.
95% of security is;
- software updates
- strong passwords
- only exposing what’s required
Alright, I think I understand, connection tracking means NAT can forward packets of a previously established connection, so a port may not have to be open on the client’s side. (Not sure how viable this is for the context I’m imagining, web server/ game servers)
Though, following from this, I’d imagine the vulnerability of an ‘insecure app’ at the listening end of the Wireguard interface (home network) would again be the same as if a situation where the port was simply forwarded, rather than using a tunnel.
My interest was more from a security perspective rather than a utility one. For 3. I don’t see any difference to this vs simply using a reverse proxy
So if you mean completely public sites, as in anyone can use them, then yeah you probably don’t need an authentication service unless you want each user to access certain things like their own account, storage, etc. But if you want access restricted to certain people, and they may use unknown IP addresses, then yes you need something. You could certainly use built-in authentication but one thing I didn’t mention is that Authelia and Authentik both have SSO capabilities.
I do the same (only make sites accessible to the web when I want people to use them) but I only want certain people to use them and even certain people to only be able to use certain ones so I use Authelia for all of that.
UDP itself is connectionless but that doesn’t mean that the higher layers are also connectionless and won’t expose their presence by responding to a UDP datagram.