Hi!

I often read suggestions to use something like Tailscale to create a tunnel between a home server and a VPS because it is allegedly safer than opening a port for WireGuard (WG) or Nginx on my router and connecting to my home network that way.

However, if 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?

  • Trainguyrom@reddthat.comEnglish
    3·
    7 months ago

    The really nice thing about tailscale for accessing your hosted services is absolutely nothing can connect without authentication via a professionally hosted standard authentication, and there’s no public ports for script kiddies to scan for, spot and start hammering on. There’s thousands of bots that do nothing but scan the internet for hosted services and then try to compromise them, so not even showing up on those scans is a good thing.

    For example, I have tailscale on my Minecraft server and connect to it via tailscale when away from home. If a buddy wants to join I just send a link sharing the machine to them and they can install tailscale and connect to it normally. If for some reason buddy needs to be cut off, I can just stop sharing to that account on Tailscale and they can no longer access the machine.

    The biggest challenge of tailscale is also it’s biggest benefit. Nothing can connect without connecting through the tailscale client, so if my buddy can’t/won’t install tailscale they can’t join my Minecraft server

    • MelmiEnglish
      2·
      7 months ago

      WG uses UDP, so as long as your firewall is configured correctly it should be impossible to scan the open port. Any packet hitting the open port that isn’t valid or doesn’t have a valid key is just dropped, same as any ports that are closed.

      Most modern firewalls default to dropping packets, so you won’t be showing up in scans even with an open WG port.

        • MelmiEnglish
          1·
          7 months ago

          Yes, but only if your firewall is set to reject instead of drop. The documentation you linked mentions this; that’s why open ports are listed as open|filtered because any port that’s “open” might actually be being filtered (dropped).

          On a modern firewall, an nmap scan will show every port as open|filtered, regardless of whether it’s open or not.

          Edit: Here’s the relevant bit from the documentation:

          The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. If ports in all other states would respond, then open ports could all be deduced by elimination. Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered. When Nmap was released, filtering devices were rare enough that Nmap could (and did) simply assume that the port was open. The Internet is better guarded now, so Nmap changed in 2004 (version 3.70) to report non-responsive UDP ports as open|filtered instead.