VPN - Ich denke Routing Problem
-
-
Dann der Client (PFS2)
-
Firewall Server:
Firewall Client:
Besten Dank!
MfG. Markus
(Musste das aufteilen - Sonst Flag Spam oder zu lang)
-
Die IPv4 Routingtabellen von beiden Seiten wären noch interessant (Diagnostic > Routes).
-
Mal davon abgesehen, dass ich die Hälfte der gesetzten Settings seltsam und nicht aktuell finde (warum das redirect-gateway def1 auf dem Client? Das istunnötig.)
Zumal auf dem Client kein Tunnel-Netzwerk angegeben und kein Entferntes Netz angegeben. Damit wird es auf der Client Seite auch kein Routing geben.Ich weiß nicht wonach du diese Konfiguration gebaut hast, aber ich würde die komplett wegwerfen und neu machen.
-
Hallo zusammen!
@JeGr redirect-gateway def1 hab ich rausgenommen und die entfernten netze eingetragen.
Bringt aber keine Veränderung.Sorry für die späte Antwort - bin etwas im Stress in letzter Zeit.
Server Routen
Client Routen
Achtung! -> habe die Netzwerk Aufzeichnung nochmal geändert, - hatte da einige Fehler drinn.
Sorry und Danke!
(Die Edit -> die 83 er Adressen sind meine Statischen WAN Adressen.)
-
Also an den Routen sollte es nicht liegen, jedenfalls nicht an den abgebildeten mit gesetztem "redirect-gateway def1". Dass damit sämtlicher Upstream Traffic von der Client- zur Serverseite geschickt wird, ist dir ja wohl bewusst, oder?
Das Interface "OVPN" am Client ist der OpenVPN Client Instanz ovpnc1 zugeordnet?
Und die Firewall-Regeln am LAN des Servers verhindern auch nicht den Zugriff auf 192.168.10.*?Am Client WAN solltest du übrigens die "alles erlauben" Regel entfernen. Um eine Verbindung zum Server aufzubauen braucht es da keine Regel.
-
@viragomann
Danke für die Denkanstöße!
Das mit dem "redirect-gateway def1" stimmt so nicht.
Bei mir ist es so das VLAN2 und VLAN3 von der PFS2 direkt ins Inet kommen.
(Daher auch die Client WAN Regel "alles erlauben")Auf der Client Site das VLAN1 geht über den Server - also VPN,PFS1,Inet
Am LAN der PFS1 ist auch eine "alles erlauben" Regel.
Muss da noch eine Regel rein damit 192.168.10.0/24 explizit erlaubt ist?Danke!
Die Edit: Müsste es nicht auf der Client Seite eine Route geben von 192.168.1.0 oder VPN 10.12.18.0 auf 192.168.10.0 ?
-
@Markus4210 said in VPN - Ich denke Routing Problem:
(Daher auch die Client WAN Regel "alles erlauben")
Die Firewall-Regeln wirken immer auf eingehenden Traffic.
Wenn den beiden Netzen alles ins Internet erlaubt sein soll, müssen die Regel auf den jeweiligen Interfaces der Netze definiert werden, nicht am WAN. Eine Regel am WAN Interface wirkt sich auf Pakete aus, die am WAN reinkommen.@Markus4210 said in VPN - Ich denke Routing Problem:
Am LAN der PFS1 ist auch eine "alles erlauben" Regel.
Muss da noch eine Regel rein damit 192.168.10.0/24 explizit erlaubt ist?Nein. Wenn eine Regel bereits alles erlaubt, reicht das. Hätte sein können, dass da nur gewisse Netze erlaubt wären.
@Markus4210 said in VPN - Ich denke Routing Problem:
Müsste es nicht auf der Client Seite eine Route geben von 192.168.1.0 oder VPN 10.12.18.0 auf 192.168.10.0 ?
Nein. 192.168.10.0/24 ist ja an einem Interface des Clients definiert. Da braucht es keine Route.
Wenn du aber 192.168.100.0/24 (LAN PFS1) meinst. Diese Route sollte aufscheinen, wenn du, wie @JeGr empfohlen hat, "redirect-gateway def1" entfernst und stattdessen dieses Netz bei "Entfernte Netzwerke) einträgst, was ich für deine Zwecke auch empfehlen würde.
Um den Upstream Traffic bestimmter Quellen dann über die VPN zu routen, muss in der Firewall-Regel, die den jeweiligen Traffic erlaubt, das VPN-Gateway gesetzt werden. Dazu die erweiterten Optionen in der Regel öffnen und das VPN Gateway bei "Gateway" auswählen. Voraussetzung ist, dass der VPN-Instanz ein Interface hinzugefügt wurde, wie zuvor erfragt. -
Puh - - das hab ich jetzt nicht ganz mitbekommen.
Ja auf der Client Seite hat die VPN Instanz ein eigenes Interface.
Auf der Server seite nicht.@viragomann said in VPN - Ich denke Routing Problem:
@JeGr empfohlen hat, "redirect-gateway def1" entfernst und stattdessen dieses Netz bei "Entfernte Netzwerke) einträgst, was ich für deine Zwecke auch empfehlen würde.Hab ich so gemacht...
Soll ich die Regel auf der Client Seite hinzufügen -> nicht oder?
Auf der Server Seite gibt es kein eigenes Interface.
MfG.
-
@Markus4210 said in VPN - Ich denke Routing Problem:
@viragomann said in VPN - Ich denke Routing Problem:
@JeGr empfohlen hat, "redirect-gateway def1" entfernst und stattdessen dieses Netz bei "Entfernte Netzwerke) einträgst, was ich für deine Zwecke auch empfehlen würde.
Hab ich so gemacht...Wie erwähnt, in der Routing-Tabelle am Client ist das nicht ersichtlich, da war "redirect-gateway def1" gesetzt.
Darüber, ob Interfaces für eine Site to site VPN nötig sind, gehen hier die Meinungen auseinander. Auf der Serverseite gibt es klare Routen, die auf den richtigen VPN Client zeigen, daher sollte das Routing auch ohne Interface funktionieren.
Dennoch, ich hatte früher die Erfahrung gemacht, dass sich Pakete gerne "verlaufen", wenn mehrere VPN Instanzen auf einem Host aktiv sind. Ich würde daher am Server der Site to site VPN (ovpns2, wenn Seit dem Screenshot der Routing-Tabelle noch nichts verändert) auch ein Interface hinzufügen.
Die Firewall-Regeln können dann auf diesem oder auf OpenVPN definiert werden. Letzteres ist eine Interfacegruppe für alle OpenVPN Instanzen.Grüße
-
Servus nochmal!
Leider das ganze hat mir eine richtig lange Nacht bereitet.
Sobald ich am Server ein Interface hinzufüge, den VPNServer darauf zuweise und das Interface einschalte ist es mit der Verbindung vorbei.
Das entfernen des redirect gateway def1 hat sich auch als schlechte lösung herausgestellt. Machte zwar beim Speichern keinen Unterschied aber nach einen Neustart war ich zwar mit dem VPN Server verbunden und konnte all Clients auf der Server Seite erreichen, allerdings ging dann meine Verbindung ins Inet direkt und nicht übers VPN.Ganz schön verwirrend das ganze.
MfG.
Markus
