VPN - Ich denke Routing Problem



  • Hallo Zusammen!

    Ich hab wiedermal ein Problem.

    Die Konstellation:

    ca 20 PC´s
    Ping nach 192.168.10.*  Fail
    Ping nach !!->10.12.18.2 OK-<!!
    Ping nach 10.12.3.0 OK
    -----------
          I
          I
    PFSense1 (LAN 192.168.1.1)
    (incl. VPN Server 1,2,3,)
    VPN1 192.168.100.0
    VPN2 10.12.14.0 - - - - > ca 10 clients Ping nach 192.168.1.1 OK - Ping nach 192.168.10.* Fail
    VPN3 10.12.18.0 - - - - > 1 Client (PFS2 10.12.18.2)
          I
          I
    ----------
    Internet
    ----------
         I
         I
    PFSense 2 (VPN Client 1 (10.12.18.2))
         I---- VLAN 1 192.168.10.0/24, Ping nach 192.168.1.1 OK, Ping nach 10.12.14.0 OK, Ping nach 192.168.100.0 OK
         I----VLAN 2 192.168.11.0/24
         I-----VLAN 3 192.168.12.0/24
    LAN 192.168.10.0/24
    
    
    
    
    
    
    

    Ich denke das Problem liegt daran das die PFS1 nicht weiß wie sie das Netz 192.168.10.0 erreichen kann.
    Nur wie bekomme ich das ins Routing?

    (Die Edit: ich kann bei der PFS1 unter Diagnose Ping, 192.168.10.* auch nicht erreichen)

    Besten dank schonmal!

    MfG Markus


  • LAYER 8 Rebel Alliance

    Das Routing ergibt sich aus der korrekten VPN Konfiguration.
    OpenVPN oder was nutzt du da?
    Am besten mal die gesamte VPN Konfiguration und Firewall Regeln als Screenshot posten.

    -Rico



  • @Markus4210
    Sind beide pfSense Stardartgateway in ihrem Netz?



  • @viragomann

    Ja die PFSensen sind jeweils das Standard Gateway.

    @Rico

    Mal der VPN Server.(PFS1)
    serv1.PNG
    serv2.jpg
    serv3.PNG
    serv4.PNG
    serv5.PNG



  • Dann der Client (PFS2)

    cli1.jpg
    cli2.jpg
    cli3.PNG
    cli4.PNG
    cli5.PNG



  • Firewall Server:

    fwser1.PNG
    fwser2.PNG

    Firewall Client:

    fwcli1.PNG
    fwcli2.PNG

    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).


  • Rebel Alliance Moderator

    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

    Server-Routen.PNG

    Client Routen

    Client-Routen.PNG

    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


Log in to reply