Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

OpenVPN 2. Standort kommt nicht ins Hauptnetz

Frage Netzwerke Router & Routing

Mitglied: Luciver1981

Luciver1981 (Level 1) - Jetzt verbinden

02.12.2014 um 12:06 Uhr, 1029 Aufrufe, 13 Kommentare

Hallo Admingemeinde, folgendes Szenario

Hauptstandort:
Netzt 192.168.0.0/24
Pfsense mit Openvpn server
VPN: 10.0.8.0/24 (im Router, VPN Server als Gateway für dieses Netz)

2. Standort:
Easybox 192.168.2.1(DHCP Server)
Pfsense:
WAN: DHCP client
LAN: 172.17.0.0/24

Normale Clients(auf Laptop VPN Client) kommen in das Hauptnetz.

Der 2. Standort ist verbunden aber ich kann weder 10.0.8.1 (VPN Server Adresse), noch ins Hauptnetz pingen.

In der Serverconfig hab ich folgende Einträge vorgenommen:

route 172.17.0.0 255.255.0.0;push "route 192.168.0.0 255.255.255.0";push "route 172.17.0.0 255.255.0.0";push "dhcp-option DNS 192.168.0.7"

Hat jemand eine Idee?
Mitglied: Luciver1981
02.12.2014 um 13:12 Uhr
Der Ping von der PFsense von der Aussenstelle über Diagnose ->Ping von Openvpnclient ins Hauptnetz ist erfolgreich, ein Traceroute (ohne ICMP) nicht.
Bitte warten ..
Mitglied: aqui
02.12.2014 um 16:48 Uhr
Deine Schilderung ist etwas verwirrend da du einmal die mobilen Clietns beschreibst und einmal den 2.Standort. Also erstmal sortieren damit wir es verstehen:
  • Mobile Clients mit OVPN können sich am Server Hauptnetz anmelden und alles pingen ?!
  • 2.ter Standort macht ein Site to Site VPN um die netze zu koppeln, richtig ?
  • 2ter Standort kann weder das interne OVPN IP Netz erreichen noch das Hauptnetz 192.168..0.0 /24, richtig ?

Dazu 2 Fragen:
  • Kannst du anhand der pfSense Logs sicherstellen das sich der 2te Standort erfolgreich verbinden kann, bzw. siehst du eine "Success" Meldung im Log ?
Das ist wichtig um überhaupt erstmal zu klären ob Zertifikate, Passwörter usw. stimmen und der Tunnel überhaupt als solches zustande kommt !!
Dadurch das du die interne IP nicht pingen kannst bestehen da Zweifel....
  • Achtung: Es sieht so aus als ob du hier eine Router Kaskade mit der Easybox betreibst ?? Ist dem so ?
Wenn ja musst du hier unbedingt den OVPN Port UDP 1194 auf die am LAN angeschlossene WAN IP 192.168.2.x der pfSense hier per Port Forwarding forwarden ! Machst du das nicht kommt erst gar kein OVPN Traffic durch:
Siehe Tutorial hier:
http://www.administrator.de/wissen/openvpn-server-installieren-auf-dd-w ...
Weitere zwingende ToDos in einer solchen Kaskade:
  • PfSense WAN Port sollte eine statische IP außerhalb der DHCP Range der Easybox haben ! Das ist zwingend denn solltest du DHCP verwenden und sich die IP durch die DHCP Dynamik einmal ändern an der pfSense, denn geht dein Port Forwarding für den OVPN Traffic auf der Easybox ins Nirwana und dein VPN steht ! Hier also immer statisch arbeiten !
  • Im General Setup der pfSense am WAN Port den Haken bei Block RFC 1918 IP networks entfernen !
  • Eine Firewall Regel erstellen die von Source Any auf Destination pfSense WAN IP address den Destination Port UDP 1194 und Source Port Any erlaubt !!
Damit erlaubst du generell OVPN Traffic auf die WAN IP der pfSense.
Das alles musst du als erstes sicher verifizieren. Kommt der Tunnel durch ggf. Fehler gar nicht zustande sind die folgenden Schritte natürlich obsolet !
Weiter....
  • Ist ersteres sichergestellt, hast du auf beiden Firewalls ein virtuelles OVPN Interface (Tunnelinterface) über die der Traffic zw. den Standorten rennt ! Hier musst du sicherstellen das einen entsprechende Firewall Regel existiert die hier allen Traffic mit Source IP 192.168.0.0 /24 nach Destination IP 172.17.0.0 /24 Protokoll "Any" erlaubt. (Hauptstandort)
Analog am 2ten Standort: Traffic mit Source IP 172.17.0.0 /24 nach Destination IP 192.168.0.0 /24 Protokoll "Any"
Als Tip immer ins Firewall Log sehen ob da was geblockt wird. Ggf. das Log vorher löschen.
Am Hauptstandort klappt es ja schon denn da können die Clients ja arbeiten ?!

  • Thema Firewall: Sollte der Tunnel klappen kommst du im Hauptstandort Netz und analog auch am 2ten Standort mit einer fremden Absender IP an. Fast alle Firewalls aller Betriebssysteme blocken das per Default wenn dort Absender IPs auftauchen die nicht aus dem lokalen IP Netz kommen. Beachte das und passe die lokalen Firewalls entsprechend an !
Zum Testen ist es erstmal sinnvoller ein Endgerät in diesen Netzen zu pingen das keine Firewall hat wie z.B. ein Drucker.
Auch hier darauf achten das dieses Gerät ein Default Gateway definiert hat das immer auf den lokalen pfSense LAN Port zeigt !

Wenn du das alles beachtest kommt das auch sofort zum fliegen.
Bitte warten ..
Mitglied: Luciver1981
03.12.2014 um 10:05 Uhr
Hallo Aqui, die Verbindung ist definitiv hergestellt. Ich sehe sowohl im Client als auch im Server das die Verbindung steht und der Client eine VPN Netz IP bekommen hat, also kann ich das eigentlich ausschließen.
M ich beim Server an der VPN konfiguartion etwas ändern? Derzeit ist Remote Access SSL eingestellt. Muss in einen der Router, im Hauptnetzwerk oder in der Aussenstelle, noch Routen eingetragen werden?
Die Routerkaskade werde ich entfernen und klemm einfach ein Modem vor die Pfsense in der Aussenstelle und lass die das machen.
Bitte warten ..
Mitglied: Luciver1981
03.12.2014 um 15:39 Uhr
Also ich habe die PFsense in der Außenstelle neu Konfiguriert

PFsense Direter Router (an Modem)
Netzwerk 172.17.0.0/24

Ich kann von der Aussenstelle PFsense Diagnose ->Ping mit Schnittstelle Openvpn client ins Hauptnetz pingen, aber nicht vom LAN der Außenstelle

Andererseits kann ich vom Hauptnetz aus weder die Openvpnclient 10.0.8.1 noch die LAN schnittstelle 172.17.0.1 der Außenstelle anpingen.

Fehlen da Routen oder ist der Fehler in der Firewall?
Bitte warten ..
Mitglied: aqui
03.12.2014 um 16:41 Uhr
Ich kann von der Aussenstelle PFsense Diagnose ->Ping mit Schnittstelle Openvpn client ins Hauptnetz pingen, aber nicht vom LAN der Außenstelle
Das ist jetzt etwas verwirrend.... Wie meinst du das ?
Wenn du im Ping Tool der pfSense als Source IP das OVPN Interface nimmst und als Destination die LAN IP des Hauptstellennetzes geht es.
Mit der Außenstellen LAN IP als Source aber nicht ??
Das bitte mal genauer ??
Hast du an der Aussenstelle ein push route 172.17.0.0 /24 in die OVPN Konfig eingetragen ??
Wenn die Außenstellen pfSense eingewählt ist in der Hauptstelle WAS sagt die Routing Tabelle der Hauptstellen pfSense ??
Ist dort das Netz 172.17.0.0 /24 vorhanden ? Das muss zwingend sein !
Klick auf "Diagnostics -> Routes" !
Andererseits kann ich vom Hauptnetz aus weder die Openvpnclient 10.0.8.1
Das ist auch unmöglich, denn die 10.0.8.1 müsste die interne OVPN Server IP sein und das müsstest du auch sehen unter der Routing Tabelle. Als Gateway steht da "link#xyz" !
Fehlen da Routen oder ist der Fehler in der Firewall?
Da fehlen die Routen vermutlich. Die musst du aber nicht statisch definieren sondern sollten dynamisch bei OVPN propagiert werden.
Ein Route Tabel Posting beider FWs wäre hilfreich mit aktiver OVPN Site to Site Session.
Bitte warten ..
Mitglied: Luciver1981
04.12.2014, aktualisiert um 11:34 Uhr
Hier die Routingtabelle von der PFsense Hauptnetzwerk

e7a14d1418a1c60b23b6a57d29e6f1a6 - Klicke auf das Bild, um es zu vergrößern

Was ich nicht verstehe das der Router für das 172.17.0.0 Netzwerk die 10.0.8.2 ist und nicht die 10.0.8.1.
Die 10.0.8.1 kann ich anpingen, die 10.0.8.2 nicht.

Achso im Hauptnetzwerk ist die Pfsense nicht der WAN Gateway also auch nicht der Master Router, sondern das erledigt ein LANCOM bei diesem habe ich die Route folgendermaßen erstellt.
Netz: 172.17.0.0/24
Gateway: die Pfesense im Hauptnetzwerk
Bitte warten ..
Mitglied: aqui
04.12.2014, aktualisiert um 12:12 Uhr
Das sieht sehr gut aus ! Wie du ja selber sehen kannst hat die Nebenstellen pfSense im Tunnel die IP 10.0.8.2 und die Route in das dortige lokale LAN 172.17.0.0 /24 ist angelegt.
In der Hauptstelle also alles gut. Sofern du ICMP (Ping) auf dem lokalen LAN und Tunneladapter in den FW Regeln erlaubt hast solltest du von der Hauptstellen pfSense mit der Absender IP lokal LAN die 10.0.8.2 und auch die 172.17.0.x Adresse der nebenstellen pfSense pingen können.

Vice versa musst du dir auch mal die Routing Tabelle der nebenstellen pfSense ansehen ! Dort sollte ein analoger Eintrag sein:
Zielnetz: 192.168.0.0 /24 Gateway: 10.0.8.1
Auch von da muss dan das remote Tunnel Interface und LAN Interface der Hauptstellen pfSense pingbar sein. Auch nur wenn in den Interface FW Regeln ICMP als Protokoll erlaubt ist !!
im Hauptnetzwerk ist die Pfsense nicht der WAN Gateway also auch nicht der Master Router, sondern das erledigt ein LANCOM
OK, sehr wichtige Info !
Dort müssen 2 statische Routen eingetragen werden:
Zielnetz: 172.17.0.0/24, Gateway: 192.168.0.x (die Pfsense im Hauptnetzwerk)
und
Zielnetz: 10.0.8.0/24, Gateway: 192.168.0.x (die Pfsense im Hauptnetzwerk)
ACHTUNG: sofern du am LAN Port eine Firewall Regel hast die inbound NUR das LAN Netzwerk 192.168.0.0 /24 mit Ziel ANY erlaubst, dann MUSST du logischerweise noch eine Firewall Regel hinzufügen die Inbound auch Pakete fürs 172er und 10er Netz erlauben !!!
Klar sonst blockt die FW alles was nicht 192.168.0.0 ist !
Checke also in jedem Falle deine Regeln sowohl am LAN Port als auch am virtuellen Tunnel Port !!
Generell gilt eine FW blockt alles was du nicht explizit erlaubt hast !!
Denk dabei auch an die lokalen Firewalls auf den Endgeräten im LAN. Du kommst jetzt bei der remoten Seite immer mit anderen Absender IPs ! Normal blocken alle Firewalls das was eben nicht lokal ist.
Nimm zum Ping Test dann besser einen Drucker oder irgendein anderes Endgerät was keine lokale Firewall hat um das auszuschliessen.

Im Zweifel siehst du dazu immer in das Firewall Log der pfSense ! Die listet dort akribisch auf WAS sie WO blockt so das du darauf reagieren kannst sollten interne IP des 172er und 10er Netze irgendwo geblockt werden !
Am besten das FW Log vorher löschen und dann einen Connect Versuch machen, dann siehst du das sofort !
Bitte warten ..
Mitglied: Luciver1981
04.12.2014, aktualisiert um 12:36 Uhr
Leider kann ich vom Hauptnetz die 10.0.8.2 nicht anpingen nur die 10.0.8.1 und die bekomme ich aber nicht als Gateway eingetragen.
Bitte warten ..
Mitglied: aqui
04.12.2014, aktualisiert um 18:24 Uhr
Warum auch als Gateway ? Sie ist ja direkt angeschlossen...
Das du die 10.0.8.1 der Standort pfSense nicht pingen kannst liegt vermutlich an einer fehlenden Firewall Regel auf dem Tunnel Interface ?!
Bei einem Testaufbau hier klappt das fehlerlos !
Wie sieht die Routing Table an der Standort pfSense aus ?? Ist dort das Netz 192.168.0.0 /24 vertreten ?
Wenn nicht kannst du es auch erzwingen mit dem Eintrag route 192.168.0.0 255.255.255.0; in der Konfig. Es sollte aber auch so auftauchen !
Bitte warten ..
Mitglied: Luciver1981
04.12.2014 um 18:41 Uhr
Die 10.0.8.1 kann ich vom Hauptnetz aus anpingen aber nicht die 10.0.8.2 die allerdings als Gateway (siehe Bild) für das 172.17.0.0 Netzwerk eingetragen ist.
Bitte warten ..
Mitglied: aqui
05.12.2014 um 09:23 Uhr
Die 10.0.8.1 kann ich vom Hauptnetz aus anpingen
Das ist klar, denn die IP liegt ja auf der Hauptnetz pfSense selber ! Kannst du die von jeglichem Gerät aus im Hauptnetzz anpingen die den Lancom als Default Gateway eingetragen haben ?
aber nicht die 10.0.8.2
Das ist die Tunnel IP der Nebenstellen pfSense ! Das diese IP in der Routing Tabelle der Hauptstellen pfSense steht zeigt das eine funktionierende OVPN Verbindung besteht, denn sonst würde das nicht dynmaisch eingetragen worden !
Das du sie nicht pingen kannst kann eigentlich nur daran liegen das die FW Regeln auf dem internen Tunnel Interface ICMP (Ping) blocken. Eine andere Erklärung gibt es nicht.
Bitte warten ..
Mitglied: Luciver1981
05.12.2014, aktualisiert um 14:56 Uhr
Kannst du mir noch kurz helfen das Prinzip der FW Regeln auf den einzelnen Schnittstellen erklären?

Folgende Regeln würde ich setzen an der Außenstelle:

Adapter VPN:
Source: LAN_NET Proto: any Service: any Destination: 192.168.0.0/24
Adapter LAN:
Source: 192.168.0.0/24 Proto: any Service: any Destination: LAN_NET

Ist das so Richtig oder muss ich noch Regeln fürs Transfernetz erstellen?

Und kann ich der Außenstelle ein feste VPN IP vergeben?
Bitte warten ..
Mitglied: aqui
06.12.2014 um 18:39 Uhr
Kannst du mir noch kurz helfen das Prinzip der FW Regeln auf den einzelnen Schnittstellen erklären?
Klar !
Das Regelwerk ist ganz einfach:
  • FW Regeln gelten immer nur INBOUND also nur für Pakete die extern vom LAN/WAN IN's Interface der Firewall reinkommen !
  • Es gilt immer: First match wins ! Das heisst die erste Regel die greift sorgt dafür das die nachfolgenden Regeln des Regelwerks NICHT mehr ausgeführt werden !!
Das ist in sofern wichtig das damit die Reihenfolge der Regeln eine nicht unerhebliche Rolle spielt in der Regellogik. Du kannst also nicht erst was erlauben was du hinterher wieder verbietest z.B.
Du kannst daher sehen das deine obige Regel am LAN Adapter mit "Source: 192.168.0.0/24" schon fehlerhaft ist, denn dort können niemals Pakete mit einer Source Adresse 192.168.0.0 auftreten. Du hast diese regel vermutlich als OUTBOUND Regel gedacht, richtig ? Dann würde die Logik Sinn machen aber OUTBOUND Regeln supportet die FW nicht.
Am LAN Adapter sollte also stehen:
Pass oder Permit: Source: LAN_NET Proto: any Service: any Destination: any
Du musst hier ja alles erlauben, da die FW ja auch lokalen Internet Traffic abwickelt.
Adapter VPN:
Permit, Pass: Source: LAN_NET Proto: any Service: any Destination: 192.168.0.0/24
Das würde dann funktionieren.
Testweise solltest du am VPN Adapter aber erstmal //LAN_NET nach any erlauben als Schrotschuss um das VPN sauber zu testen und dir möglichst wenig Fallen zu stellen durch Regeln.
Wenn das VPN rennt, dann kannst du das regelset immer wieter "zumachen". Du kannst dann sehen falls mal was nicht geht war die Regel zu strikt
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Router & Routing
OpenVpn Verbindung Synology NAS hinter Zywall USG 40 (2)

Frage von Tirgel zum Thema Router & Routing ...

Windows Server
Windows Firewall Einstellungen für OpenVPN Tunnel (4)

Frage von Aubanan zum Thema Windows Server ...

Netzwerkgrundlagen
gelöst Heimnetzwerk über Server im Internet und OpenVPN erreichbar machen (16)

Frage von byt0xm zum Thema Netzwerkgrundlagen ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...