IP-Adresse in VPS nach Reboot mit Firewall im 169.254.x.x Subnetz

Liebes Forum,

ich nutze seit einigen Tagen meinen VPS 500 G11s BW24 wieder aktiver. Auf dem VPS ist Debian 13 installiert.

Ich habe nun vor kurzem die neue Firewall-Sektion im SCP entdeckt und mich gefreut, da ich eine KVM-basierte Firewall vermisst hatte (bzw. mir gewünscht hatte, hier mögliche eigene Fehlkonfigurationen "abzudichten"). Ich habe die Firewall also mit Policys ausgestattet und mich soweit gefreut, dass alles funktioniert.

Gestern Abend habe ich den VPS einmal neu gestartet und mich nicht mehr weiter damit beschäftigt. Heute nun habe ich festgestellt, dass mein Wireguard-Server auf dem VPS nicht mehr zu erreichen war, obwohl ganz explizit eine Policy für diesen Port eingestellt war.

Beim Debuggen habe ich festgestellt, dass meine VPN Verbindung von meiner nftables Firewall auf dem VPS geblockt wurden - was vorher nie passierte. Dabei konnte ich dann sehen, dass die VPN-Pakete komischerweise in der forward und nicht in der input chain gelandet sind. ip a brachte dann die Erklärung: das Interface hatte hier auf einmal nicht mehr die öffentliche IP (aus dem SCP) gelistet, sondern eine aus dem 169.254.x.x Subnetz. nftables (bzw. der VPS) hat die Pakete also nicht mehr addressiert an sich selbst gesehen. Ich hatte zeitweise auch eine allow regel für den VPN traffic in der forward chain von nftables hinterlegt. Aber der traffic wurde (meinem Verständnis nach korrekterweise) von Wireguard nicht verarbeitet.

Ich habe dann die Firewall im SCP wieder deaktiviert. Nach wenigen Minuten funktionierte der Traffic wieder UND das Interface hatte wieder die öffentliche IP-Adresse des Servers.

Jetzt frage ich mich natürlich: habe ich hier eine Fehlkonfiguration vorgenommen? Oder ist das eine Fehlkonfiguration der SCP Firewall?

Vielleicht kann jemand meine Verständnisfrage aufklären oder das Verhalten mal bei sich selbst replizieren.

Guter Punkt. Darüber hatte ich tatsächlich nicht nachgedacht!

Der Server ist nicht mit statischer IP konfiguriert, sondern zieht sich das per DHCP.

Heißt vermutlich Port 68 eingehend erlauben? Hier wäre vielleicht eine IP-Range der DHCP Server als Einschränkung hilfreich.

Oder einfach direkt auf statisch wechseln.

Wäre schön, wenn dies (ähnlich wie die ICMP default policy) bereits hinterlegt wäre.

Habe jetzt auf statische IP umgestellt.

Jetzt geht auch Wireguard wieder.

Hat mich auch gerade nochmal Zeit gekostet, weil ich dann erst gesehen habe, dass die Default Regeln am Ende eben nicht Allow All Outgoing | Drop All Incoming sind, sondern auch Outgoing blockiert wird und das dann nicht Stateful ist.

Ja, Serverbetrieb ist natürlich immer eigene Verantwortung. Aber vielleicht könnte man noch einmal weitere Default Policies aufnehmen, die solche Standardfälle etwas besser abdecken. Wenn man sie nicht haben will, kann man sie ja löschen (so wie SMTP und Ping Regeln).

Danke für den Austausch hier im Forum! Hat mir sehr geholfen.