Routing Denkfehler ? wo liegt der Wurm?
Hi Leute,
ich steh grad auf dem Schlauch und finde den Wurm nicht. Hoffe ihr könnt weiterhelfen. Folgendes Setup:
Heim-Netz: 10.20.30.0/24
Internet-Router Fritzbox: 10.20.30.1
Linksys WRT54GL mit OpenWRT BackFire: 10.20.30.2
Der Linksys WRT54GL hat OpenVPN am Laufen und stellt eine Verbindung zu einem entfernten Netz her. Das entfernte LAN hat 192.168.0.0/24.
Wenn ich mich per SSH auf dem WRT54GL einlogge, dann geht wie erwartet das OpenVPN, denn das wirde laut logfiles auch problemlos und wie erwartet korrekt aufgebaut. Ping 192.168.0.0/24 ist positiv. Vom WRT54GL, der ja die IP 10.20.30.2 besitzt kann ich auch alle Clients aus dem Heimnetz 10.20.30.0/24 anpingen, logisch.
Vom Heimnetz kann ich auch den Linksys WRT54GL anpingen. Zur Fehlersuche habe ich auf dem WRT54GL mit "/etc/init.d/firewall stop" die Firewall abgeschaltet. "iptables -L" bestätigt mir dies.
Das Problem --> Die Clients aus dem Heim-Netz 10.20.30.0/24 gelangen nicht auf das entfernte Netz 192.168.0.0/24, obwohl ich auf der Fritzbox eine statische Route eingetragen habe:
Netz: 192.168.0.0
Maske: 255.255.255.0
Router/Gateway: 10.20.30.2
Wenn ich an einem Client aus dem Heimnetz "traceroute" ausführe, dann sehe ich aber, dass der Ping an den 10.20.30.2 korrekt geleitet wird, aber es kommt nie eine Antwort an. Ich habe anfangs gedacht, dass die Fritzbox evtl. nicht korrekt rüberroutet um alle Anfragen an 192.168.0.0/24 über das Gateway 10.20.30.2 abzuwickeln. Also habe ich testweise auch einfach auf meinem PC (Heim-Netz) manuell mein routing-table angepasst und die Route zum 192.168.0.0/24 Netz über 10.20.30.2 eingegeben. Das hilft jedoch auch nicht, ich denke das Problem liegt irgendwie am Linksys WRT54GL, ich versteh aber nicht warum?!
Die /etc/config/network auf dem Linksys WRT54GL sieht so aus:
route -n zeigt mir auf dem WRT54GL das hier an:
ich seh keinen Fehler. Hoffe ihr könnt weiterhelfen. Danke!
ich steh grad auf dem Schlauch und finde den Wurm nicht. Hoffe ihr könnt weiterhelfen. Folgendes Setup:
Heim-Netz: 10.20.30.0/24
Internet-Router Fritzbox: 10.20.30.1
Linksys WRT54GL mit OpenWRT BackFire: 10.20.30.2
Der Linksys WRT54GL hat OpenVPN am Laufen und stellt eine Verbindung zu einem entfernten Netz her. Das entfernte LAN hat 192.168.0.0/24.
Wenn ich mich per SSH auf dem WRT54GL einlogge, dann geht wie erwartet das OpenVPN, denn das wirde laut logfiles auch problemlos und wie erwartet korrekt aufgebaut. Ping 192.168.0.0/24 ist positiv. Vom WRT54GL, der ja die IP 10.20.30.2 besitzt kann ich auch alle Clients aus dem Heimnetz 10.20.30.0/24 anpingen, logisch.
Vom Heimnetz kann ich auch den Linksys WRT54GL anpingen. Zur Fehlersuche habe ich auf dem WRT54GL mit "/etc/init.d/firewall stop" die Firewall abgeschaltet. "iptables -L" bestätigt mir dies.
Das Problem --> Die Clients aus dem Heim-Netz 10.20.30.0/24 gelangen nicht auf das entfernte Netz 192.168.0.0/24, obwohl ich auf der Fritzbox eine statische Route eingetragen habe:
Netz: 192.168.0.0
Maske: 255.255.255.0
Router/Gateway: 10.20.30.2
Wenn ich an einem Client aus dem Heimnetz "traceroute" ausführe, dann sehe ich aber, dass der Ping an den 10.20.30.2 korrekt geleitet wird, aber es kommt nie eine Antwort an. Ich habe anfangs gedacht, dass die Fritzbox evtl. nicht korrekt rüberroutet um alle Anfragen an 192.168.0.0/24 über das Gateway 10.20.30.2 abzuwickeln. Also habe ich testweise auch einfach auf meinem PC (Heim-Netz) manuell mein routing-table angepasst und die Route zum 192.168.0.0/24 Netz über 10.20.30.2 eingegeben. Das hilft jedoch auch nicht, ich denke das Problem liegt irgendwie am Linksys WRT54GL, ich versteh aber nicht warum?!
Die /etc/config/network auf dem Linksys WRT54GL sieht so aus:
config 'switch' 'eth0'
option 'enable' '1'
config 'switch_vlan' 'eth0_0'
option 'device' 'eth0'
option 'vlan' '0'
option 'ports' '0 1 2 3 5'
config 'switch_vlan' 'eth0_1'
option 'device' 'eth0'
option 'vlan' '1'
option 'ports' '4 5'
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'lan'
option 'type' 'bridge'
option '_orig_ifname' 'eth0.0 wlan0'
option '_orig_bridge' 'true'
option 'ifname' 'eth0.0'
option 'proto' 'static'
option 'ipaddr' '10.20.30.2'
option 'netmask' '255.255.255.0'
option 'gateway' '10.20.30.1'
option 'dns' '10.20.30.1'
config 'interface' 'wan'
option '_orig_ifname' 'eth0.1'
option '_orig_bridge' 'false'
option 'proto' 'dhcp'
route -n zeigt mir auf dem WRT54GL das hier an:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.1 10.10.10.5 255.255.255.255 UGH 0 0 0 tun0
10.10.10.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.0.0 10.10.10.5 255.255.255.0 UG 0 0 0 tun0
10.20.30.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
0.0.0.0 10.20.30.1 0.0.0.0 UG 0 0 0 br-lan
ich seh keinen Fehler. Hoffe ihr könnt weiterhelfen. Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 201896
Url: https://administrator.de/contentid/201896
Ausgedruckt am: 25.11.2024 um 21:11 Uhr
30 Kommentare
Neuester Kommentar
Werden die Pakete von deinem LAN ins entfernte Netz geNATet?
Falls nicht: Kennen die Clients im entfernten LAN eine Route zu deinem 10er-Netz?
Für die Fehlersuche bietet sich hier auch ein Packetsniffer wie tcpdump an, den du auf dem WRT-Router auf dem Tunnelinterface lauschen lässt.
Der Befehlsaufruf wäre:
Damit kannst du sehen, ob die Pakete von dir aus überhaupt in den Tunnel geschickt werden und ob überhaupt Antwortpakete zurückkommen. Da du auch die Pakete siehst, die von einer Firewall blockiert werden, solltest du also diese Probleme alle ausschließen können.
Denkbare Fehler wären:
- Pakete werden auf dem Tunnel-Interface garnicht weitergeleitet (IP-Forwarding)
- Die Clients im anderen LAN nutzen einen falschen Router um die Antwortpakete zu schicken
- Firewalls im entfernten LAN verhindern die Kommunikation mit dir
Falls nicht: Kennen die Clients im entfernten LAN eine Route zu deinem 10er-Netz?
Für die Fehlersuche bietet sich hier auch ein Packetsniffer wie tcpdump an, den du auf dem WRT-Router auf dem Tunnelinterface lauschen lässt.
Der Befehlsaufruf wäre:
tcpdump -i tun0 -n
Damit kannst du sehen, ob die Pakete von dir aus überhaupt in den Tunnel geschickt werden und ob überhaupt Antwortpakete zurückkommen. Da du auch die Pakete siehst, die von einer Firewall blockiert werden, solltest du also diese Probleme alle ausschließen können.
Denkbare Fehler wären:
- Pakete werden auf dem Tunnel-Interface garnicht weitergeleitet (IP-Forwarding)
- Die Clients im anderen LAN nutzen einen falschen Router um die Antwortpakete zu schicken
- Firewalls im entfernten LAN verhindern die Kommunikation mit dir
Hallo panguu,
entschuldige, aber was sich mir noch nicht erschließt ist folgendes;
1. - ist auf der einen Seite die Fritz!Box und auf der anderen Seite der Linksys Router mit OpenWRT oder
2. - ist auf der einen Seite die Fritz!Box und dahinter der Linksys mit OpenWRT und auf der anderen Seite das
192.168.0.0/24 Netz?
Gruß
Dobby
entschuldige, aber was sich mir noch nicht erschließt ist folgendes;
1. - ist auf der einen Seite die Fritz!Box und auf der anderen Seite der Linksys Router mit OpenWRT oder
2. - ist auf der einen Seite die Fritz!Box und dahinter der Linksys mit OpenWRT und auf der anderen Seite das
192.168.0.0/24 Netz?
Gruß
Dobby
Hi,
wie D.o.b.b.y schon zum Ausdruck bringt, das ganze ist wirklich etwas undurchsichtig geschrieben.
Vielleicht würde ja ein Bild des Netzwerkaufbaus etwas zur Klärung beitragen...
@ Skarden
laut Routingtabelle 10.10.10.5 tun0
also der OpenVPN-Tunnel. Hast Du wohl überlesen.
Gruß orcape
wie D.o.b.b.y schon zum Ausdruck bringt, das ganze ist wirklich etwas undurchsichtig geschrieben.
Vielleicht würde ja ein Bild des Netzwerkaufbaus etwas zur Klärung beitragen...
@ Skarden
laut Routingtabelle 10.10.10.5 tun0
also der OpenVPN-Tunnel. Hast Du wohl überlesen.
In deinem Text ist dieses Netz aber nicht erwähnt.
Damit hast Du natürlich Recht.Gruß orcape
Wenn die Clients die FB als Default Router haben muss dort eine statische Route auf das remote Netz eingetragen sein mit next Hop auf den OpenFire (OVPN) Router !
Dieses Tutorial (Router hinter NAT Router) beantwortet alle deine Fragen zu dem Thema:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Dieses Tutorial (Router hinter NAT Router) beantwortet alle deine Fragen zu dem Thema:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ich seh den Holzwurm nicht
..aber ich, habe mir fast die Zähne daran ausgebissen .Das gleiche Problem hatte ich auch, nur mit einer anderen Serversoftware.
Dein Tunnelnetz ist 10.10.10.0/24 und du hast pro Seite je 2 IP´s.
10.10.10.1 / 10.10.10.2 Serverseite
10.10.10.5 / 10.10.10.6 Clientseite
Dir fehlt der iroute-Befehl in der Server-config.
Der macht aus dem Netz dann...
10.10.10.1 Serverseite
10.10.10.2 Clientseite
Also folgenden Befehl in die Serverconfig...
iroute 10.20.30.0 255.255.255.0
Dann klappt´s auch mit dem Nachbarn...Gruß orcape
Ist irgendwie unverständlich, denn das was du da beschreibst ist das klassische Standardverhalten von OVPN und hat nichts mit Multiclient usw. zu tun.
Man will ja gerade mehrere Clients mit dem OVPN Server bedienen also ein simples und klasssichen VPN Dialin Verfahren wie es seit Jahren Standard ist.
Richtet man es so ein bekommen alle sich einwählenden VPN Clients eine 32 Bit Hostadresse aus dem internen OVPN Server IP Netz, da muss man keinerlei DHCP oder anderes konfigurieren. Keine Ahnung was du da meinst oder machst, das ist unverständlich, denn es erfordert keine separaten IPs pro Client.
Normalerweise ist in so einem Standard Dialin VPN Netz die Client to Client Kommunikation per Default untersagt, mit einem einzigen Kommando in der Server Konfig kann man das aber erlauben.
Anders sieht die Sache aus wenn du jedem Client ein eigenes internes IP Netzwerk geben willst. Eigentlich unsinnig für ein normales "Road Worrior" VPN Netz aber machbar wenn man es denn unbedingt will.
Dann und nur dann, muss man mit iroute arbeiten, damit der jeweilige Client diese internen IP Netze der anderen Clients kennenlernt...logisch
In einer simplen Standard Konfig ist das aber überflüssig wenn die interne Server IP Netsmake entsprechend groß gewählt ist für die max. Anzahl an Clients.
Man will ja gerade mehrere Clients mit dem OVPN Server bedienen also ein simples und klasssichen VPN Dialin Verfahren wie es seit Jahren Standard ist.
Richtet man es so ein bekommen alle sich einwählenden VPN Clients eine 32 Bit Hostadresse aus dem internen OVPN Server IP Netz, da muss man keinerlei DHCP oder anderes konfigurieren. Keine Ahnung was du da meinst oder machst, das ist unverständlich, denn es erfordert keine separaten IPs pro Client.
Normalerweise ist in so einem Standard Dialin VPN Netz die Client to Client Kommunikation per Default untersagt, mit einem einzigen Kommando in der Server Konfig kann man das aber erlauben.
Anders sieht die Sache aus wenn du jedem Client ein eigenes internes IP Netzwerk geben willst. Eigentlich unsinnig für ein normales "Road Worrior" VPN Netz aber machbar wenn man es denn unbedingt will.
Dann und nur dann, muss man mit iroute arbeiten, damit der jeweilige Client diese internen IP Netze der anderen Clients kennenlernt...logisch
In einer simplen Standard Konfig ist das aber überflüssig wenn die interne Server IP Netsmake entsprechend groß gewählt ist für die max. Anzahl an Clients.
Das mag ja alles richtig sein aber es bleibt die Frage warum du das umständlich mit dem Pool und den separaten Netzen so machst ?
Wie gesagt auch bei 2.0 ist das überflüssig und muss de facto nicht sein !
Eine simple Server Konfig wie:
port 1194
proto udp
dev tun0
server 10.8.0.0 255.255.0.0
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
erreicht exakt das gleich ohne iroute, dev tap Konfig und den ganzen Firlefanz. Das kannst du auch im Quick Start Guide von OVPN genau so nachlesen. Irgendwie ist dein Punkt hier nicht verständlich...sorry.
Wie gesagt auch bei 2.0 ist das überflüssig und muss de facto nicht sein !
Eine simple Server Konfig wie:
port 1194
proto udp
dev tun0
server 10.8.0.0 255.255.0.0
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
erreicht exakt das gleich ohne iroute, dev tap Konfig und den ganzen Firlefanz. Das kannst du auch im Quick Start Guide von OVPN genau so nachlesen. Irgendwie ist dein Punkt hier nicht verständlich...sorry.
Hallo Ihr beiden,
habe gerade mal bei meiner pfSense Version 2.0.2,
OpenVPN Point-to-Point, Gegenstelle als OpenVPN-Client, jeweils WRT54GL und E3000 mit DD-WRT.
(2 Tunnelnetze 2 OpenVPN-Server/ also kein Multiclient)
bei einem der beiden Tunnel bei "Client Specific Overrides" den iroute-Eintrag auskommentiert.
Ergebnis, der Tunnel baut sich ganz normal auf, aber eine Verbindung ins remote Netz ist nicht mehr möglich.
Das war genau das Problem, warum ich mir über mehr als einen Tag die Zähne habe ausgebissen.
Aqui, vielleicht kannst Du mich da aufklären.
Dem Server ist ja das remote Netz durch den Eintrag in der Serverconfig bereits bekannt und trotzdem funktioniert die LAN-to-LAN Verbindung nur in Richtung Server.
Erst mit dem iroute-Eintrag ist ein direkter Zugriff auf´s remote LAN möglich, ohne irgendwelche Änderungen am Client-Router vorzunehmen.
Gruß orcape
kleiner Nachtrag...
Der iroute-Eintrag erscheint seltsamerweise nicht in den OpenVPN-Server-configs unter Diagnostics/Edit auf der pfSense. Dort steht nur der Route-Eintrag....
habe gerade mal bei meiner pfSense Version 2.0.2,
OpenVPN Point-to-Point, Gegenstelle als OpenVPN-Client, jeweils WRT54GL und E3000 mit DD-WRT.
(2 Tunnelnetze 2 OpenVPN-Server/ also kein Multiclient)
bei einem der beiden Tunnel bei "Client Specific Overrides" den iroute-Eintrag auskommentiert.
Ergebnis, der Tunnel baut sich ganz normal auf, aber eine Verbindung ins remote Netz ist nicht mehr möglich.
Das war genau das Problem, warum ich mir über mehr als einen Tag die Zähne habe ausgebissen.
Aqui, vielleicht kannst Du mich da aufklären.
Dem Server ist ja das remote Netz durch den Eintrag in der Serverconfig bereits bekannt und trotzdem funktioniert die LAN-to-LAN Verbindung nur in Richtung Server.
Erst mit dem iroute-Eintrag ist ein direkter Zugriff auf´s remote LAN möglich, ohne irgendwelche Änderungen am Client-Router vorzunehmen.
Gruß orcape
kleiner Nachtrag...
Der iroute-Eintrag erscheint seltsamerweise nicht in den OpenVPN-Server-configs unter Diagnostics/Edit auf der pfSense. Dort steht nur der Route-Eintrag....
Bei mir ist das analog auf einem DD-WRT mit WRT54 als HW Basis. Benutze die ganz einfache Konfig von oben und 3 (vermutlich auch 20) Clients können sich da problemlos ohne jegliches iroute oder was auch immer anmelden und im lokalen Netz was mit "push route" vom Server propagiert wird arbeiten.
Deshalb ist der ominöse "iroute" Befehl ja auch unverständlich, denn wenn man mit ipconfig oder ifconfig sich die Adressierung des Client tun/tap Tnterfaces ansieht dann sieht man das der Client immer eine IP aus dem internen Server IP Netzwerk bekommt.
Es ist daher ja gar kein Routing am Client erforderlich (außer natürlich das was per push route propagiert wird) In sofern ist es ja überflüssig zu routen innerhalb des Clinet Netzes sprich des internen OVPN Server IP Netzes.
Wie gesagt, das obige ist eine VPN Client Dialin Konfig (Roadworrior) und keine Site to Site VPN Konfig wo ein ganzes Netz hintersitzt...die aber nicht groß anders sein dürfte. Und die funktioniert aktuell ohne jegliches iroute Gefrickel...
Deshalb ist der ominöse "iroute" Befehl ja auch unverständlich, denn wenn man mit ipconfig oder ifconfig sich die Adressierung des Client tun/tap Tnterfaces ansieht dann sieht man das der Client immer eine IP aus dem internen Server IP Netzwerk bekommt.
Es ist daher ja gar kein Routing am Client erforderlich (außer natürlich das was per push route propagiert wird) In sofern ist es ja überflüssig zu routen innerhalb des Clinet Netzes sprich des internen OVPN Server IP Netzes.
Wie gesagt, das obige ist eine VPN Client Dialin Konfig (Roadworrior) und keine Site to Site VPN Konfig wo ein ganzes Netz hintersitzt...die aber nicht groß anders sein dürfte. Und die funktioniert aktuell ohne jegliches iroute Gefrickel...
Ja, eine Diskussion ist müssig, denn du nutzt ein falsches oder umständliches Setup mit OVPN was nicht sein muss, das ist Fakt und beschreibt auch der Quickstart Guide. Das hiesige Tutorial basiert da ebenfalls drauf und dort steht kein Wort mit iroute. Wozu auch es basiert ja auch einer aktuell sauber laufenden Installation.
Das es hier fehlerfrei ohne jegliche iroute Fricklei rennt für 10 VPN Clients sowohl auf WRT54 als auch einer pfSense Appliance ist denke ich Beweis genug, da muss man keine längeren Forums Diskussionen mehr führen...
Was immer du da konfigurieren willst oder musst, wenns für dich mit iroute klappt ist alles gut ! Der "normale" OVPN User benötigt es wenigstens nicht.
Das es hier fehlerfrei ohne jegliche iroute Fricklei rennt für 10 VPN Clients sowohl auf WRT54 als auch einer pfSense Appliance ist denke ich Beweis genug, da muss man keine längeren Forums Diskussionen mehr führen...
Was immer du da konfigurieren willst oder musst, wenns für dich mit iroute klappt ist alles gut ! Der "normale" OVPN User benötigt es wenigstens nicht.
Nein nochmals...und das ist das letzte Posting zu dem Thema hier ! Du hast mit keinerlei Silbe erwähnt WARUM du diese Konfigurations bevorzugst. Zweifelsohne hast du deine Gründe dafür !
Mir war nur wichtig klarzustellen, das es für ein simples "Road Worrior" VPN Dialin, also das sich remote Mitarbeiter einfach mit einem OVPN Client in einem lokales Netzwerk einwählen es dieser Konfiguration nicht bedarf !
Es ging keineswegs darum deine sicher vorhandenen Gründe dafür irgendwie abzuqualifizieren (obwohl du sie nie erklärt hast).
OVPN Ist ja per se ein "Multiclient" System. Es ist ja genauso absurd das du den Eindruck hier erweckst das man mit der einfachen OVPN Standardkonfig sich lediglich mit einem einzelnen VPN Client einwählen kann.
Das das Unsinn ist weisst du selber wie auch der Rest der OVPN Gemeinde hier. Wie gesagt hier rennt es mit 10 Clients und mehr und was wäre das denn ?? Ist das denn kein MultiClient ??
Wie gesagt es geht nicht um Sinn oder Unsinn. Fakt ist nur das man es für einen simplen remote Client Zugang für multiple eben NICHT braucht.
Nur darum ging es ! Nicht um eine Bewertung !
Mir war nur wichtig klarzustellen, das es für ein simples "Road Worrior" VPN Dialin, also das sich remote Mitarbeiter einfach mit einem OVPN Client in einem lokales Netzwerk einwählen es dieser Konfiguration nicht bedarf !
Es ging keineswegs darum deine sicher vorhandenen Gründe dafür irgendwie abzuqualifizieren (obwohl du sie nie erklärt hast).
OVPN Ist ja per se ein "Multiclient" System. Es ist ja genauso absurd das du den Eindruck hier erweckst das man mit der einfachen OVPN Standardkonfig sich lediglich mit einem einzelnen VPN Client einwählen kann.
Das das Unsinn ist weisst du selber wie auch der Rest der OVPN Gemeinde hier. Wie gesagt hier rennt es mit 10 Clients und mehr und was wäre das denn ?? Ist das denn kein MultiClient ??
Wie gesagt es geht nicht um Sinn oder Unsinn. Fakt ist nur das man es für einen simplen remote Client Zugang für multiple eben NICHT braucht.
Nur darum ging es ! Nicht um eine Bewertung !
Hi aqui,
Panguu hat in diesem Thread, von seinem ersten Post an, von einer OpenVPN Konfiguration gesprochen, bei der über ein tun-Device 2 Netzwerke verbunden werden sollen.
Die Definition von Multiclient ist wohl hier der Streitpunkt.
Ob sich hier 1 oder 30 einzelne Clients mit einem Servernetz verbinden, ist wohl irrelevant, genauso wie 1 oder 3 Router auf denen der OpenVPN-Client läuft.
Fakt ist, das ohne eine Anpassung mit dem iroute-Befehl auf den OpenVPN-Server, das LAN hinter einem OpenVPN-Client-Router nicht zu erreichen ist.
Zumindest hat es bei mir ohne dem nicht funktioniert.
Die von panguu verlinkte OpenVPN-Dokumentation bestätigt dieses.
Der iroute-Befehl aus dem GUI der pfsense, der dort nicht unter der Server.conf, sondern unter "Client Specific Overrides" einzutragen ist, findet sich übrigens nicht in der OpenVPN-Server.conf unter "/var/etc/openvpn/server.conf" wieder, sondern unter "/var/etc/openvpn-csc" .
Gruß orcape
Mir war nur wichtig klarzustellen, das es für ein simples
"Road Worrior" VPN Dialin, also das sich remote Mitarbeiter
einfach mit einem OVPN Client in einem lokales Netzwerk
einwählen es dieser Konfiguration nicht bedarf !
Sorry, aber klar das Thema verpasst."Road Worrior" VPN Dialin, also das sich remote Mitarbeiter
einfach mit einem OVPN Client in einem lokales Netzwerk
einwählen es dieser Konfiguration nicht bedarf !
Panguu hat in diesem Thread, von seinem ersten Post an, von einer OpenVPN Konfiguration gesprochen, bei der über ein tun-Device 2 Netzwerke verbunden werden sollen.
Die Definition von Multiclient ist wohl hier der Streitpunkt.
Ob sich hier 1 oder 30 einzelne Clients mit einem Servernetz verbinden, ist wohl irrelevant, genauso wie 1 oder 3 Router auf denen der OpenVPN-Client läuft.
Fakt ist, das ohne eine Anpassung mit dem iroute-Befehl auf den OpenVPN-Server, das LAN hinter einem OpenVPN-Client-Router nicht zu erreichen ist.
Zumindest hat es bei mir ohne dem nicht funktioniert.
Die von panguu verlinkte OpenVPN-Dokumentation bestätigt dieses.
Der iroute-Befehl aus dem GUI der pfsense, der dort nicht unter der Server.conf, sondern unter "Client Specific Overrides" einzutragen ist, findet sich übrigens nicht in der OpenVPN-Server.conf unter "/var/etc/openvpn/server.conf" wieder, sondern unter "/var/etc/openvpn-csc" .
Gruß orcape
Hallo zusammen,
normaler Weise schickt sich das nicht einen geschlossenen Beitrag nochmals anzuschreiben, aber hier gibt es eben auch eine Suchfunktion und man kann diesen Beitrag nach Jahren noch finden und dann kommen andere Leute evtl. auch in die so genannte Bedrängnis.
Orginal Text von @aqui:
Wenn Du (panguu) die statische Route gesetzt hättest wäre alles erledigt gewesen!
Wenn Du sie aber nicht setzt kann Dir iroute zwar helfen, aber dafür muss man eben auch immer zuerst wissen
wer ist hinter wem oder einfacher und genauer hinter welchem Gateway ist welches oder sogar welche Netzewerke und dafür ist iroute nun ja letztendlich da und daher habe auch ich gleich ganz oben mit gefragt wer, steht hinter wem oder wo genau! Das ist eine Bringschuld und keine "Kann ich ja mal machen Sache", denn Du @panguu hast doch hier das Problem oder nicht! Schon mal gehört: "Ein Bild sagt mehr als tausend Worte!" Wer sein Problem aber so gut beschreiben kann das es von jedem gleich verstanden wird und das
auch gleich noch ohne großes nachfragen benötigt so etwas natürlich nicht, in bin aber ganz klar der Meinung
das Du @panguu eben nicht zu denen gehörst.
So und hier nun noch einmal ein gutes und einfach verständliches Beispiel für OpenVPN mit iroute für alle die
diesen Beitrag in 10 Jahren finden und sonst auch noch denken sie müssen iroute unbedingt auf benutzen.
OpenVPN and iroute
Manchmal sind einige Lösungen für bestimmte Probleme eben nicht nur dafür einsetzbar, für die sie eigentlich
schrieben, implementiert oder angedacht worden sind, sondern man kann auch noch andere Probleme damit lösen,
aber ob das zum Einen immer sinnvoll ist bzw. auch gleich von allen verstanden wird steht auf einem ganz anderen Blatt Papier und zum Andren ob man sich das alles antun möchte ist die zweite Frage, denn eines ist
doch jetzt schon klar, wenn das Netzwerk wächst und/oder später mit VLANs die ein eigenes Subnetz beinhalten und/oder irgend etwas was heute noch nicht so ersichtlich ist dazu kommt wird es unweigerlich wieder zu Problemen kommen.
So und nun noch etwas in eigener Sache, es wäre ja mal schick wenn Du @panguu Dir noch einmal genau anschaust
und zwar in unter den bei Dir selber aufgeführten Links was denn ein Client ist und wie man so etwas eben
"glatt" und sauber löst und uns nicht noch anmachst bloß weil wir Dir helfen wollen.
normaler Weise schickt sich das nicht einen geschlossenen Beitrag nochmals anzuschreiben, aber hier gibt es eben auch eine Suchfunktion und man kann diesen Beitrag nach Jahren noch finden und dann kommen andere Leute evtl. auch in die so genannte Bedrängnis.
Orginal Text von @aqui:
Wenn die Clients die FB als Default Router haben muss dort eine statische Route auf das remote Netz eingetragen sein mit next Hop auf den OpenFire (OVPN) Router!
Wenn Du (panguu) die statische Route gesetzt hättest wäre alles erledigt gewesen!
Wenn Du sie aber nicht setzt kann Dir iroute zwar helfen, aber dafür muss man eben auch immer zuerst wissen
wer ist hinter wem oder einfacher und genauer hinter welchem Gateway ist welches oder sogar welche Netzewerke und dafür ist iroute nun ja letztendlich da und daher habe auch ich gleich ganz oben mit gefragt wer, steht hinter wem oder wo genau! Das ist eine Bringschuld und keine "Kann ich ja mal machen Sache", denn Du @panguu hast doch hier das Problem oder nicht! Schon mal gehört: "Ein Bild sagt mehr als tausend Worte!" Wer sein Problem aber so gut beschreiben kann das es von jedem gleich verstanden wird und das
auch gleich noch ohne großes nachfragen benötigt so etwas natürlich nicht, in bin aber ganz klar der Meinung
das Du @panguu eben nicht zu denen gehörst.
So und hier nun noch einmal ein gutes und einfach verständliches Beispiel für OpenVPN mit iroute für alle die
diesen Beitrag in 10 Jahren finden und sonst auch noch denken sie müssen iroute unbedingt auf benutzen.
OpenVPN and iroute
Manchmal sind einige Lösungen für bestimmte Probleme eben nicht nur dafür einsetzbar, für die sie eigentlich
schrieben, implementiert oder angedacht worden sind, sondern man kann auch noch andere Probleme damit lösen,
aber ob das zum Einen immer sinnvoll ist bzw. auch gleich von allen verstanden wird steht auf einem ganz anderen Blatt Papier und zum Andren ob man sich das alles antun möchte ist die zweite Frage, denn eines ist
doch jetzt schon klar, wenn das Netzwerk wächst und/oder später mit VLANs die ein eigenes Subnetz beinhalten und/oder irgend etwas was heute noch nicht so ersichtlich ist dazu kommt wird es unweigerlich wieder zu Problemen kommen.
So und nun noch etwas in eigener Sache, es wäre ja mal schick wenn Du @panguu Dir noch einmal genau anschaust
und zwar in unter den bei Dir selber aufgeführten Links was denn ein Client ist und wie man so etwas eben
"glatt" und sauber löst und uns nicht noch anmachst bloß weil wir Dir helfen wollen.
panguu,
es wäre schön, wenn du daraus mal eine Anleitung oder einen Tipp machst. Über die Suchfunktion findet man das nicht wieder.
Leo
es wäre schön, wenn du daraus mal eine Anleitung oder einen Tipp machst. Über die Suchfunktion findet man das nicht wieder.
Leo
Zur Klärung: OK, durch die vielen Beiträge ist das untergegangen das es sich nur um Site to Site Verbindungen handelt. Diese einzelnen Sites dann als "Clients" zu bezeichnen hat natürlich die Verwirrung komplettiert. Das es bei einer Site to Site Verbindung mit multiplen Sites ganz anders aussieht steht außer Frage !
Das war aber in der etwas "erhitzten" Diskussion nie ersichtlich, denn bei einem VPN mit rein mobilen Clients ist das nie erforderlich. Site to Site hingegen schon. OK, wer lesen kann....
Gut das Kollege Orcape das nochmal richtig gestellt hat bevor es eskaliert wäre
Das war aber in der etwas "erhitzten" Diskussion nie ersichtlich, denn bei einem VPN mit rein mobilen Clients ist das nie erforderlich. Site to Site hingegen schon. OK, wer lesen kann....
Gut das Kollege Orcape das nochmal richtig gestellt hat bevor es eskaliert wäre