Bestimmte Verbindungen via VPN Routen
-
@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
