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?

  • Melmi@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-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.

      • Melmi@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        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.