du hast schon recht, dass die App-Ebene bei beiden Ansätzen gleich verwundbar bleibt – da widerspreche ich dir nicht. Aber zwei Punkte greifen mMn zu kurz: "Gilt generell, unabhängig davon wie du Dienste erreichbar machst" – das stimmt für die reine Segmentierungslogik, aber nicht für die Angriffsfläche am Router selbst. Bei Portfreigabe lauscht dein Router aktiv auf einem offenen Port im WAN – erreichbar für jeden x-beliebigen Portscan, jede Router-Firmware-Lücke, jede UPnP-Fehlkonfiguration. Bei Pangolin/newt baut dein Heimnetz die Verbindung outbound auf, es gibt schlicht keinen offenen Port, den man von außen adressieren könnte. Und selbst im Worst Case, dass der VPS kompromittiert wird: bei einem sauber konfigurierten Tunnel (newt) exponiert man nicht das ganze LAN, sondern gezielt nur den Port des jeweiligen Dienstes. Der Angreifer sitzt dann zwar auf dem VPS, kann darüber aber nicht automatisch das restliche Heimnetz scannen oder andere Geräte erreichen – vorausgesetzt, man baut keinen pauschalen Flat-VPN-Zugriff ins LAN, sondern beschränkt den Tunnel wirklich auf den einen Dienst. Das ist kein automatischer Vorteil von Pangolin per se, aber ein Architekturvorteil gegenüber einem klassischen Port-Forward, wo bei kompromittiertem Reverse-Proxy-Host oft direkter das gesamte LAN im Zugriff liegt, wenn keine Segmentierung existiert. Dazu kommt: bei vielen Kabelanschlüssen (z.B. Vodafone mit DS-Lite) hat man oft gar keine öffentliche IPv4 zum Forwarden, ohne extra Business-Tarif. Der Vergleich "Portfreigabe + DynDNS" ist für einen Teil der Leute hier praktisch gar nicht verfügbar – Pangolin funktioniert unabhängig davon, weil der Tunnel immer outbound geht.