OpenVPN Site-To-Site über MultiWan auf Clientseite
-
Servus Zusammen,
da mich die Endian-Firewall entgültig los werden will hier erstmal ein: Servus Community!
Ich bin schon ganz gut am Testerfahrungen Sammeln mit der pfsense, und versuche eine etwas kompliziertere Aufgabenstellung zu lösen, bisher leider ohne (kompletten) Erfolg.
Am Standort A sind leider nur 2 DSL-Leitungen vorhanden, Standort B ist im Rechenzentrum mit guter anbindung.
im Idealfall sollen von A beide Leitungen gebündelt/loadbalanced über OpenVPN genutzt werden, wenn Host A was von Host B will.
Ist das überhaupt so möglich?
Zielstellung: 10.93.10.0/24 <-> 10.93.3.0/24
Falls das so nicht geht, könnte auch über Aufteilung der Netze an beiden Standorten der Traffic halbwegs aufgeteilt werden. Als Grundlage diente mir https://forum.pfsense.org/index.php?topic=12888.0
Derzeitige aufteilung
auf pfsense bei B laufen zwei OpenVPN-Server-instanzen, und bei A zwei Client-Instanzen, die gegeneinander verbunden sind.
Server Ovpn1: 10.93.10.0/25 -> 10.93.3.0/24
Server Ovpn2: 10.93.10.128/25 -> 10.93.3.0/24Client Ovpn1: 10.93.3.0/25 -> 10.93.10.0/24
Client Ovpn2: 10.93.3.128/25 -> 10.93.10.0/24Das läuft auch testweise schon soweit bis auf den Fehler, dass ich von den unteren Teilnetz von Host A nur auf das untere Teilnetz von Host B übertragen kann. Ebenso funktioniert oberes Teilnetz zu oberes Teilnetz aber nicht von 10.93.10.0/25 auf 10.93.10.128/25 (z.B. 10.93.10.1 auf 10.93.10.181)
die beiden pfsenses selbst erreichen alle adressen. nur von den hosts hinter den pfsenses komm ich nur ins jeweils untere Teilnetz,
OpenvpnServer 1 Custom options
route 10.93.3.0 255.255.255.128; push "route 10.93.10.0 255.255.255.128";
OpenvpnServer 2 Custom options
push "route 10.93.10.128 255.255.255.128"; route 10.93.3.128 255.255.255.128
OpenvpnClient 1 Client Specific Overrides
iroute 10.93.3.0 255.255.255.128
OpenvpnClient 2 Client Specific Overrides
iroute 10.93.3.128 255.255.255.128
Warum gehen die Pakete nicht gegenseitig in die jeweils anderen netze?
LG Freisei
-
Änderung beider Client Specific Overrides brachten erfolg:
iroute 10.93.3.0 255.255.255.0
d.h. jetzt wären wir wieder bei
im Idealfall sollen von A beide Leitungen gebündelt/loadbalanced über OpenVPN genutzt werden, wenn Host A was von Host B will.
Ist das überhaupt so möglich?
-
Hallo erstmal und willkommen :)
iroute 10.93.3.0 255.255.255.0
Huh? Eine gepushte iroute? Wofür? Dein Problem ist eigentlich ganz anders gelagert: Du kannst die gleiche Route nicht über zwei Verbindungen pushen. Das ist einfach die Logik von Routing per se. Wenn ich nicht weiß wo ich das Paket hinschicken soll weil ich 2 gleiche Routen habe, dann hab ich ein Problem :)
Ergo bleiben dir drei sinnvolle Möglichkeiten.
Variante 1)
Du legst 2 Site2Site OVPN Tunnel an (wie dus wohl jetzt gemacht hast) OHNE dass du die Routen auf beiden Seiten angibst. Damit hast du dann primär erstmal nur die beiden Transfernetze der OVPN Tunnel in den Routingtabellen auf beiden Seiten. Nennen wir sie mal 192.168.100/200.0/24 wobei .1 jeweils auf Seite A und .2 auf Seite B ist (einfach exemplarisch).
Ohne Routen zu den Netzen von A und B stehen jetzt erstmal nur die Tunnel sinnbefreit in der Gegend herum. Sobald diese aber laufen, wird auf beiden Seiten jeweils das OVPNS bzw. OVPNCx interface unter "Interfaces/Assignments" real zugewiesen und aktiviert (keine weiteren Einstellungen machen, nur zuweisen und aktivieren - und auf Wunsch VPN1 und VPN2 benennen).
Ist das auf beiden Seiten erledigt und der Tunnel sicherheitshalber nochmal resettet (neu aufbauen) wird nochmal getestet ob A<->B via Tunnel anpingen kann (also die Tunnelendpunkte .1 und .2 der beiden Tunnel).Anschließend solltest du - da du jetzt die VPN Interfaces dem System zugewiesen hast unter System/Routing plötzlich neue Gateways haben - nämlich deine Tunnel Gateways.
Die beiden kannst du nun in eine Loadbalancing oder Failover Gatewaygruppe packen, diese dann in Regeln auf deinem LAN Interface einbinden und damit dann den Traffic routen -> PBR (Policy based routing). Einfach eine Regel VON "LAN net" nach "LAN_der_anderen_Seite" via (Adv. Settings öffnen, GW auswählen). Damit wird dann jeder Traffic der darauf matched durch die Tunnel gezwungen. Bei einem LB Gateway dann entsprechend mal durch 1 und mal durch 2. Auf der anderen Seite gibts natürlich dann Bedarf das mit den Regeln genauso zu machen.Variante 2)
Routing Protokoll. Vorbereitung Siehe 1) und dann statt einer Gateway Gruppe etc. statt dessen ein Routing Paket wie FRR, Quagga oder RIP nehmen (FRR müsste aktuell sein) und OSPF machen. OSPF auf beiden Seiten für die jeweils andere Netzseite dann eintragen und beide VPN Gateways als gleichberechtigt auswählen, dann sollte das via OSPF schön round-robin durch den Tunnel geloadbalanced werden. Fällt ein Tunnel aus, fällt dessen Gateway ebenso aus und damit fällt es aus einer GW Gruppe wie auch aus der OSPF Gewichtung raus.Variante 3)
Du schreibst dass die eine Seite entsprechend dick angebunden ist, so dass es da eigentlich keine 2 Leitungen gibt (richtig?) sondern nur eine. Als reines Failover würde ich dann eher auf OpenVPNs eigene Funktion setzen (Achtung: nur Failover hier):
- Server auf der schwachen Seite mit 2 Anschlüssen aufmachen, aber NICHT 2 Server an 2 WANs binden, sondern EINEN an localhost!
- Forwardings auf WAN1 und WAN2 einrichten auf den OpenVPN Server auf localhost
- Funktionstest von anderer Seite als Client gegen VPN Server mit IP von WAN1, dann mal zum Test mit WAN2 IP. Wenn beide gehen:
- OpenVPN Client konfigurieren mit WAN1, in advanced settings Feld noch ein Eintrag mit "remote <ip_von_wan2>;" reinpacken. Client Konfiguration dann mal ansehen (Filesystem /var/etc/openvpn…), da müssten nun 2 remote Einträge enthalten sein
Damit verhält sich die "starke Seite" dann so:
- baut Verbindung zu WAN1 auf
- wenn WAN1 tot, timeout und neuer Versuch, bei timeout bei Verbindungsaufbau dann Schwenk zu zweitem Remote Eintrag und Aufbau via WAN2
Somit automatisches Failover (mit etwas Latenz) bei Leitungsausfall WAN1, allerdings nur semiautomatisch, da ein Fallback auf WAN1 nicht automatisch geschieht, das würde dann bei Neueinwahl aber automatisch passieren.
Mit der Methode ist es auch möglich bspw. Roadwarrior zu balancen über beide Leitungen wenn man der Client Konfiguration für die Leute unterwegs zusätzlich zum zweiten remote Eintrag noch ein "remote-random;" mit einwirft. Dann baut der Client zufällig eine Verbindung zu WAN1 oder 2 auf, je nachdem was die Münze sagt, mit der Masse sollte man aber eine halbwegs gleiche Verteilung dann über die Leitungen erreichen.
Ich hoffe das hilft dir mal weiter - der 3)er Punkt dürfte da eher ein wenig OT bzw. nicht so gewünscht sein, ich würde versuchen 2) mit FRR zu implementieren, da das Routing per OSPF IMHO sauberer sein dürfte als das Gateway Balancing via PBRs
Grüße
jens</ip_von_wan2> -
Ja geil! Hört sich sehr vielversprechend an, ich komm aber erst am WE dazu das zu testen. Vielen Dank schonmal für deine Ausführungen!
-
Servus,
ich bin jetzt mal beim probieren von Variante 1), da sich das für mich am passendsten anhört.
Du legst 2 Site2Site OVPN Tunnel an (wie dus wohl jetzt gemacht hast) OHNE dass du die Routen auf beiden Seiten angibst. Damit hast du dann primär erstmal nur die beiden Transfernetze der OVPN Tunnel in den Routingtabellen auf beiden Seiten. Nennen wir sie mal 192.168.100/200.0/24 wobei .1 jeweils auf Seite A und .2 auf Seite B ist (einfach exemplarisch).
läuft, die können sich auch gegenseitig die Endpunkte pingen.
Hier mal die Logs, damit die IPs und Hostnamen klar sind.
Ovpn1
[2.4.1-RELEASE][root@server2.rz2.xp8.de]/root: ping 10.10.51.2 PING 10.10.51.2 (10.10.51.2): 56 data bytes 64 bytes from 10.10.51.2: icmp_seq=0 ttl=64 time=30.320 ms
[2.4.1-RELEASE][root@pfxp8.xp8.local]/root: ping 10.10.51.1 PING 10.10.51.1 (10.10.51.1): 56 data bytes 64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=33.897 ms
Ovpn2
[2.4.1-RELEASE][root@server2.rz2.xp8.de]/root: ping 10.10.52.2 PING 10.10.52.2 (10.10.52.2): 56 data bytes 64 bytes from 10.10.52.2: icmp_seq=0 ttl=64 time=30.395 ms
[2.4.1-RELEASE][root@pfxp8.xp8.local]/root: ping 10.10.52.1 PING 10.10.52.1 (10.10.52.1): 56 data bytes 64 bytes from 10.10.52.1: icmp_seq=0 ttl=64 time=30.485 ms
server2.rz2.xp8.de hat die 10.10.10.254/24
pfxp8.xp8.local hat die 192.168.99.254/24Ohne Routen zu den Netzen von A und B stehen jetzt erstmal nur die Tunnel sinnbefreit in der Gegend herum. Sobald diese aber laufen, wird auf beiden Seiten jeweils das OVPNS bzw. OVPNCx interface unter "Interfaces/Assignments" real zugewiesen und aktiviert (keine weiteren Einstellungen machen, nur zuweisen und aktivieren - und auf Wunsch VPN1 und VPN2 benennen).
auch erledigt. Die Gatways erscheinen (je seite zweimal einmal als IPv6 und IPv4)
Ist das auf beiden Seiten erledigt und der Tunnel sicherheitshalber nochmal resettet (neu aufbauen) wird nochmal getestet ob A<->B via Tunnel anpingen kann (also die Tunnelendpunkte .1 und .2 der beiden Tunnel).
pingen geht immer noch. Nach Neuaufbau stehen bei System/Routing/Gateways bei Gateway+Monitor-IP der lokale Ovpn-Endpoint des Tunnel-Netzes. (also bei z.B. server2.rz2.xp8.de die 10.10.51.1)
Die beiden kannst du nun in eine Loadbalancing oder Failover Gatewaygruppe packen, diese dann in Regeln auf deinem LAN Interface einbinden und damit dann den Traffic routen -> PBR (Policy based routing). Einfach eine Regel VON "LAN net" nach "LAN_der_anderen_Seite" via (Adv. Settings öffnen, GW auswählen). Damit wird dann jeder Traffic der darauf matched durch die Tunnel gezwungen. Bei einem LB Gateway dann entsprechend mal durch 1 und mal durch 2\. Auf der anderen Seite gibts natürlich dann Bedarf das mit den Regeln genauso zu machen.
Ich glaub ich fehlts noch irgendwo. Ich habs mal mit und mal ohne GW-Group probiert (bei ohne in den FW-Rules also z.B. die OVPN1 als Gateway genommen), komm aber nicht durch den tunnel.
Wie kann ich feststellen, wie weit die Pakete kommen?
[2.4.1-RELEASE][root@server2.rz2.xp8.de]/root: route show 192.168.99.11 route to: 192.168.99.11 destination: default mask: default gateway: static.88-198-231-201.clients.your-server.de fib: 0 interface: vtnet1 flags: <up,gateway,done,static> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0</up,gateway,done,static>
[2.4.1-RELEASE][root@server2.rz2.xp8.de]/root: ssh 192.168.99.11 ssh: connect to host 192.168.99.11 port 22: Operation timed out
So wie das aussieht laufen die pakete auf dem default-GW raus…
Bei den Firewall-Rules erscheint ja auch das zugewiesene Interface. Muss da was erlaubt werden, oder kann da eigentlich gar nichts drüberlaufen?
LG Freisei
-
Da muss auf dem LAN eine entsprechende Firewall Regel erstellt werden, um den Traffic vom LAN zur anderen Seite via OpenVPN zu routen. Dazu in der Regel dann unter Advanced das entsprechende Gateway auswählen, dann sollte der Traffic auch via ovpnX Interface raus geroutet werden.
-
Servus,
das entspricht ja quasi dem, oder?
diese dann in Regeln auf deinem LAN Interface einbinden und damit dann den Traffic routen -> PBR (Policy based routing). Einfach eine Regel VON "LAN net" nach "LAN_der_anderen_Seite" via (Adv. Settings öffnen, GW auswählen). Damit wird dann jeder Traffic der darauf matched durch die Tunnel gezwungen.
Ist auch so gemacht, funktioniert nur leider nicht. Ich kann per tcpdump. auf dem vm-Host sehen, wie die Ping-Pakete durch das normale WAN-Gateway rausgehen und irgendwann vom Rechenzentrums-Router verworfen werden, da private subnetze.
Diese PBR-Regel greift so leider nicht. Ich verstehe auch nicht warum, da diese ja ziemlich eindeutig ist. Kann es sein, dass sich "LAN" da nicht zuständig fühlt, da weder ein Interface eine IP in diesen Subnetz hat, noch eine "normale" routing-Regel vorhanden ist, die das ziel-subnetz beschreibt?
Wie kann ich feststellen, wie weit die Pakete kommen?
LG, Freisei