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
GELÖST

OpenVPN Routen werden nicht korrekt übergeben (PfSense)

Frage Netzwerke Router & Routing

Mitglied: Kaioshin

Kaioshin (Level 1) - Jetzt verbinden

09.01.2013, aktualisiert 00:52 Uhr, 7101 Aufrufe, 8 Kommentare

Hallo Leute
Ich hoffe ihr könnt mir beim folgenden Problem weiter helfen.

Gemäss der Anleitung von aqui, habe ich in einer virtuellen Umgebung versucht, zwei PfSense Router anhand von OpenVPN zu verbinden. Die Verbindung baut sich auch auf. Hier einige Screenshots von den Konfigurationen her.

b31727231e66a61419de19e4ae34920e - Klicke auf das Bild, um es zu vergrößern
Entschuldigt die komische Zeichnung (hatte kein Zugriff auf Visio).

Server Konfiguration
cf1d6cb160bafb68fd728cd5d67f6b91 - Klicke auf das Bild, um es zu vergrößern

Server Konfiguration
8142e0ff89b48813600960dbefb3c956 - Klicke auf das Bild, um es zu vergrößern

Client Konfiguration
83d62a37ba8448223f87bdc9c1bf6783 - Klicke auf das Bild, um es zu vergrößern

Client Konfiguration
b62f9700c57be58ee9959dc9c6cdd219 - Klicke auf das Bild, um es zu vergrößern

Da es es sich nur um einen Test handelt, sind die Firewall Regeln auf praktisch allen Adaptern so eingestellt, da jeglichder Verkehr erlaubt wird (WAN, LAN, OpenVPN (auf beiden Routern)). Die VPN Verbindung baut sich grundsätzlich auf, jedoch gibt es mit dem Routing ganz komische Probleme.

Server OpenVPN Status
52c007cceeaff4ada8ec1dd65d0989df - Klicke auf das Bild, um es zu vergrößern

Client OpenVPN Status
1f9cb11ff17101200c363ca42551051e - Klicke auf das Bild, um es zu vergrößern

Der Client aus dem Netz 10.1.1.0/24, kann einen Client aus dem Remotenetz (10.2.1.0/24) nicht anpingen. Umgekehrt das gleiche. Gehe ich jedoch auf dem Router (OpenVPN Client) per Shell drauf, kann ich das Netz 10.1.1.0/24 erreichen. WSchaut man sich per ifconfig die Einstellungen an, erkennt man bei den OpenVPN Adaptern folgendes,

ifconfig Server
01.
ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 
02.
	options=80000<LINKSTATE> 
03.
	inet6 fe80::20c:29ff:feee:f7ea%ovpns1 prefixlen 64 scopeid 0x9  
04.
	**inet 10.254.1.1 --> 10.254.1.2 netmask 0xffffffff**  
05.
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV> 
06.
	Opened by PID 52164
ifconfig Client
01.
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 
02.
	options=80000<LINKSTATE> 
03.
	inet6 fe80::20c:29ff:fe75:bfb5%ovpnc1 prefixlen 64 scopeid 0x9  
04.
	**inet 10.254.1.6 --> 10.254.1.5 netmask 0xffffffff**  
05.
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV> 
06.
	Opened by PID 17031
Ich weis nicht ob das so korrekt ist, beide Adapter haben jeweils zwei Adressen. Entsprechend sind die Routen aus meiner Sicht komisch. Hier ein relevanter Abschnitt davon.

Route Client
01.
Internet: 
02.
Destination        Gateway            Flags    Refs      Use  Netif Expire 
03.
default            dsldevice.home     UGS         0      692    em0 
04.
10.1.1.0           10.254.1.5         UGS         0        6 ovpnc1 
05.
10.2.1.0           link#2             U           0        5    em1 
06.
client             link#2             UHS         0        1    lo0 
07.
10.254.1.1/32      10.254.1.5         UGS         0        1 ovpnc1 
08.
10.254.1.5         link#9             UH          0        1 ovpnc1 
09.
10.254.1.6         link#9             UHS         0        0    lo0
Im grunde möchte ich, das zwischen beiden Netzen (10.1.1.0/24 und 10.2.1.0/24) geroutet wird. Später sollen weitere OpenVPN Clients auch eine gleiche Verbindung mit dem Netz 10.1.1.0/24 haben (Remote Access).

Bin für jede Hilfe sehr dankbar.

Gruss
Kaioshin
Mitglied: aqui
09.01.2013 um 16:38 Uhr
Das "route" Kommando ist eigentlich überflüssig. Einzig sollte ein "Push route" reichen. Vermutlich gibt es da ein Konflikt, zumal das "route" Kommando unsinnig ist, denn da fehlt ein next Hop Gateway.
Du kannst dir unter Diagnostics die Route Table der OVPN Router ansehen ob die entsprechenden IP Netze jeweils in die Tunnelinterfaces geroutet werden.
Die Clients sollten natürlich allesamt auf die OVPN Router als default Gateway eingetragen haben !
Bitte warten ..
Mitglied: orcape
09.01.2013 um 20:14 Uhr
Hallo Kaioshin,

Im grunde möchte ich, das zwischen beiden Netzen (10.1.1.0/24 und 10.2.1.0/24)
geroutet wird.
Dann sollte die Server-Config auf Peer-to-Peer SSL/TLS stehen und nicht auf
Remote Access.
Dann kannst Du auch Dein remotes Netzwerk in der Eingabemaske des pfSense-OVPN-Servers eingeben und wie hier Aqui schon richtig sagt, ist das "route" Kommando unter "advanced" dann überflüssig, Du hast ja bereits in der Server Config das remote Netz hinter dem OVPN-Client eingetragen.
Der "push" Eintrag dort ist so OK, er teilt dem OVPN-Client mit, welches Netz hinter dem Server liegt.
Was Dir noch fehlt sind Einträge unter "Client Specific Overrides" auf dem Server.
Dort sind die Serverangaben einzutragen und was ganz wichtig ist,
ein "iroute" Befehl zum remoten OVPN-Clientnetz.
iroute 10.2.1.0 255.255.255.0;
Dann erhält´s Du ein Virtuelles Netz, welches nicht mehr aus 4 Tunnel-IP´s besteht, sondern nur noch aus...
10.254.1.1 Server-IP
10.254.1.2 Client-IP
...und du solltest das Clientnetz vom Server und umgekehrt erreichen.

Gruß orcape
Bitte warten ..
Mitglied: Kaioshin
09.01.2013, aktualisiert um 20:54 Uhr
Hallo aqui

Ich dachte das "route"-Kommando wäre für den Server insofern wichtig, dass wen mehrere Netzte hinter den Clients liegen, diese durch die Information (anhand des route Befehls) erreicht werden könne. In meinem Beispiel ist das (jetzt) nicht der Fall.

denn da fehlt ein next Hop Gateway.
Wäre das nicht der OpenVPN Adapter des Clients?

Die Clients sollten natürlich allesamt auf die OVPN Router als default Gateway eingetragen haben !
Das ist natürlich der Fall. Die Clients hängen direkt an den Router (OVPN Server, OVPN Client).

Wenn ich den OpenVPN Systemlog anschaue, stelle ich einen Fehler fest:
d6450fa32332bd9de6257d09912fc87a - Klicke auf das Bild, um es zu vergrößern

Jan 9 19:13:05 openvpn[55058]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
Meistens zweimal hintereinander aufgelistet.

Im PfSense Forum lass ich, dass einer mit derselben Konfiguration (die die betroffene Person hatte) den Fehler nicht feststelle, wenn er auf eine frühere Firmware upgradete.

Was ganz komisch ist, ist dass der Router (Client) selber, das Netz 10.1.1.0/24 und die Clients erreicht. Wenn ich auf dem Client (10.1.1.1) Wireshark laufen lasse und danach einen Ping vom OpenVPN Client Router starte, stelle ich im Wireshark eine Anfrage von 10.254.1.6 fest. Der Client (10.2.1.3) hinter dem OpenVPN Router Client kann hingegen das fremde Netz nicht erreichen.

Ich habe nun den Client auf die neue Version 2.0.2 geupdatet. Der Fehler besteht aber weiterhin (vorher hatte ich 2.0.1). Der Server befindet sich auf die Version 2.0.1.

Danke für deine Hilfe.

Gruss,
Kaioshin
Bitte warten ..
Mitglied: Kaioshin
09.01.2013, aktualisiert um 20:50 Uhr
Hallo orcape

Dann sollte die Server-Config auf Peer-to-Peer SSL/TLS stehen und nicht auf
Remote Access.
Werde ich jetzt mal so einstellen.

Dann kannst Du auch Dein remotes Netzwerk in der Eingabemaske des pfSense-OVPN-Servers eingeben und wie hier Aqui schon > richtig sagt, ist das "route" Kommando unter "advanced" dann überflüssig, Du hast ja bereits in der Server Config das remote Netz hinter dem OVPN-Client eingetragen.
Als Remote-Netz auf der Serverseite, habe ich das lokale Netz des Servers eingetragen (10.1.1.0/24). Aber ich dachte mir, dass ich vielleicht die lokalen Netzte des Server per push an den Client übertrage - da es später mehrere sind. Weil nach dem Tutorial musste ich da - wenn ich mich nicht irre - dort das für den Client zu erreichende Netz eintragen.
Und die hinter dem Client liegenden Netzte per route Befehl am Server mitteilen. Wobei ich jetzt sehe, dass mit der "Peer-to-Peer" Einstellung, ein weiteres Eingabefeld auftaucht: "Remote Network". Trotzdem müsste ich aber bei Vorhandensein mehrere Netzte, mit den Befehlen unten arbeiten, oder?!?

Was Dir noch fehlt sind Einträge unter "Client Specific Overrides" auf dem Server.
Dort sind die Serverangaben einzutragen und was ganz wichtig ist,
ein "iroute" Befehl zum remoten OVPN-Clientnetz.
Werde ich jetzt machen.

Danke für deine Hilfe.

Gruss
Kaioshin

PS: Entschuldigt den Doppelpost.
Bitte warten ..
Mitglied: aqui
10.01.2013 um 15:32 Uhr
.. ."stelle ich im Wireshark eine Anfrage von 10.254.1.6 fest. Der Client (10.2.1.3) hinter dem OpenVPN Router Client kann hingegen das fremde Netz nicht erreichen."
Das ist auch insofern logisch, das du die AbsenderIP Adresse nicht mitgegeben hast. In den pfSense Diagnostics kannst du die auswählen !
Letztlich ist es aber egal wenn der 10.254.1.6er Ping am Client ankommt 10.2.1.3 will der auch ein Echo Reply (Ping) and die 10.254.1.6 zurückschicken. Dazu sieht der Client in seine Routing Tabelle ("route print" zeigt dir die), denn es ist ja nicht sein loakles Netz. Er wird das Antwortpaket also an sein Default Gateway schciken, was hoffentlich der pfSense Router ist. Hier solltest du jetzt unter Statistics auch mal nachsehen wie dessen Routing Tabelle aussieht !!
Die zeiht dir nämlich genau WO das 10.254.1er Paket hingeroutet wird.
Fazit: Irgendwas ist total vermurkst bei den Routen. Eigentlich mehr als verwunderlich, denn wenn man OVPN einfach ohne Schnickschnack einrichtet funktioniert sowas schon in einer simplen Grundkonfiguration.
Unverständlich also was du da machst. Sagen die pfSense Logs irgendwas ??
Bitte warten ..
Mitglied: Kaioshin
10.01.2013, aktualisiert um 19:45 Uhr
Hallo

Jetzt funktioniert es nun.

Fazit: Irgendwas ist total vermurkst bei den Routen. Eigentlich mehr als verwunderlich, denn wenn man OVPN einfach ohne Schnickschnack einrichtet funktioniert sowas schon in einer simplen Grundkonfiguration.

Ganz am Anfang habe ich beim OVPN-Server, "Remote Access" als Server Mode gewählt. Das führt offensichtlich dazu, dass der verbundene Client auf das Remote-Netz (das lokale Netz auf der Serverseite) zugriff hat. Im Normalfall wäre das beispielsweise jemand, der mit seinem OVPN Client aus einem Arbeitsrechner eine Verbindung aufbaut - um auf entfernte Ressourcen zuzugreifen. Da ich aber eine PfSense als Client verwende, funktioniert natürlich auch der Ping von der PfSense (OVPN Client) aus. Jedoch nicht von den dahinterliegenden Clients. Die Rechner aus dem lokalen Netz des OVPN Servers, konnten auch den OVPN Client (10.254.1.6) erreichen, aber nicht sein lokales Netzwerk. Dafür ist der "Peer to Peer" Modus notwendig.

Mit dieser Einstellung - und den weiteren Konfigurationen bezüglich der "Client Specific Overrides" - funktioniert nun ein gegenseitiges erreichen der lokalen Netze untereinander.

Durch das Umstellen auf "Peer to Peer", kann in der PfSense danach zusätzlich das "Remote Network" eingetragen werden.
ad35a78d250d5f91a6a483296d6184c1 - Klicke auf das Bild, um es zu vergrößern

Ich muss jetzt nun einfach noch prüfen, wie das aussieht, wenn weitere lokale Netze vorhanden sind. Ich denke diese sollten problemlos mit der "Advanced configuration" mitgegeben werden können.

Danke für eure Hilfe.

Kaioshin
Bitte warten ..
Mitglied: RicoPausB
01.10.2015 um 18:00 Uhr
Das ganze funktioniert auch mit Remote-Access ...
Allerdings muss dann in der Advanced Config eine route eingetragen werden ...
z.B.: route 192.168.0.0 255.255.0.0

ich vermute, im Modus "Remote Access" greift der iroute-Eintrag in den overrides nicht ...
Bitte warten ..
Mitglied: aqui
02.10.2015, aktualisiert um 15:53 Uhr
PfSense als Client verwende, funktioniert natürlich auch der Ping von der PfSense (OVPN Client) aus. Jedoch nicht von den dahinterliegenden Clients.
Ist ja auch klar, denn dafür müsste die pfSense die Routen in diese IP Netze kennen, was sie aber im Client Mode nicht kann.
Wie du richtig schreibst kennt sie dann nur das remote lokale IP Netz.
Hier musst du logischerweise mit zusätzlichen Routen dafür sorgen das der Client oder der Gegenpart auf der anderen Seite diese IP netze auch in den Tunnel routet.
Dazu ist immer die Routing Tabelle der pfSense hilfreich und der erste Anlaufpunkt (unter "Diagnostics)
Die Tabelle sagt immer wie alle IP Netze die die pfSense kennt zu erreichen sind und über welches Interface.
Fehlen da Routen hast du ein Konfig Problem....wie immer.
Dafür ist der "Peer to Peer" Modus notwendig.
Sehr richtig ! Bei einer LAN zu LAN Kopplung ist das zwingend.
wie das aussieht, wenn weitere lokale Netze vorhanden sind.
Wie gesagt..Advanced mit route oder zusätzliche statische Route ! Noch pfiffiger ist es wenn du mit RIPv2 oder OSPF dynamisch routest dann spart man sich die Frickelei mit den statischen Routen.
Gut wenn nun alles rennt wie es soll
Bitte warten ..
Neuester Wissensbeitrag
Internet

Unbemerkt - Telekom Netzumschaltung! - BNG - Broadband Network Gateway

(3)

Erfahrungsbericht von ashnod zum Thema Internet ...

Ähnliche Inhalte
Netzwerkgrundlagen
Routen bei openvpn (4)

Frage von davman zum Thema Netzwerkgrundlagen ...

Firewall
gelöst PFSense Squid Proxy über OpenVpn Verbindung nutzen (4)

Frage von horstvogel zum Thema Firewall ...

Firewall
Pfsense OpenVPN - MultWAN nur als Failover (1)

Frage von Otto1699 zum Thema Firewall ...

Heiß diskutierte Inhalte
Switche und Hubs
Trunk für 2xCisco Switch. Wo liegt der Fehler? (15)

Frage von JayyyH zum Thema Switche und Hubs ...

DSL, VDSL
DSL-Signal bewerten (13)

Frage von SarekHL zum Thema DSL, VDSL ...