Selfhosted

I often read suggestions to use something like Tailscale (...) safer than opening a port for WireGuard (WG)

I guess someone is trying really hard to upsell Tailscale there. But anyways it all comes down to how you configure things, Tailscale might come with more sensible defaults and/or help inexperienced user to get things working in a safe way. It also makes it easier to deal with the dynamic address at home, reconnects and whatnot.

Specifically about Wireguard, don’t be afraid to expose its port because if someone tries to connect and they don’t authenticate with the right key the server will silently drop the packets. An attacker won’t even know there’s something listening on that port / it will be invisible to typical IP scans / will ignore any piece of traffic that isn’t properly encrypted with your keys.

f my VPS is compromised, wouldn’t the attacker still be able to access my local network? How does using an extra layer (the VPS) make it safer?

The extra layer does a couple of things, the most important might be hiding your home network IP address because your domains will resolve the VPS public IP and then the VPS will tunnel the traffic to your network. Since your home IP isn't public nobody can DDoS your home network directly nor track your approximate location from the IP. Most VPS providers have some security checks on incoming traffic, like DDoS detection, automatically rate limit requests from some geographies and other security measures that your ISP doesn't care about.

Besides that, it depends on how you setup things.

You should NOT have a WG tunnel from the home network to the VPS with fully unrestricted access to everything. There should be firewall rules in place, at your home router / local server side, to restrict what the VPS can access. First configure the router / local VPN peer to drop all incoming traffic from the VPN interface, then add exceptions as needed. Imagine you're hosting a website on the local machine 10.0.0.50, incoming traffic from the VPN interface should only be allowed to reach 10.0.0.50 port 80 and nothing else. This makes it all much more secure then just blunt access to your network and if the VPN gets compromised you'll still be mostly protected.

I self host because i do not trust companies. I will not even consider giving tailscale the keys to my kingdom.

The company Tailscale is a giant target and has a much higher risk in getting compromised than my VPN or even accessible services.

Understand the technology that you use and assess your use case and threat model.

It's mainly about managing risk, but also not all ISPs allow residential accounts to host services on their IP addresses.

Opening a port to the internet exposes the service to the whole internet, which means you need to secure the service with strong credentials, set up SSL, manage the certificate, and keep software up to date. You incur a lot of extra work, and also extra risk not only to your self-hosted service, but to any other services you host that "trust" your service.

All that work requires extra knowledge and experience to get right which, let's just be honest here: we've all probably followed that one How-To blog post, and maybe not understood every step along the way to get past that one pesky error.

Running a secure VPN overlay like Tailscale has much less overhead. You generate some keys, and configure your lighthouse server so the enrolled devices can find each other. It effectively extends your LAN environment to trusted hosts wherever they might be without exposing any of the services to the Internet.

Overall, Tailscale is simpler and much less work for individuals to set up and maintain than to secure multiple services against casual or targeted intrusion.

Tailscale also has the benefit of being a "client" in the view of the ISP, who see your IP address reach out to your VPS to initiate the tunnel, and not the other way around. If there's any CGNAT going on, Tailscale would tunnel through it.

It's very hard to compromise a VPN, they're designed specifically to prevent that.

A random service being exposed to the entire Internet may not be secure, and could provide a way in to your network for someone.

Adding on one aspect to things others have mentioned here.

I personally have both ports/URLs opened and VPN-only services.

IMHO, it also depends on the exposure tolerance the software has or risk of what could get compromised if an attacker were to find the password.

Start by thinking of the VPN itself (Taliscale, Wireguard, OpenVPN, IPSec/IKEv2, Zerotier) as a service just like the service your considering exposing.

Almost all (working on the all part lol) of my external services require TOTP/2FA and are required to be directly exposed - i.e. VPN gateway, jump host, file server (nextcloud), git server, PBX, music reflector I used for D&D, game servers shared with friends. Those ones I either absolutely need to be external (VPN, jump) or are external so that I don't have to deal with the complicated networking of per-user firewalls so my friends don't need to VPN to me to get something done.

The second part for me is tolerance to be external and what risk it is if it got popped. I have a LOT of things I just don't want on the web - my VM control panels (proxmox, vSphere, XCP), my UPS/PDU, my NAS control panel, my monitoring server, my SMB/RDP sessions, etc. That kind of stuff is super high risk - there's a lot of damage that someone could do with that, a LOT of attack surface area, and, especially in the case of embedded firmware like the UPSs and PDUs, potentially software that the vendor hasn't updated in years with who-knows-what bugs lurking in it.

So there's not really a one size fits all kind of situation. You have to address the needs of each service you host on a case by case basis. Some potential questions to ask yourself (but obviously a non-exhaustive list):

• does this service support native encryption?
  • does the encryption support reasonably modern algorithms?
  • can I disable insecure/broken encryption types?
  • if it does not natively support encryption, can I place it behind a reverse proxy (such as nginx or haproxy) to mitigate this?
• does this service support strong AAA (Authentication, Authorization, Auditing)?
  • how does it log attempts, successful and failed?
  • does it support strong credentials, such as appropriately complex passwords, client certificate, SSH key, etc?
  • if I use an external authenticator (such as AD/LDAP), does it support my existing authenticator?
  • does it support 2FA?
• does the service appear to be resilient to internet traffic?
  • does the vendor/provider indicate that it is safe to expose?
  • are there well known un-patched vulnerabilities or other forum/social media indicators that hosting even with sane configuration is a problem?
  • how frequently does the vendor release regular patches (too few and too many can be a problem)?
  • how fast does the vendor/provider respond to past security threats/incidents (if information is available)?
• is this service required to be exposed?
  • what do I gain/lose by not exposing it?
  • what type of data/network access risk would an attacker gain if they compromised this service?
  • can I mitigate a risk to it by placing a well understood proxy between the internet and it? (for example, a well configured nginx or haproxy could mitigate some problems like a TCP SYN DoS or an intermediate proxy that enforces independent user authentication if it doesn't have all the authentication bells and whistles)
  • what VLAN/network is the service running on? (*if you have several VLANs you can place services on and each have different access classes)
  • do I have an appropriate alternative means to access this service remotely than exposing it? (Is VPN the right option? some services may have alternative connection methods)

So, as you can see, it's not just cut and dry. You have to think about each service you host and what it does.

Larger well known products - such as Guacamole, Nextcloud, Owncloud, strongswan, OpenVPN, Wireguard - are known to behave well under these circumstances. That's going to factor in to this too. Many times the right answer will be to expose a port - the most important thing is to make an active decision to do so.

However, if my VPS is compromised, wouldn't the attacker still be able to access my local network?

That depends on your setup. I terminate my wireguard tunnels on my opnsense router, where I have explicit fw rules for what the vps hosts can talk to.

Wireguard is a VPN.

A VPN is preferable because what's safer, making one hole, or making six holes? One, obviously.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

14 acronyms in this thread; the most compressed thread commented on today has 17 acronyms.

[Thread #765 for this sub, first seen 27th May 2024, 12:45] [FAQ] [Full list] [Contact] [Source code]

Is it for security? I think is mostly recommended because your home router is likely to have a dynamic address.

This is in regards to opening a port for WG vs a tunnel to a VPS. Of course directly exposing nginx on your router is bad.

The thing about something like TailScale or ZeroTier or Nebula is that it's dynamic. These all behave similar to a multiplayer game ... a use case every residential firewall should "just get."

The ports that are "opened" can change regularly, they're not some standard port that can just be checked to see if it's open (typically).

Compare that to the average novice opening port 51822 for wireguard or 22 for SSH and you start to see the difference. With those ports, you've got a pretty good idea what's on the other side and it might even be willing to talk to you and give you error messages or TCP ACK packets to confirm it's there (e.g. SSH).

This advice is as you can probably imagine more relevant to things like OpenVPN that are notoriously hard to correctly configure or application protocols like SSH or HTTP.

With these mesh VPNs you also don't have to worry about your home dynamic IP changing and breaking your connection at inopportune times... And that's a huge benefit (IMO). It's also very easy to tie in new devices to the network.

A lot of it is about outsourcing labor to programs that know how to set up a VPN and make management of it easy. That ties into security because ... a LOT of security issues boil down to misconfiguration.

I guess the VPN adds an additional layer of authentication. And of course everything is encrypted by default which might otherwise not be the case.

Plus, with a VPN you can access multiple services.

Wireguard (which is what tailscale is built on) doesn’t even require you to open ports on both sides.

Set up wireguard on a vps first, where it is accessible, then set it up from within your network. It’ll traverse NAT and everything, and you don’t have to open a port on your network.

Tailscale is the exact same thing, just easier because it does everything for you (key generation, routing, …). Their service replaces your vps, up to you if you think that’s acceptable or not. IMHO, wireguard is worth learning at least. I eventually (partially) switched to tailscale because I’m lazy, and all services I host have authentication anyway, with vpn just being a second layer.

I think you misunderstood the advice. If your goal is to open your services to the internet then any of the approaches can let in an attacker. It would depend on whether any of the things you expose to the internet has a remote exploitable vulnerability.

A long-standing software like SSH or WG that everybody relies on and everybody checks all the time will have fewer vulnerabilities than a service made by one person, that you expose over reverse proxy; but they're not 100% foolproof either.

The Tailscale advice is about connecting your devices privately, on a private mesh network that is never exposed to the internet.

If you're behind CGNAT and use a VPS to open up to the internet then any method you use to tunnel traffic from the VPS into your LAN will have the same risk because it's the service inside that's the most vulnerable not the tunnel itself.