Wireguard Multiwan

[wupperi]

Hallo,

ich habe ein Problem, dass keine Daten durch den Wireguard Tunnel geroutet werden. Mein Setup sieht so aus:

Code: [Select]


              WAN                      WAN
                 :                        :
                 : DSL-Provider       : DSL-Provider
                 :                        :
             .---+---.                 .--+--.
         WAN | DSL |           | DSL | WAN2
             '---+---'                 '--+--'
                 |                        |
                |  Stat public IP     |Public IP
                 +------| OPNsense |------+
                             |       |
                      LAN |       | LAN
                             |       |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-----...
                     (Clients/Servers) 10.1.1.0/24 und 192.168.4.0/24



Ich habe den Wireguard Server aufgesetzt und Clients entsprechend konfiguriert.
Ich hatte Wireguard schon einmal aufgesetzt, als ich nur eine Leitung hatte.

Jetzt mit 2 Leitungen wird mein Tunnel im client log zwar als "Connected" angezeigt, allerdings werden keine Daten geroutet. "TLS handshake initialization started" und diese läuft dann in einen Timeout. Der Tunnel terminiert über den DSLer mit statischer IP Adresse und muss ja darüber auch wieder raus.

Inbound allow Regel UDP auf WG Server Port auf "This Firewall" ist gesetzt, allowed IPs sind testweise jeweils die kompletten /24 Netze aus den beiden LANs und aus dem virtuelle WG Netz.

Ich vermute stark, dass ich irgendwo im outbound NAT noch ein Thema habe, stehe aber auf dem Schlauch.
Kann mir jemand einmal kurz mit den notwendigen Regeln (ggfls. Routen) helfen?

wupperi

[mimugmail]

Kannst du das mal mit einem anderen Dienst testen (z.B. SSH auf die Firewall) um den Fehler einzugrenzen (Wireguard selbst oder MultiWAN an sich)

[wupperi]

SSH auf die Firewall geht ohne Probleme. (any -> this Firewall -> SSH -> allow)

Auch Portforwarding auf Server im LAN geht (inbound NAT: externe statische IP WAN1-> LAN IP / outbound NAT: src IP server -> destination any, NAT source address = gateway address, gateway = wan1 gateway)

Ich sehe auch, dass mein WG Tunnel aufgebaut wird, die Clients senden halt nur TLS handshake requests, die offensichtlich nicht beantwortet werden. Der Wireguard traffic schlägt also sicherlich auf der FW auf.

[wupperi]

Denke ich habe das Problem schon mal identifiziert, weiss nur nicht, wie ich es lösen kann:

Vielleicht vorab:

Meine Leitungen in den Gateway Groups sind nicht im gleichen Tier, sondern die Leitung mit der Dynamischen IP ist Tier 1, die mit den statischen IPs ist Tier 2. Die Tier 2 Leitung ist nur Backup, bzw. wird nur für inbound services (Server) genutzt. Damit für diesen Traffic für den outbound Weg nicht die Tier 1 Leitung genutzt wird, setze ich mittels Firewall route den Gateway der Tier 2 als Gateway für genau diesen Traffic von den jeweiligen Servern outbound. Klassisches Poilcy Based Routing.

Das WireGuard Paket kommt über das richtige WAN Interface (Tier 2 mit statischen IPs) rein und geht aber über das falsche (Tier 1) raus.

Mir fehlt aber gerade die Phantasie, wie ich für den Wireguard Serice den Traffic über Tier 2 outbound erzwinge?

[mimugmail]

Das WireGuard Paket kommt über das richtige WAN Interface (Tier 2 mit statischen IPs) rein und geht aber über das falsche (Tier 1) raus.

Mir fehlt aber gerade die Phantasie, wie ich für den Wireguard Serice den Traffic über Tier 2 outbound erzwinge?

Wenn du auf dem richtigen Interface ein Upstream Gateway gesetzt hast sollte das funktionieren.
Das Problem ist dass Wireguard state-less ist, kann sein dass der nur sein Default Gateway nimmt, also das vom System und nicht von loadbalancing Logik

[alh]

Ich habe genau das gleiche Problem. Eine OPNsense mit 3 WAN-Interfaces. WireGuard via WAN1 (default) funktioniert, via WAN2 und WAN3 nicht. OpenVPN funktioniert hingegen auf allen dreien. Sollten die Antwortpakete nicht automatisch auf das eingehende Interface geroutet werden?

Eine Lösung wäre natürlich, wenn man im PlugIn das Interface pro Server festlegen könnte. Jetzt lauscht WG ja auf allen Interfaces.

[wupperi]

Kann ich bestätigen. Habe in den clients als "peer" einen DDNS Namen zeigend auf die dyn IP des WAN links mit der dynamischen IP gelegt und läuft...

[mimugmail]

Ich glaub das ist dann unabhängig von FreeBSD oder Linux. Hat da einer Mal Lust zu googlen? Oder im #wireguard channel im IRC fragen?

[alh]

Im IRC bestätigen sie im Prinzip das Verhalten.

Wireguard uses the kernel routing table for where to route traffic which is always going to be the default route unless you have other more specific routes.

Könnte man das evtl. so wie OpenVPN im MultiWAN lösen? WireGuard auf das Loopback-Interace setzen und dann mit Port-Forwards arbeiten? Man braucht ja wohl irgendwie ein SNAT, damit die entsprechenden Routen wirksam werden, oder?

[alh]

Michaels Antwort war leider richtig:

The core limitation here is that wg doesn't have a concept of connections, and thus won't try to send replies from the same ip where incoming packets arrived.

Das ist wohl genau das Problem.

[alh]

Hier noch ein paar Vorschläge aus dem IRC:

Either a single wg interface on the server + SNAT, or one wg interface per wan interface + DNAT or network namespaces.

Wobei Wireguard nicht an eine IP/Interface gebunden werden kann, sondern nur an Ports!

[12:22:56]  Just to verify: I cannot even bind wg to listen on a specific interface/ip only, right?
[12:23:39]  No, unfortunately not. That may change at some point, though.

Hier noch ein paar mehr Details:

[12:19:25]  Could you do some policy based stuff for this based on wireguards port perhaps?
[12:21:05]  Unless you want to stick every wan interface into its own network ns (each with its own wg tunnel), you're gonna have to involve netfilter in this somehow.
[12:21:05]  in fact, thats over complicating it...
[12:21:27]  Just set DNAT rule for wireguards port surely?
[12:22:04]  And there are numerous ways of pulling that off, sure, but NAT is by far the simplest to set up, because it leaves most of the work to the conntracking machinery.
[12:23:24]  Either a DNAT rule that maps traffic to different wg interfaces depending on the input interface, or, if you're hell-bent on using only a single wg interface, SNAT + some hackery.

Würde das in OPNsense folgendes bedeuten (für 2 WANs)?

- 2 WG-Instanzen (51821, 51822)?
- Port Forwards auf jedem Interface von 51820 auf 51821/51822
- Firewall-Regel für S-Port 51821 via WAN1
- Firewall-Regel für S-Port 51822 via WAN2

Sollte das so funktionieren?

[mimugmail]

Ich check grad nicht wohin ein Portforward dann gehen soll?

[alh]

Auf dem gleichen Interface von 51820 auf 51821. Braucht man natürlich nur, wenn man gleichzeitig auf allen WANs arbeiten will.

Im OP könnte man das weglassen und einfach eine Policy-Route für die Antwort setzen.

[mimugmail]

Eigentlich bringt Policy route nichts weil das kein Reply to Paket ist und auch selbst initiiert (geht nicht mit PBR).
Das wird noch eklig. Am besten ist eigentlich Default GW Switching aktivieren und immer nur das primäre WAN zu verwenden.

[alh]

In unserem Fall kann man leider die Uploadrate von WAN1 vergessen... Könnte man evtl. mit der Option "fwmark" arbeiten?