Bestimmte Verbindungen via VPN Routen
-
Hallo,
ich habe folgendes Problem,
Ich habe eine OpenVPN Server auf der Pfsense installiert, damit verbindet sich ein V - Server der im Internet Steht.
Dieser hat eine Feste IP, ist deswegen für Diverse Funktionen passend Konfiguriert.
Die Verbindung steht, es funktioniert mein Appache Reverse Proxy, dieser spricht aber ins Lan mit der IP vom OpenVPN Client.
Soweit alles in Ordnung.Nun möchte ich das der Port 25 bzw. der gesamte Traffic unsere Mailserver durch den V - Server via OpenVPN geleitet wird.
Normalerweise würde das ja via Default GW rausgehen. Dann habe ich aber eine Dynamische IP, das Funktioniert nicht.Die Kommunikation ist im Moment mit einem Lancom Implementiert, dort Funktioniert es Richtung V - Server.
Ich möchte den Lancom aber abschalten.
Im Lahncom habe ich das mit dem Tagging in der Firewall gelöst.Kann mir mal Jemand erklären was ich da tun muss?
Gruß Alexander
-
Hallo!
@tigger1975 said in Bestimmte Verbindungen via VPN Routen:
Normalerweise würde das ja via Default GW rausgehen. Dann habe ich aber eine Dynamische IP, das Funktioniert nicht.
Im Grunde gibt es 2 Möglichkeiten:
Entweder machst du die VPN zum Default Gateway oder
du routest routest per Policy Routing den Traffic rüber.Ich nehme an, dass vor allem ankommende SMTP-Verbindungen auf den V-Server über die VPN geleitet werden sollen, oder?
Da gäbe es im Falle von Polcy Routing noch ein paar Dinge zu beachten. -
@viragomann Hallo,
Danke für deine Antwort,
Ja Variante 2 ist es die ich gerne umsetzen möchte.
Und was gibt es zu beachten?Ich habe schon einige Konfigurationen ausprobiert. aber Irgendwas mache ich falsch.
Könntest du mir Tips geben auf was ich achten soll?
Grüße Alexander
-
@tigger1975
Damit pfSense die Antwortpakete wieder auf das Nicht-Default Gateway zurückrouten kann, markiert sie die entsprechende Verbindung mit dem "reply-to" Tag, der das Gateway des Interfaces enthält, auf dem die Verbindung reinkommt. Das geschieht anhand des initialen Pakets durch die Firewall Regel, die diese Verbindung erlaubt.Das setzt aus logischen Gründen voraus:
- Am eingehenden Interface muss ein Gateway definiert sein (in den Interface-Einstellungen).
- Die Regel, die die eingehende Verbindung zulässt, muss eindeutig einem Interface zugeordnet werden können.
Der Punkt 2 ist nicht erfüllt für Regeln auf Interface-Gruppen und Floating-Regeln. Beide können für mehrere Interfaces definiert werden.
Zu wissen gilt es da auch, dass genau diese Regeln Vorzug gegenüber Interface-Regeln haben. Wenn also eine solche Regel zutrifft, wird keine weitere mehr berücksichtigt.
Und der OpenVPN Tab ist eine Interface-Gruppe. Sie wird implizit durch pfSense eingerichtet, wenn man eine OpenVPN Instanz konfiguriert und enthält alle OpenVPN Instanzen, Server wie Clients.
Letzteres wird oft nicht bedacht und der Wizard zum Setup eines Zugangsservers richtet auf OpenVPN automatisch eine Regel ein, die alles erlaubt.Wenn du eine OpenVPN site-to-site einrichtest und Policy Routing verwendest, hast du der OpenVPN Instanz vermutlich bereits ein Interface zugewiesen. Damit ist der erste Punkt oben erfüllt (Das Interface wird automatisch konfiguriert und das Gateway gesetzt. Zu sehen in Routing > Gateways).
Damit hast du auch einen eigenen Tab für Firewall-Regeln für eingehende Verbindungen von dieser VPN-Gegenstelle. Auf diesem musst du nun eben eine Pass-Regel einrichten und dafür sorgen, dass keine Pass-Floating und keine Regel am OpenVPN Tab auf die gewünschten eingehenden Pakete zutrifft.
-
@viragomann
Hallo,danke, das ist schon mal eine gute Erlärung, zumidest haben sich für mich jetzt Fragen beantwortet,
leider ist mein Problem nicht gelöst.also habe das jetzt so Konfiguriert:
Ich hatte noch einen OpenVPN Server für die Client Einwahl. Dafür habe ich jetzt auch ein Interface definiert.
Außerdem hatte ich LAN und weiteres Netzwerk über eine Gruppe zusammen gefasst.
Das habe ich jetzt zum Testen aufgelöst.Client -> [LAN] -> FW: "Quelle Client IP" "Ziel Alle" "Protokoll Alle" -> Auf OpenVPN Gateway
So kommen auf dem OpenVPN Gateway laut tcpdump die "icmp echo request" Pakete an.
Leider aber nicht am OpenVPN Client.
Kann es sein das ich am Client noch was einstellen muss, oder lässt mir die PF Firewall die Pakete nicht in den Tunnel?Gruß Alexander
-
@tigger1975
Ich weiß nicht, was der OpenVPN Client ist, aber leider auch nicht, was konkret das Problem ist.Und das
Client -> [LAN] -> FW: "Quelle Client IP" "Ziel Alle" "Protokoll Alle" -> Auf OpenVPN Gateway
ist vermutlich eine Policy Routing Regel?
Die hat aber nun nichts mit eingehenden Verbinden über die VPN zu tun.Außerdem hatte ich LAN und weiteres Netzwerk über eine Gruppe zusammen gefasst.
Das habe ich jetzt zum Testen aufgelöst.Gruppen stören ja nicht grundsätzlich, nur eingehende Regeln für öffentlich Quellen dürfen darin nicht definiert sein.
-
@viragomann said in Bestimmte Verbindungen via VPN Routen:
ist vermutlich eine Policy Routing Regel?
Die hat aber nun nichts mit eingehenden Verbinden über die VPN zu tun.Dann haben wir uns Falsch Verstanden. Eingehen hat schon immer ohne Probleme Funktioniert.
Ich wollte das der Traffic von meinem Mailserver [LAN] über den OpenVPN Tunnel nach draußen geht.
Gruß
Alexander -
@tigger1975 Genau so was habe ich auch schon gemacht, es ist auch Sicht der pfSense nur policy Routing. Der VServer muss das aber auch noch routen bzw. NATen. Vielleicht liegt dort das Problem.
-
@tigger1975
Verstehe jetzt, glaub ich.BTW: Interessant, dass der Server mit der festen IP der Client in deinem VPN Setup ist.
So kommen auf dem OpenVPN Gateway laut tcpdump die "icmp echo request" Pakete an.
Leider aber nicht am OpenVPN Client.Hast du das am Client selbst am VPN Interface überprüft?
Wenn du die Pakete am lokalen VPN Interface siehst, würde ich schon annehmen, dass sie auch auf der Remote-Seite zu sehen sind.Ansonsten für ausgehende Verbindungen brauchst du am Remote-Client eine Masqareding-Regel, wenn noch nicht gesetzt.
Ist vermutlich irgendein Linux, oder? -
@viragomann und @Bob-Dig
Hallo Frohes neues Jahr,
Ich kann die Pakete mit TCPDump nur auf der PFsense seite am Tunnelinterface sehen.
Am Client sehe ich nichts.Nat ist auf dem VServer eingerichtet, ist ja auch für die Verbindung via Lancom wichtig.
Gruß
Alex -
Hallo,
wünsche auch ein gutes neues Jahr.
@tigger1975 said in Bestimmte Verbindungen via VPN Routen:
Ich kann die Pakete mit TCPDump nur auf der PFsense seite am Tunnelinterface sehen.
Am Client sehe ich nichts.Natürlich sollten die Pakete auch auf der Clientseite auftauchen, wenn das ein funktionierende Site-to-Site VPN ist.
Hast du mehrere VPN Instanzen (Server oder Client) laufen, und kann es sein, dass die Pakete in den falschen Tunnel geleitet werden?
Oder hast du einen breiteren Tunnel als /30 konfiguriert?Dieses Phänomen wurde hier im Board schon mehrmals erwähnt. Ich habe damit selbst aber noch keine Erfahrung gemacht.
Den Rückmeldungen der Leute folgend, hätte es nach dem Neueinrichten der VPN dann funktioniert.Grüße
-
@viragomann
Hallo,Ja ich habe mehrere VPN Server, einer für die NB Anbindung läuft auf ein eigenes /24 Netzwerk Funktioniert auch Problemlos,
einen weiteren für die Anbindung des Server, ohne die Subneteinstellung am Server aber, mit der IP x.x.x.x/29 weil noch ein zweiter V - Server mit gleichen Aufgaben hinzukommen soll.Grundsätzlich geht ja Traffic durch den Tunnel, wie gesagt auf dem V-Server befindest sich ein Apache als Reversproxy das funktioniert auch wunderbar.
-
@tigger1975
Wenn der Tunnel breiter als /30 ist, ist das Gateway nicht eindeutig. Daher muss für jeden Client ein CSO konfigurieren werden. Ansonsten wird das Routing nicht funktionieren.Edit: Ich habe aber keine Vorstellung, wie das mit Policy Routing funktionieren könnte.
-
@viragomann
OK, danke das könnte der hinweis sein den ich benötige.Nur was muss ich in der CSO Konfigurieren?
Das Policy Routing hab ich ja eigentlich schon am laufen, es ist auch eigentlich gar nicht so schwer.
Lediglich in der FW-Regel die für ein Ziel oder quelle auf dem Lokalen Interface angelegt wurde unter erweitert ein anderes GW auswählen.
Und WICHTIG die Regel muss die Oberste sein. Es ist wichtig das keine andere Regel vorher greift.Ach und der Hinweis oben mit den Interfacegruppen.
Grüße Alexander
-
@tigger1975
CSO funktioniert nicht mit Preshared Key.Für Policy Routing auf mehrere VPN-Gateways müsstest du mehrere Interfaces im VPN-Subnetz definieren. Das ginge nur manuell, was aber OpenVPN nicht mag.
Dazu kommt dann noch, Reply-to benötigt, wie oben erwähnt, ein eindeutiges Gateway am Interface. Kann sein, dass das immer der erste Client ist und dass es für die eine Verbindung funktioniert, verlassen würde ich mich aber nicht darauf, und für die 2. Verbindung wäre ein Weiterleiten von öffentlichen Quellen nicht möglich.
Ich würde empfehlen, für jedes VPN Gateway einen eigenen Server einzurichten. Dann ist alles eindeutig und funktioniert auch ordentlich.
Wenn du aktuell eine Preshare Key Konfiguration hast, musst du ohnehin umbauen. Da würde ich einfach mal denn Tunnel auf eine /30 Maske ändern. -
@viragomann
Hallo,danke für die Antwort.
Ich bin eigentlich der Meinung das ich das schon getestet habe.
Wenn ich unter IPv4 Tunnel-Netzwerk X.X.X.X/30 eintrage Startet der Server nicht es kommt zu einer Fehlermeldung.
Wenn ich unter IPv4 Tunnel-Netzwerk X.X.X.X/24 oder /29 eintrage kommt der Tunnel zum Fliegen, und daten gehen durch, lediglich das Policy Routing geht nicht.
Wenn ich unter IPv4 Tunnel-Netzwerk X.X.X.X/24 eintrage und unter Netzstruktur Net20 kommt der Tunnel zum Fliegen, aber auch hier geht kein Policy Routing
Ich habe auch gelesen das das net30 deprecated ist.
Irgend wie drehe ich mich im Kreis.
Gruß
Alexander -
@tigger1975
Welchen Server Mode hast du eingestellt?Bei einem Peer-to-Peer ist eine /30 Topologie Standard und auch gar nicht veränderbar.
-
Bor danke, das war der Hinweis den ich gesucht habe, alles Richtig gemacht, aber einen kleine Einstellung falsch.
Modus: Peer to Peer ( SSL/TLS ) das wars!
Ich hatte Fernzugriff ( SSL/TLS ) eingestellt.
Jetzt gehts!!!!
Danke!!!
Gruß
Alex -
@tigger1975
Freut mich, dass das endlich klappt.Bei SSL/TLS ginge auch CSO für mehrere Clients, wenn du einen breiteren Tunnel einstellst. Allerdings, wie oben erwähnt, ich rate zu getrennten Servern mit jeweils 30er Tunnel. Das schließt schon im Vorfeld einige Probleme aus und alles ist sauber getrennt und gut konfigurierbar.
UND es erfordert nicht mehr Systemressourcen, was offenbar manche befürchten, UND OpenVPN Server Settings kann man in aktuellen Versionen einfach kopieren.Grüße
