Wer mehrere Internet-Zugänge mit einer Securepoint UTM verwendet und zudem auf WireGuard als VPN-Lösung setzt stößt möglicherweise über eine Einschränkung.

Verwendet man WireGuard mit dem primären Internet-Zugang, also beispielsweise an der Schnittstelle wan0 bzw. der Schnittstelle die die Standard-Route verwendet, hat man kein Problem. Möchte man allerdings WireGuard an einen weiteren Internetzugang nutzen, funktioniert dies nicht.

Client-Verbindungen kommen zwar an der richtige Schnittstelle an, aber die Antworten werden dann über die andere Schnittstelle (auf die die Standard-Route verweist) versendet.

Dieses Verhalten lässt sich auch nicht irgendwie “austricksen”. Mit Rule-based Routing oder einem Port-Forwarding auf die interne Schnittstelle kann dies nicht geändert oder gelöst werden. <- Siehe Update vom 13.07.2026 weiter unten.

Das Problem ist dabei nicht auf der Securepoint UTM-Seite, sondern direkt bei WireGuard, da dieses schlicht die Default Route verwendet und es aktuell nicht so einfach ist, dies irgendwie zu ändern.

Es gibt bei Linux die Möglichkeit dies mit mehreren Routing-Tables und einem Regelwerk anzugehen, bei BSD wiederum mit Gateway-Groups, bei der Securepoint UTM und vielen anderen Routen geht das aktuell allerdings (noch) nicht.

Wie mir der Support verraten hat, wird intern an einer Lösung gearbeitet, wie lange es dann dauert bis diese nutzbar wird, ist aktuell offen.

Mit SSL-VPN (OpenVPN) und IPsec (ungetestet, soll allerdings funktionieren), Reverse Proxy usw. klappt wiederum der Zugriff über einen oder mehrere Internetzugänge, sofern man eine öffentliche IP-Adresse hat versteht sich.

Kurzum: Möchte man WireGuard verwenden, muss darauf geachtet werden, das der primäre Internetzugang verwendet wird.

Update 13.07.2026

Und sie bewegt sich doch: Da ich gerade ein Thema mit nicht funktionierenden IPv6 (auf Client-Seite) habe und ein Augenblick Zeit war, habe ich es noch mal mit einer Port-Weiterleitung versucht.

Die Kunden-Umgebung sieht wie folgt aus:

• Securepoint UTM RC100 mit Firmware-Stand 14.1.6.
• Der primäre-Internetanschluss ist von der Deutsche Glasfaser (DG), d.h. CGNAT (keine öffentlich-zugängliche IPv4, nur IPv6 ist aus dem Internet zugänglich) auf der Schnittstelle A0 (Zone: external-interface bzw. external-interface_v6).
• Der sekundäre Internet-Anschluss ist von der easybell mit fester öffentlicher IPv4-Adresse auf der Schnittstelle wan1 (Zone: external-interface2)
• Die Default Route der UTM zeigt auf den DG-Anschluss.

Da es aktuell so ist, das WireGuard über den easybell, sprich via IPv4 umgesetzt werden muss, sollte eine Lösung her. Kurz mal eine Port-Weiterleitung wie folgt eingerichtet und siehe da, es geht:

Das Ausrufezeichen ignorieren (ist nur ein Hinweis auf mögliche Probleme):

Auf der Client-Seite muss natürlich bei “Endpoint = ” die öffentliche IPv4-Adresse oder ein entsprechend-auflösender FQDN eingetragen sein.

Warum es anno 2023, als dieser Beitrag entstand, so nicht funktioniert hat, kann ich nicht sagen.

Wie hat Dir der Artikel gefallen ?

(Bislang keine Stimmen erhalten.)

Loading...

Du möchtest den Blog unterstützen ?

Neben PayPal.ME gibt es noch weitere Möglichkeiten, lies hier wie du diesen Blog unterstützen kannst.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 15 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.