Serveradresse OpenVPN
-
Hallo,
ja genau da in der Client Konfig. Das ";" ist nur als Trennzeichen bei mehreren Einträgen erforderlich, stört aber vermutlich auch nicht.
Am Server kannst du ein Port Forwarding von der einer auf die andere IP einrichten.
Ich lasse den VPN Server gerne auf eine interne IP oder auf localhost lauschen und richte am WAN nur Weiterleitungen dahin ein.Grüße
-
Meinst Du wie in dieser Anleitung:
https://www.joerg-leuschner.de/pfsense/pfsense-openvpn-server-mit-multiwan/#more-676
Christian
-
Nicht wirklich. Die Anleitung beschreibt die Einrichtung eines Access Servers unter Nutzung von DynDNS auf einer Gateway Group.
Soweit ich deine Anforderung verstanden, habe trifft nichts davon auf deinen Aufbau zu.Eine Gateway Group könntest du natürlich für deine beiden WANs einrichten, würde Sinn machen. Dann könnte der VPN Server ebenfalls auf der GW Group lauschen anstatt der Port Weiterleitungen.
Doch wenn es ausschließlich um die Site-to-Site VPN geht, kann auch der Server auf irgendeinem Interface lauschen und die Anfragen werden von beiden WAN-IP dahin geleitet, und der Client wird mit zwei Remote-Einträgen konfiguriert, wie von Jens beschrieben. -
Was muss ich dann für das 2 Wan in der Pfsene am Standort A Eintragen.
Jetzt ist er ja schon am laufen:
1. Standort A, openVPN Server mit Interface A
2. Standort B, openVPN Client mit Server feste IP auf Interface A am Standort A
-> das ist am Laufen
Änderungen:
Eintrag am Standort B: remote <ip>1194 udp; (feste IP Interface B am Standort A)
Frage:
Wie routing von Interface B auf Interface A am Standort A?</ip> -
Ein normales Portforwarding von der 2. auf die 1. WAN IP.
Firewall > NAT > Port Forwarding.
Eine neue Regel hinzufügen.
Interface: WAN B
Protokoll: UDP
Destination: WAN B address
Dest. Port range: OpenVPN
Redirect target IP: WAN A IP
Redirect target port: OpenVPNDer Client ist schon in Ordnung.
-
Hallo,
habe die Umleitung gerade ausprobiert und habe ein ganz komisches Verhalten. Am Standort A (mit den 2 WAN Leitungen ist die Leitung up, am Standort B (Client ist die Leitung down. Habe Bilder angefügt, zur Erklärung Bild 001-003 ist Standort A (Server) Bild 004-006 ist Standort B Client.
Zur Erklärung, mein Open VPN läuft nicht auf UDP 1194 sondern 24100.
-
Hallo,
den Source Port darfst du in der Weiterleitung nicht definieren, der muss any sein.
Damit beschränkst du ihn ja auf 24100, was wohl selten zutrifft.Du erwartest dir aber nicht, dass sich der Client mit beiden Adressen gleichzeitig verbindet? Er kann sich bei einem Site-to-Site Server nur mit einer der beiden verbinden.
Grüße
-
Wenn ich den Source Port nicht auf 24100 beschränke, werden doch alle Ports die über dieses WAN kommen über diese Umleitung geroutet.
Der Client soll sich nur bei Ausfall der WAN-Leitung A beim Server auf der WAN-Leitung B verbinden. Das ganze soll ein Backup sein. -
Nein, nur der Zielport ist entscheidend. Das ist der, auf den sich der Client verbinden möchte. Der ist hier 24100 und dieser wird weitergeleitet, wenn er bei Destination Port eingetragen ist (ist er ja), nur dieser.
Der Quellport ist der ausgehende Port am Client, der ist dynamisch und kann alles Mögliche sein. Der wird meist vom Betriebssystem der Anwendung zugeteilt. Nur ganz wenige Netzwerk-Anwendungen bestehen auf einen bestimmten Quellport, für diese gibt es die Option, den Port anzugeben. -
https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN
Dort ist beschrieben wie das gebaut wird vom Prinzip her. Der Standort mit Multi-WAN bekommt den Server auf localhost, WAN1 und WAN2 bekommen ein Port Forwarding des genutzten Ports udp/1194 (default) auf localhost/1194. Damit ist es egal ob auf WAN1 oder 2 angefragt wird, es wird immer intern mit dem gleichen Server verbunden.
Die Client Seite wird dann ganz normal gebaut nur mit dem Zusatz dass unten eben noch das zweite Remote Statement mit rein kommt. Die zusätzlichen Route Einträge kann man sich BTW ebenfalls schenken, wenn man die am Server bzw. am Client gleich richtig konfiguriert (mehrere Netze können angegeben werden als remote/local).
Wenn beide Leitungen gleich "stark" sind und es egal ist, ob sich ein Client über 1 oder 2 verbindet, kann man zusätzlich noch remote-random; angeben, dann wird round robin gewählt, welche Leitung verwendet wird. Damit kann man dann bei mehreren Clients die Einwahl auch noch über zwei Leitungen streuen / verteilen. Muss man dann nur nach einem Ausfall mal alle trennen und wieder verbinden lassen, sonst hat man alle auf einer Leitung hängen :)
-
Super, es funktioniert
Danke