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.

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.

Ähnliche Artikel:

  1. Securepoint UTM und WireGuard (Kommt im Februar/März 2022)
  2. Securepoint OS v11 – Fehlende Route beim SSL-VPN Client
  3. WireGuard-Server unter Windows einrichten
  4. pfSense: Site-to-Site VPN mit WireGuard (oder auch nicht)
  5. Securepoint UTM: Ein paar Notizen zum Fallback