WireGuard Site-to-Site: zwei LANs verbinden

Was Sie bauen: WireGuard Site-to-Site über einen VPS

WireGuard Site-to-Site verbindet zwei vollständige LANs miteinander, nicht einen einzelnen Laptop mit einem Netz. In der Mitte steht ein VPS als Hub. Beide Standorte bauen die Verbindung selbst zu ihm auf, und er routet zwischen ihnen. Dieser Aufbau funktioniert auch dann, wenn beide Anschlüsse hinter NAT (Network Address Translation) liegen und keine der beiden Seiten von außen erreichbar ist. Bei DS-Lite, Kabelanschlüssen und Mobilfunk-Routern ist genau das der Normalfall.

Die Technik ist mit drei Konfigurationsdateien erledigt. Die Arbeit steckt an vier anderen Stellen: in AllowedIPs, im Forwarding auf dem Hub, in den Rückrouten auf den beiden Standort-Routern und in der MTU (Maximum Transmission Unit). Dieser Text geht jede Stelle einzeln durch, zusammen mit den Prüfbefehlen, die die Schichten voneinander trennen. Wenn Sie nur ein einzelnes Gerät anbinden wollen, ist ein einzelner Client, der ins heimische LAN routet die einfachere Lösung. Für den Hub setzt dieser Text voraus, dass WireGuard dort schon läuft, so wie in WireGuard auf dem eigenen VPS betreiben beschrieben.

Die Topologie: ein VPS als Hub, zwei Standorte als Peers

Der Adressplan für diese Anleitung:

• Tunnelnetz: 10.99.0.0/24
• Hub, ein VPS mit fester öffentlicher IP-Adresse: 10.99.0.1
• Standort A: WireGuard-Host 10.99.0.2, LAN 192.168.10.0/24
• Standort B: WireGuard-Host 10.99.0.3, LAN 192.168.20.0/24

Warum ein Hub und keine direkte Verbindung? Für den ersten Handshake braucht mindestens eine Seite einen von außen erreichbaren Endpoint. Sitzen beide Standorte hinter NAT, gibt es diese Seite nicht, und der Tunnel kommt nie zustande. Der VPS hat eine feste öffentliche Adresse, also kann er der Punkt sein, zu dem beide Seiten sich verbinden.

Der Preis dafür gehört genannt. Jedes Paket zwischen den Standorten läuft über den VPS, die Latenz ist also die Summe beider Teilstrecken, und der Durchsatz ist durch die Anbindung des VPS begrenzt. Haben beide Seiten feste, erreichbare Adressen, sparen Sie sich den Umweg und koppeln sie direkt, so wie beim Verbinden zweier Server bei verschiedenen Anbietern.

Warum die beiden LANs verschiedene Subnetze brauchen

Zwei Standorte mit demselben Subnetz lassen sich nicht routen. Das ist keine Eigenheit von WireGuard, sondern eine Eigenschaft von IP.

Angenommen, beide Standorte laufen ab Werk auf 192.168.178.0/24, dem Standard einer FRITZ!Box. Ein Rechner in Standort A mit der Adresse 192.168.178.50 soll 192.168.178.60 in Standort B erreichen. Für ihn liegt dieses Ziel im eigenen Subnetz. Er fragt per ARP (Address Resolution Protocol) im lokalen Netz danach und schickt das Paket nie an seinen Router, also auch nie in den Tunnel. Es gibt keine Einstellung auf dem Hub, die das repariert.

Dazu kommt ein zweites Problem auf dem Hub. Derselbe Präfix darf in AllowedIPs nur bei einem Peer stehen. Tragen Sie ihn bei beiden ein, gehört er dem zuletzt konfigurierten Peer, und der andere Standort ist ohne jede Fehlermeldung nicht mehr erreichbar.

Nummerieren Sie also eine Seite um, bevor Sie anfangen. Wählen Sie Bereiche, die Ihnen im Alltag nicht begegnen. 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 und 192.168.178.0/24 sind schlechte Kandidaten, weil sie in jedem zweiten Heimnetz und in vielen Hotel-WLANs stehen.

Schlüssel erzeugen, ohne sie preiszugeben

Jeder der drei Knoten bekommt ein eigenes Schlüsselpaar. Der private Schlüssel verlässt seinen Host nie.

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/host.key'
sudo sh -c 'wg pubkey < /etc/wireguard/host.key > /etc/wireguard/host.pub'
sudo chmod 600 /etc/wireguard/host.key

Führen Sie diesen Block auf dem Hub und auf beiden Standort-Hosts aus. Die drei öffentlichen Schlüssel aus host.pub tauschen Sie danach untereinander aus. Die Zeile mit chmod 600 ist nicht überflüssig: sudo setzt eine eigene umask, deshalb ist die verbreitete Kombination aus umask 077 und sudo tee nicht verlässlich. Eine weltweit lesbare host.key entwertet den gesamten Aufbau.

Die Hub-Konfiguration: ein Peer pro Standort

Auf dem VPS, in /etc/wireguard/wg0.conf:

[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <privater Schlüssel des Hubs>

[Peer]
# Standort A
PublicKey = <öffentlicher Schlüssel Standort A>
AllowedIPs = 10.99.0.2/32, 192.168.10.0/24

[Peer]
# Standort B
PublicKey = <öffentlicher Schlüssel Standort B>
AllowedIPs = 10.99.0.3/32, 192.168.20.0/24

Der Hub hat keinen Endpoint Eintrag, weil er die Verbindung nie selbst aufbaut. Er wartet auf UDP-Port 51820. Jeder Peer-Block trägt zwei Präfixe: die Tunneladresse des Standorts als /32 und das LAN hinter diesem Standort. Setzen Sie SaveConfig nicht, sonst überschreibt wg-quick down diese Datei mit dem Laufzeitzustand. Die Datei gehört auf Modus 600, sonst warnt der Start, dass sie für alle lesbar ist.

AllowedIPs ist die Routingtabelle des Tunnels

Hier scheitern die meisten Standortkopplungen. AllowedIPs erledigt zwei Aufgaben gleichzeitig, und beide gelten immer.

Nach außen ist es eine Routingtabelle. Ein Paket, dessen Zieladresse in den AllowedIPs eines Peers steht, wird für diesen Peer verschlüsselt. Steht das Ziel bei keinem Peer, gibt es keinen Tunnel dafür, und der Kernel schickt das Paket auf die normale Route, also meist ins Internet.

Nach innen ist es eine Zugriffsliste. Ein entschlüsseltes Paket, dessen Quelladresse nicht in den AllowedIPs desselben Peers steht, wird verworfen. Ohne Protokolleintrag und ohne ICMP-Antwort. Genau daher kommt das Symptom "Handshake steht, aber nichts geht": Eine Seite sendet korrekt, und die Gegenstelle wirft das Paket weg, weil die Quelle dort nicht eingetragen ist. Die Mechanik dahinter heißt Cryptokey Routing und ist in der festen Zuordnung von Schlüsseln zu IP-Bereichen im Detail beschrieben.

Daraus folgt die Regel für zwei Standorte: Jedes Netz muss auf jeder Seite eingetragen sein, die es weiterleiten soll. Standort A trägt beim Hub-Peer das LAN von Standort B ein. Der Hub trägt beim Peer A das LAN von A ein und beim Peer B das LAN von B. Fehlt ein einziger dieser Einträge, funktioniert der Weg in eine Richtung und in die andere nicht.

Die Konfiguration an den beiden Standorten

Standort A, /etc/wireguard/wg0.conf:

[Interface]
Address = 10.99.0.2/24
PrivateKey = <privater Schlüssel Standort A>

[Peer]
PublicKey = <öffentlicher Schlüssel des Hubs>
Endpoint = hub.example.com:51820
AllowedIPs = 10.99.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Standort B ist das Spiegelbild davon:

[Interface]
Address = 10.99.0.3/24
PrivateKey = <privater Schlüssel Standort B>

[Peer]
PublicKey = <öffentlicher Schlüssel des Hubs>
Endpoint = hub.example.com:51820
AllowedIPs = 10.99.0.0/24, 192.168.10.0/24
PersistentKeepalive = 25

Ein ListenPort ist an den Standorten nicht nötig, weil beide Seiten die Verbindung selbst aufbauen. Beide listen das Tunnelnetz und das jeweils andere LAN, aber nicht ihr eigenes. Ein Standort, der sein eigenes LAN in AllowedIPs schreibt, bringt wg-quick dazu, eine Route für ein bereits lokal vorhandenes Netz zu setzen, und der Start bricht mit einem RTNETLINK-Fehler ab.

0.0.0.0/0 gehört hier nicht hinein. Das wäre ein Full Tunnel, bei dem der gesamte Internetverkehr des Standorts über den VPS liefe. Für eine Standortkopplung wollen Sie einen Split Tunnel: genau die Präfixe der Gegenseite und sonst nichts.

sudo systemctl enable --now wg-quick@wg0
sudo wg show

enable --now ist der wichtige Teil. Ein von Hand gestartetes wg-quick up wg0 ist nach dem nächsten Neustart weg, und Kernel-Updates bedeuten Neustarts.

Forwarding auf dem Hub einschalten

Ein Linux-Server leitet Pakete, die nicht an ihn selbst gerichtet sind, standardmäßig nicht weiter. Solange net.ipv4.ip_forward auf 0 steht, verwirft der Kernel jedes Paket von Standort A nach Standort B, und zwar direkt auf dem Hub.

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Die letzte Zeile muss net.ipv4.ip_forward = 1 ausgeben. Ein sysctl -w auf der Kommandozeile wirkt bis zum nächsten Neustart und danach nicht mehr, deshalb die Datei unter /etc/sysctl.d/. Dieselbe Einstellung brauchen auch die WireGuard-Hosts an den Standorten, sobald sie Pakete in ihr LAN weitergeben sollen.

Die Firewall-Regel, die fast alle vergessen: wg0 nach wg0

Auf dem Hub kommt der Verkehr von Standort A auf wg0 an und verlässt den Hub wieder auf wg0. Eine übliche Forward-Kette mit policy drop erlaubt genau diesen Weg nicht, weil sie nur den Fall Tunnel nach Internet abdeckt.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "wg0" accept
  }
}

flush ruleset löscht das bestehende Regelwerk. Auf einem Host, auf dem ufw oder Docker eigene Regeln verwalten, dürfen Sie diese Datei so nicht einspielen. Aktiviert wird sie mit sudo systemctl enable --now nftables, und zwar mit einer zweiten offenen SSH-Sitzung, weil ein Tippfehler in der SSH-Regel zusammen mit policy drop Sie aus Ihrem eigenen Server aussperrt.

Beachten Sie, was hier fehlt: eine NAT-Regel. Der Hub soll zwischen den Standorten routen, nicht maskieren. Ein masquerade auf dem Hub lässt den Aufbau auf den ersten Blick funktionieren, weil damit die Rückrouten unnötig werden. Der Preis ist hoch: Jedes Paket kommt in Standort B mit der Absenderadresse 10.99.0.1 an. Sie können am Ziel dann weder nach Quelladresse filtern noch sinnvoll protokollieren, und jeder Dienst sieht statt zweier Standorte nur einen einzigen Client.

Warum der Rückweg eine Route auf dem Standort-Router braucht

An diesem Punkt ist ein technisch fertiger Tunnel trotzdem unbenutzbar.

Läuft WireGuard am Standort nicht auf dem Router selbst, sondern auf einem separaten Linux-Host im LAN, dann wissen die übrigen Geräte im Netz nichts von dem Tunnel. Ein PC in Standort A mit der Adresse 192.168.10.50 schickt ein Paket an 192.168.20.50. Das Ziel liegt nicht im eigenen Subnetz, also geht das Paket an das Standard-Gateway, den Router 192.168.10.1. Der Router kennt 192.168.20.0/24 nicht und schickt es über seine Default-Route ins Internet, wo es verworfen wird. Der Tunnel wird dabei nie berührt.

Deshalb braucht jeder der beiden Router eine statische Route:

• Router in Standort A: 192.168.20.0/24 über 192.168.10.2, den WireGuard-Host
• Router in Standort B: 192.168.10.0/24 über 192.168.20.2

Beide Einträge sind nötig. Fehlt nur der in Standort B, kommt Ihre Anfrage an, die Antwort findet aber nicht zurück, und Sie sehen eine Zeitüberschreitung, die wie ein kaputter Tunnel aussieht. Eine FRITZ!Box kann solche IPv4-Routen in den Netzwerkeinstellungen aufnehmen, OPNsense und OpenWrt ohnehin. Router ohne statische Routen lassen Ihnen eine Alternative: WireGuard direkt auf dem Router betreiben. Dann entfällt die Zusatzroute, weil der Router das entfernte Netz selbst kennt.

Zwei weitere Dinge müssen auf dem WireGuard-Host am Standort stimmen. net.ipv4.ip_forward muss auch dort 1 sein, sonst nimmt er die Pakete aus dem Tunnel an und gibt sie nicht ins LAN weiter. Und wenn sudo tcpdump -ni wg0 zeigt, dass Pakete ankommen, sie aber auf der LAN-Schnittstelle nie auftauchen, prüfen Sie sysctl net.ipv4.conf.all.rp_filter. Der Wert 1 bedeutet strikte Rückpfadprüfung: Der Kernel verwirft ein Paket, wenn die Antwort an dessen Quelladresse über eine andere Schnittstelle hinausgehen würde.

Wenn ein Standort hinter NAT sitzt: PersistentKeepalive

NAT-Router merken sich ausgehende UDP-Verbindungen nur für kurze Zeit. Fließt kein Paket, verfällt der Eintrag, und der Hub erreicht den Standort nicht mehr. Seine Pakete landen bei einem Router, der nicht mehr weiß, an welches interne Gerät sie gehören. Der Tunnel wirkt dann in einer Richtung tot, bis der Standort von sich aus etwas sendet.

PersistentKeepalive = 25 schickt alle 25 Sekunden ein leeres Paket und hält den NAT-Eintrag offen. Die Einstellung gehört auf jede Seite hinter NAT, hier also auf beide Standorte, nicht auf den Hub mit der öffentlichen Adresse. Der Wert 25 ist die übliche Wahl, weil er unter den kurzen Zeitüberschreitungen der meisten NAT-Tabellen liegt.

MTU: rechnen, bevor Sie WireGuard verdächtigen

Typisches Bild: SSH läuft, Ping läuft, aber große HTTP-Antworten oder SMB-Übertragungen bleiben stehen. Das ist fast immer die MTU und fast nie WireGuard.

WireGuard steckt jedes Paket in ein UDP-Paket. Über IPv4 kostet das 60 Byte: 20 Byte IP-Header, 8 Byte UDP-Header, 16 Byte WireGuard-Header und 16 Byte Poly1305-Prüfsumme. Über IPv6 sind es 80 Byte, weil der äußere Header größer ist. Die folgenden Werte sind gerechnet, nicht gemessen:

[
  {
    "label": "IPv4-Underlay, Pfad 1500",
    "overhead_bytes": 60,
    "tunnel_mtu": 1440
  },
  {
    "label": "IPv6-Underlay, Pfad 1500",
    "overhead_bytes": 80,
    "tunnel_mtu": 1420
  },
  {
    "label": "PPPoE, Pfad 1492",
    "overhead_bytes": 60,
    "tunnel_mtu": 1432
  },
  {
    "label": "DS-Lite, Pfad 1460",
    "overhead_bytes": 60,
    "tunnel_mtu": 1400
  }
]

Auf einem Pfad mit 1500 Byte bleiben nach Abzug von 60 Byte genau 1440 Byte für den Tunnel übrig. wg-quick rechnet vorsichtiger und zieht 80 Byte ab, landet also bei 1420 Byte und ist damit auch über IPv6 als Underlay auf der sicheren Seite. Kritisch wird es, wenn der Pfad selbst kleiner ist. Ein klassischer PPPoE-Anschluss liefert 1492 Byte, und bei DS-Lite bleiben nach dem IPv6-Tunnel des Anbieters rund 1460 Byte übrig, was die nutzbare Tunnel-MTU auf 1400 Byte drückt.

Messen Sie den Pfad, statt zu raten. Der folgende Befehl schickt ein Paket mit gesetztem DF-Bit (Don't Fragment), das unterwegs also nicht zerteilt werden darf:

ping -M do -s 1372 -c 3 192.168.20.50

-s gibt die Nutzlast an, dazu kommen 28 Byte für ICMP- und IP-Header, 1372 plus 28 ergibt also 1400 Byte. Geht der Ping durch, erhöhen Sie schrittweise, bis er scheitert. Meldet Ihr eigener Host Message too long, ist die lokale Schnittstelle kleiner eingestellt als das Testpaket. Bleibt der Ping stattdessen einfach ohne Antwort, wird das Paket unterwegs verworfen, ohne dass die zugehörige ICMP-Meldung zurückkommt. Die gefundene Größe tragen Sie als MTU = im [Interface] Abschnitt beider Standorte ein.

Für TCP gibt es eine Abkürzung, die auch bei unbekannter MTU eines Teilstücks hilft. Diese Regel in der Forward-Kette des Hubs passt die maximale Segmentgröße an die tatsächliche Route an:

tcp flags syn tcp option maxseg size set rt mtu

Sie wirkt nur auf TCP. UDP-Protokolle bleiben auf eine korrekt gesetzte MTU angewiesen.

Prüfen, Schritt für Schritt

Arbeiten Sie von innen nach außen, sonst suchen Sie den Fehler in der falschen Schicht. Jeder Schritt setzt den vorigen voraus.

1. Auf dem Hub: sudo wg show. Jeder Peer muss eine aktuelle Zeile latest handshake zeigen. Ein Peer ohne diese Zeile bedeutet, dass nichts ankommt oder nichts angenommen wird.
2. Auf dem WireGuard-Host in Standort A: ping -c 3 10.99.0.3. Das prüft ausschließlich den Tunnel und das Tunnelnetz.
3. Auf demselben Host: ping -c 3 192.168.20.1. Antwortet das, stimmen AllowedIPs und Forwarding auf allen drei Knoten.
4. Auf demselben Host: ip route get 192.168.20.50. In der Ausgabe muss dev wg0 stehen. Erscheint dort die LAN- oder die Internet-Schnittstelle, fehlt der Präfix in AllowedIPs.
5. Von einem gewöhnlichen PC in Standort A: derselbe Ping. Klappt Schritt 3, aber dieser nicht, fehlt die statische Route auf dem Router.
6. Wenn unklar ist, wo das Paket verschwindet: sudo tcpdump -ni wg0 icmp auf dem Hub, während Sie pingen. Sehen Sie nur die Anfrage und keine Antwort, liegt der Fehler hinter dem Hub auf der Zielseite.

Fehlerbilder und was sie bedeuten

Kein Handshake. Im Protokoll des Standort-Hosts steht eine Zeile wie Handshake for peer 1 (203.0.113.10:51820) did not complete after 5 seconds, retrying (try 2). Prüfen Sie in dieser Reihenfolge, ob UDP 51820 auf dem VPS offen ist, und zwar auch in der separaten Netzwerk-Firewall im Kundenmenü Ihres Anbieters, ob Endpoint und Port stimmen und ob die Schlüssel vertauscht sind. Im [Peer] Block des Standorts muss der öffentliche Schlüssel des Hubs stehen, nicht dessen privater und nicht der eigene.

Handshake steht, der Ping ins andere LAN bleibt ohne Antwort. Das ist fast immer ein fehlender Präfix in AllowedIPs. Gehen Sie alle drei Konfigurationen durch und prüfen Sie jede Richtung einzeln.

Der Hub sieht die Pakete, sie kommen aber nicht weiter. tcpdump auf wg0 zeigt die Anfrage, am Ziel kommt nichts an. Dann fehlt ip_forward auf dem Hub, oder die Regel iifname "wg0" oifname "wg0" accept ist nicht aktiv.

Es funktioniert nur vom WireGuard-Host aus, nicht von den anderen Geräten. Die statische Route auf dem Standort-Router fehlt, oder sie zeigt auf die falsche Adresse.

Die Namensauflösung bricht weg, sobald der Tunnel steht. Ein DNS = Eintrag in der Standort-Konfiguration lässt wg-quick den Resolver des ganzen Hosts umstellen. Ist der eingetragene Server über den Tunnel nicht erreichbar, löst danach gar nichts mehr auf, und curl meldet Could not resolve host. Für eine reine Standortkopplung brauchen Sie die Zeile meistens nicht. Wollen Sie Namen aus dem anderen LAN auflösen, arbeiten Sie die DNS-Probleme im WireGuard-Tunnel gezielt ab.

Ein Standort ist nach einer Ruhephase nicht erreichbar. Der NAT-Eintrag im Router ist verfallen. Setzen Sie PersistentKeepalive = 25 auf der Seite hinter NAT.

Betrieb: dritter Standort, Schlüssel, Ausfall

Ein weiterer Standort bedeutet einen zusätzlichen [Peer] Block auf dem Hub, eine weitere /32 im Tunnelnetz und ein weiteres LAN-Präfix in den AllowedIPs aller anderen Standorte. Dieser letzte Teil wächst schnell, und von Hand gepflegt entstehen dabei leicht doppelte Präfixe. Ab etwa fünf Standorten sollten Sie die Konfigurationen generieren statt tippen. Den Hub müssen Sie dafür nicht neu starten: einen Peer im laufenden Betrieb aufnehmen erspart allen übrigen Standorten den Abbruch ihrer Verbindung.

/etc/wireguard ist der Server. Sichern Sie das Verzeichnis mit sudo tar czf wg-backup.tgz -C /etc wireguard, legen Sie das Archiv auf Modus 600 und bewahren Sie es nicht auf demselben Host auf. Der Hub bleibt ein einzelner Ausfallpunkt, denn WireGuard kennt kein Clustering. Redundanz heißt hier ein zweiter VPS mit eigenen Schlüsseln und einem zweiten Peer-Block an jedem Standort. Die Schlüsselrotation bleibt Handarbeit, also notieren Sie, welcher Schlüssel zu welchem Standort gehört und wie Sie ihn zurückziehen.

FAQ

Warum erreiche ich das andere LAN nicht, obwohl der Handshake steht?

In den meisten Fällen fehlt ein Präfix in AllowedIPs. Das LAN von Standort B muss auf dem Hub im Peer-Block von B stehen und zusätzlich bei Standort A im Peer-Block des Hubs. Fehlt einer der beiden Einträge, verwirft die Gegenseite das entschlüsselte Paket ohne Meldung. Prüfen Sie mit ip route get <Zieladresse>, ob die Route überhaupt auf wg0 zeigt, und mit sudo tcpdump -ni wg0 icmp auf dem Hub, wie weit das Paket kommt. Kommt es auf dem Hub an und geht nicht weiter, fehlt dort net.ipv4.ip_forward = 1 oder die Forward-Regel von wg0 nach wg0.

Müssen die Subnetze an beiden Standorten unterschiedlich sein?

Ja. Haben beide Standorte 192.168.178.0/24, hält jeder Rechner die Gegenstelle für einen Nachbarn im eigenen Netz, fragt per ARP nach ihr und schickt das Paket nie an seinen Router. Der Tunnel wird nie benutzt. Dazu kommt, dass derselbe Präfix auf dem Hub nur in einem einzigen Peer-Block stehen darf. Nummerieren Sie eine Seite um, zum Beispiel auf 192.168.20.0/24, und meiden Sie die verbreiteten Standardbereiche der Heimrouter.

Brauche ich PersistentKeepalive auf beiden Seiten?

Auf jeder Seite, die hinter NAT sitzt, in diesem Aufbau also auf beiden Standorten. Der Hub mit öffentlicher IP-Adresse braucht die Einstellung nicht. Der Wert 25 Sekunden ist üblich, weil er unter den kurzen Zeitüberschreitungen der meisten NAT-Tabellen liegt. Ohne Keepalive funktioniert der Tunnel, solange der Standort selbst sendet, und ist nach längerer Ruhe von außen nicht mehr erreichbar.

Welche MTU soll ich für eine Site-to-Site-Verbindung setzen?

Lassen Sie zuerst den Wert stehen, den wg-quick selbst setzt, auf einem 1500er Pfad sind das 1420 Byte. Hängen große Übertragungen, messen Sie den Pfad mit ping -M do -s <Nutzlast> und erhöhen Sie schrittweise, bis der Ping scheitert. Bei PPPoE- und DS-Lite-Anschlüssen ist der Pfad von vornherein kleiner als 1500 Byte, dort sind Werte um 1400 realistisch. Für TCP hilft zusätzlich eine MSS-Clamping-Regel in der Forward-Kette des Hubs, weil sie die Segmentgröße an die tatsächliche Route anpasst.