OPNsense Forum
International Forums => German - Deutsch => Topic started by: liceo on October 27, 2020, 08:19:23 pm
-
Hallo zusammen
Ich habe die Frage schon im EN Forum gepostet, bislang scheint niemand eine Antwort zu haben. Deshalb versuche ich es hier mal.
Ich habe pfsense vor einigen Wochen mit opnsense ersetzt und möchte nicht mehr zurück! Etwas speziell finde ich die Multi-WAN Umsetzung, ich meine das war etwas anders bei pfsense. Um Gateway-Groups und deren Redundanz-Funktionen zu nutzen, muss der Traffic mittels einer FW-Rule auf die Gateway-Gruppe geschickt werden. Funktioniert soweit auch beispielsweise für das LAN Interface.
Was bisher NICHT funktioniert, ist mein OpenVPN Setup mit zwei WAN uplinks, es verhält sich aktuell folgendermassen:
- OpenVPN funtkioniert nur, wenn der remote Client auf die WAN Adresse vom Cable-Provider connected
- Wenn clients auf die Adresse des DSL Providers connecten, funktioniert OpenVPN nicht
- Wenn ich den Cable WAN Gateway deaktiviere, funktioniert die OpenVPN Verbdindung auch über das DSL-WAN Interface
- Anhand der Firewall-Logs kann ich sehen, dass der Traffic zwar auf dem OpenVPN Server ankommt, aber auf dem anderen Gateway (Cable) wieder rausgeschickt wird (asynchrones routing)
Ich habe in den Dokus und auch im Forum keine Lösung gefunden. Im Prinzip bräuchte es eine Rule, welche den Traffic auf demselben WAN interface zurückschickt auf dem er reingekommen ist. Aber auf welchem Interface erstelle ich die Rule und wie muss die aussehen?
Vielen Dank!
Liceo
-
Idee oder Überlegung von mir....
Eine NAT Regel so einrichten , dass wenn auf deiner DSL Leitung etwas ankommt dies so aussieht als würde es vom anderen Leitung kommen...
Gesendet von meinem KB2003 mit Tapatalk
-
Sowiet ich weiß setzt du ja das Gateway für z.B. deine LAN to ANY Regel auf die GW_Gruppe.
Davor muss eine Regel erstellt werden, welche deine TUnnel und Remote Netze abdeckt mit dem Gateway als "Standard".
Dann sollten die Antwort Pakete dahin gehen wo die her kamen.
-
Sowiet ich weiß setzt du ja das Gateway für z.B. deine LAN to ANY Regel auf die GW_Gruppe.
Davor muss eine Regel erstellt werden, welche deine TUnnel und Remote Netze abdeckt mit dem Gateway als "Standard".
Die Regel auf dem Interface wo die Antwort Pakete als erstes Ankommen. Greifst du also von außen auf ein Gerät im LAN zu, die Regel auf das LAN Interface
Dann sollten die Antwort Pakete dahin gehen wo die her kamen.
-
Sorry, habe irgendwie keine Notification erhalten, danke für die Antwort.
Habe ich mir auch gedacht, aber auf welchem Interface mache ich die Rule? Es ist ja im Prinzip der Verkehr vom OpenVPN server zurück zum remote Client. Ich habe es auf dem OpenVPN Interface versucht, leider ohne Erfolg.
Du hast nicht grad zufällig ein Beispiel?
-
Warum so kompliziert? Und warum soll das anders ablaufen als in pfSense? Soweit ich weiß funktioniert es in beiden Tools ähnlich mit MultiWAN es sei denn da hätte sich jüngst signifikant was geändert.
Einfach den OpenVPN Server auf localhost binden und auf jedem WAN entsprechend ein Port Forward von udp/1194 auf localhost udp/1194 machen und gut. Funktionierte problemlos sowohl in pfSense als auch OPNsense das letzte Mal im Lab. Alles andere bräuchte je einen Server pro Interface, was intern zwar geht aber unschön ist.
-
Ha, das funktioniert, weiss auch nicht was ich mir da gedacht habe... Vielen Dank!
Was etwas anders ist als auf der pfsense (Irrtum vorbehalten): Dort musste ich keine (LAN) Rule anlegen, die den Internet Traffic auf eine Gateway-Gruppe schickt um von der WAN Redundanz zu profitieren. Das hat aber mit dem OpenVPN Problem wohl nichts zu tun ;-)
Wie auch immer, Problem gelöst!
-
> Was etwas anders ist als auf der pfsense (Irrtum vorbehalten): Dort musste ich keine (LAN) Rule anlegen, die den Internet Traffic auf eine Gateway-Gruppe schickt um von der WAN Redundanz zu profitieren. Das hat aber mit dem OpenVPN Problem wohl nichts zu tun ;-)
Jein, bei pfSense gibts seit ~2 Jahren die Möglichkeit das Default Gateway auf eine Failover Gateway Gruppe zu legen. Oder wenn du dich auf den OVPN Server beziehst, dort konntest du die FO Gruppe als Interface auswählen. Daher klappt das auch ohne Regeln sehr schön. Die Methode das bei MultiWAN auf localhost zu binden und zu forwarden ist aber schon alt/älter und steht dort seit langem in der Doku :) Darf man wertfrei nachfragen, warum du überhaupt gewechselt hast wenn alles lief?
Aber schön dass es so läuft :)
-
Darf man wertfrei nachfragen, warum du überhaupt gewechselt hast wenn alles lief?
Das ist eine gute Frage und ein längerer Ablösungsprozess ;-). Eigentlich war ich mit pfsense nicht unzufrieden, wollte aber mal einen direkten Vergleich. Hauptgründe für den Wechsel sind:
- Sensei Integration, finde ich besser gelöst als z.B. Snort bei pfsense
- Moderneres responsive WebUI (ich mag schöne GUIs :-)
- Aktuellere Versionen von Plugins (z.b. HAProxy)
Habe ausser High Availability alles zum laufen gekriegt (Dual WAN, OpenVPN, DynDNS mit Cloudflare, HAProxy mit Apache Backend, Sensei). Bei HA stimmt was noch nicht, aber das ist ein anderes Thema.