Die Netcup Firewall ist stateful (mit Connection-Tracking) für TCP aber nicht für UDP. Das heißt, die Pakete in der anderen Richtung einer TCP-Verbindung sind automatisch auch freigegeben, aber für eine UDP "Verbindung" musst du die ausgehenden Pakete ausdrücklich in einer separaten Regel durchlassen. Debugging-Tipp: Du kannst mit tcpdump sehen, ob Pakete deinen Server erreichen, unabhängig davon ob eine Firewall auf dem Server sie verwirft, ein Programm sie entgegennimmt oder nicht oder ob die Verbindung sonst funktioniert.
Icb kenne die netcup Firewall noch nicht so genau, aber meines Erachtens sind in den Regeln mehrere Dinge falsch.
Inbound:
Destination(s) (IPs / Netzwerke): *
Hier sollte eine konkrete Zieladresse stehen. Auch wenn man Netzwerke angeben kann: Der Server lauscht ja nur auf einer IP, oder?
Outbound:
Source(s) (IPs / Netzwerke): 64831
Das ist Unsinn: eine Portnummer bei der IP-Adresse. Hier sollte wieder die konkrete Adresse des Servers rein.
Source Port(s): *
Bevor du auf die Idee kommst, hier den offenen UDP-Port von Wireguard einzutragen: Nur weil der Port eingehend offen ist, heißt das noch lange nicht, dass auch die ausgehenden Pakete von diesem Port kommen. Von daher ist "*" vermutlich richtig.
Alles anzeigenIcb kenne die netcup Firewall noch nicht so genau, aber meines Erachtens sind in den Regeln mehrere Dinge falsch.
Inbound:
Hier sollte eine konkrete Zieladresse stehen. Auch wenn man Netzwerke angeben kann: Der Server lauscht ja nur auf einer IP, oder?
Outbound:
Das ist Unsinn: eine Portnummer bei der IP-Adresse. Hier sollte wieder die konkrete Adresse des Servers rein.
Bevor du auf die Idee kommst, hier den offenen UDP-Port von Wireguard einzutragen: Nur weil der Port eingehend offen ist, heißt das noch lange nicht, dass auch die ausgehenden Pakete von diesem Port kommen. Von daher ist "*" vermutlich richtig.
Ich habe das ganze nochmal angepasst:
Beschreibung: Wireguard Inbound IPv4
Typ: EINGEHEND
Aktion: ACCEPT
Protokoll: UDP
Source(s) (IPs / Netzwerke): *
Source Port(s): *
Destination(s) (IPs / Netzwerke): <IPv4-Server>
Destination Port(s): <Port-Wireguard>
Beschreibung: Wireguard Inbound IPv6
Typ: EINGEHEND
Aktion: ACCEPT
Protokoll: UDP
Source(s) (IPs / Netzwerke): *
Source Port(s): *
Destination(s) (IPs / Netzwerke): <IPv6-Server>
Destination Port(s): <Port-Wireguard>
Beschreibung: Wireguard Outbound IPv4
Typ: AUSGEHEND
Aktion: ACCEPT
Protokoll: UDP
Source(s) (IPs / Netzwerke): <IPv4-Server>
Source Port(s): <Port-Wireguard>
Destination(s) (IPs / Netzwerke): *
Destination Port(s): 1024-65535
Beschreibung: Wireguard Outbound IPv6
Typ: AUSGEHEND
Aktion: ACCEPT
Protokoll: UDP
Source(s) (IPs / Netzwerke): <IPv6-Server>
Source Port(s): <Port-Wireguard>
Destination(s) (IPs / Netzwerke): *
Destination Port(s): 1024-65535
Funktioniert mit diesen Einstellungen.
Sollte das nicht dauerhaft stabil sein, dann würde ich zuerst das hier überprüfen:
Source Port(s): <Port-Wireguard>
Wie gesagt, nur weil eine App einen Port eingehend öffnet, bedeutet das nicht, dass sie auch ausgehend alles darauf sendet.
Im Whitepaper zu WireGuard, Kap. 2.1 (siehe https://www.wireguard.com/papers/wireguard.pdf) findet sich folgender Satz:
Note that the listen port of peers and the source port of packets sent are always the same, adding much simplicity, while also ensuring reliable traversal behind NAT.
Wird damit nicht klar festgelegt, dass WireGuard sich hier anders verhält?
