panguu
Goto Top

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:
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!

Content-ID: 201896

Url: https://administrator.de/contentid/201896

Ausgedruckt am: 05.11.2024 um 08:11 Uhr

LordGurke
LordGurke 17.02.2013 um 18:43:08 Uhr
Goto Top
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:
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
orcape
orcape 17.02.2013 um 20:13:04 Uhr
Goto Top
Hi panguu,
was in Deinem angegebenen Daten fehlt, sind die Config Dateien des OpenVPN-Tunnels. Sowohl die Server-,wie auch die Client-config solltest Du posten. Weiterhin die remote Routing Tabelle.
Ist denn ein Ping vom Homenetz-Client auf das Tunnelende möglich?
Gruß orcape
Skarden
Skarden 17.02.2013 um 21:17:22 Uhr
Goto Top
Hallo,

in der aufgelisteten Routingtabelle steht für die 192.168.0.0 (entfernte Netz) die 10.10.10.5 drin.
In deinem Text ist dieses Netz aber nicht erwähnt.

Ist mir beim Überfliegen so aufgefallen

Gruß
Skarden
108012
108012 18.02.2013 um 04:45:55 Uhr
Goto Top
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
orcape
orcape 18.02.2013 um 06:51:45 Uhr
Goto Top
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. face-wink
In deinem Text ist dieses Netz aber nicht erwähnt.
Damit hast Du natürlich Recht.

Gruß orcape
aqui
aqui 18.02.2013 um 08:34:29 Uhr
Goto Top
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
panguu
panguu 18.02.2013 aktualisiert um 15:32:13 Uhr
Goto Top
Also, beide Linksys-WRT54GL stehen hinter den Internetroutern. Ich vesuch das zu veranschaulichen:


Site(A) 10.20.30.0/24---------------------------------------------------------------------------------------Site(B)192.168.0.0/24

WRT54GL 10.20.30.2 >> Internetrouter 10.20.30.1 <<==>> Internetrouter 192.168.0.1 << WRT54GL 192.168.0.2


Auf dem Internetrouter 10.20.30.1 habe ich zwei statische Routen eingetragen, und zwar:
192.168.0.0/24 via 10.20.30.2 und ebenso auch 10.10.10.0/24 via 10.20.30.2

Auf dem Internetrouter 192.168.0.1 habe ich zwei statische Routen eingetragen, und zwar:
10.20.30.0/24 via 192.168.0.2 und ebenso auch 10.10.10.0/24 via 192.168.0.2

Der Endpunkt auf Site(A) auf dem WRT54GL OpenVPN Router (client) hat die 10.10.10.6
Der Endpunkt auf Site(B) auf dem WRT54GL OpenVPN Router (server) hat die 10.10.10.1

OpenVPN wird im Multi-Client-Betrieb betrieben, hier die server-config auf site(B) 192.168.0.2:
port 12345
proto udp
dev tun
ca /etc/easy-rsa/keys/ca.crt
cert /etc/easy-rsa/keys/server.crt
key /etc/easy-rsa/keys/server.key
dh /etc/easy-rsa/keys/dh1024.pem
client-config-dir /etc/openvpn/clientcfgs
server 10.10.10.0 255.255.255.0
ifconfig-pool-persist /tmp/ipp.txt
route 10.20.30.0 255.255.255.0
push route 192.168.0.0 255.255.255.0
push dhcp-option DOMAIN intranet.siteB.de
push dhcp-option DNS 192.168.0.100
push dhcp-option WINS 192.168.0.100
comp-lzo
persist-key
persist-tun
user nobody

Und hier die OpenVPN-Config des OpenVPN-Clients aus siteA 10.20.30.2:
tls-client
proto udp
dev tun
nobind
ns-cert-type server
remote siteB.dyndns.org 12345
resolv-retry infinite
pkcs12 /etc/openvpn/mycredentials.p12
pull
comp-lzo
persist-key
persist-tun
script-security 2

Routing-Table des OpenVPN-Routers 10.20.30.2 auf SiteA:
# 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

Routing-Table des OpenVPN-Routers 192.168.0.2 auf SiteB:
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
10.20.30.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 br-lan

Auf beiden OpenVPN-Routern (Linksys WRT54GL) habe ich "/etc/init.d/firewall stop" abgesetzt und mit "iptables -L" vergewissert, dass keine FW aktiv ist. Auf SiteB habe ich sämtlich Firewalls und IntrusionDetection Systeme ausgeschaltet, auf SiteA gibts das nicht, weil dort die FritzBox als Internetrouter eingesetzt wird. Ich kann leider das Paket tcpdump mit "opkg install tcpdump" auf den OpenVPN-Routern nicht finden und installieren, gibts wohl nicht? Dort läuft die aktuellste OpenWRT Version.

Ping-Tests vom OpenVPN-Router 10.20.30.2 auf SiteA:
- ich kann den OpenVPN-server Endpunkt anpingen, Ping auf 10.10.10.1 POSITIV
- ich kann sämtliche Hosts aus dem Netz SiteB anpingen, Ping auf 192.168.0.* POSITIV

Ping-Tests vom OpenVPN-Router 192.168.0.2 auf SiteB:
- ich kann den OpenVPN-Client Endpunkt anpingen, Ping auf 10.10.10.6 POSITIV
- ich kann KEINE weiteren Hosts auf SiteA anpingen, Ping auf 10.20.30.* NEGATIV

Ich seh den Holzwurm nicht face-smile
panguu
panguu 18.02.2013 aktualisiert um 15:47:25 Uhr
Goto Top
HURRRAAA!!! Hab den Wurm gefunden. Es war ein Typo von einem einzigen Buchstaben, und zwar in dem client-config-dir das für den Multi-Server-Betrieb des OpenVPN verwendet wird. Dort hatte ich im Dateinamen einen typo-Fehler stehen in der Datei, somit konnte die Zuordnung nicht erfolgen, und entsprechend der iroute Befehl nicht gesendet werden. Maaaaannnn, das hat mich einen ganzen Tag gekostet, uaaaah face-smile

Hauptsache Problem gelöst. Dank hochschrauben des debug levels und Logfile auf server-side.

Dennoch danke für eure Hilfestellungen, thanks to all!!!
orcape
orcape 18.02.2013 um 16:17:58 Uhr
Goto Top
Ich seh den Holzwurm nicht face-smile
..aber ich, habe mir fast die Zähne daran ausgebissen face-wink.
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...face-wink
Gruß orcape
aqui
aqui 18.02.2013 um 17:33:19 Uhr
Goto Top
Muss er eigentlich nicht, denn seine Netze sind eindeutig.
Intern im Tunnel werden per Default /32er Masken benutzt (sofern nicht anderes eingestellt)
Normalerweise muss man also nix machen mit iroute usw.
Mit dem Typo ist das ja dann auch gefixt wenn man es richtig versteht..?!
panguu
panguu 18.02.2013 um 18:13:31 Uhr
Goto Top
@aqui: doch, orcape hat Recht. iroute MUSS sein! Das Thema hatten wir doch schonmal, wenn du/ihr euch erinnert:
Fragen zu OpenVPN unter OpenWRT
Das ist dieses Multi-Server-Modell in OpenVPN.

@orcape: Ja genau richtig! Gut aufgepasst ;) ich hatte mir auch schon den Wolf abgesucht, hehe. Und alles wegen nur einem Buchstabendreher innerhalb meines client-config-dirs, argh!

Letztendlich hat's aber doch noch geklappt *freu*
orcape
orcape 18.02.2013 um 19:25:53 Uhr
Goto Top
Hi panguu,
habe mich auch schon fast dämlich gesucht, wegen so einer Kleinigkeit.
Da zweifelt man schon manchmal an sich selbst.
Aber einmal die Woche braucht man auch ein Erfolgserlebnis. face-wink
Gruß orcape
aqui
aqui 19.02.2013 um 10:00:32 Uhr
Goto Top
Mit "Multi Server" meinst du dann das du aus Redundanzgründen 2 OVPN Server hast, ist das so richtig ?
Wenn ja dann stimmt das natürlich, sorry war wieder zuviel Zeit dazwischen face-wink
panguu
panguu 19.02.2013 aktualisiert um 10:50:59 Uhr
Goto Top
Hi aqui,

nein, es ist nur ein einzelner OpenVPN-Server. Aber du kannst diesen im Multiclient-Betrieb (als Roadwarrior) betreiben. Das heisst es läuft ein interner DHCP-Server auf dem OpenVPN-Server, und es können sich gleichzeitig mehrere VPN-Clients andocken. Jeder VPN-Client bekommt dabei seinen eigenen Adressbereich vom Server zugeteilt, und die Abwicklung erfolgt dabei durch iroute, das ist zwingend notwendig. Nähere Infos hatte ich damals bereits in meinem anderen Beitrag gepostet (siehe Fragen zu OpenVPN unter OpenWRT)

Ich zitiere mich selbst:

durch den Eintrag

server 10.8.0.0 255.255.255.0

OpenVPN teilt das virtuelle Netzwerk 10.8.0.0/255.255.255.0 in viele kleinere Netzwerke auf, die aus 4 IP-Adressen bestehen. (256 / 4 = 64 Subnets/Clients maximal, wobei das erste Subnet für OpenVPN selbst reserviert ist) Die Subnetmask der Netzwerke ist immer 255.255.255.252 oder in Kurzschreibweise /30.

Erstes Minisubnet:

10.8.0.0 = Netzwerkadresse
10.8.0.1 = VPN-Server
10.8.0.2 = virtueller Endpunkt B
10.8.0.3 = Broadcastadresse

Das nächste Minisubnet:

10.8.0.4 = Netzwerkadresse
10.8.0.5 = Gateway zu OpenVPN (Endpunkt A)
10.8.0.6 = Client-IP (Endpunkt B)
10.8.0.7 = Broadcastadresse

http://openvpn.net/index.php/open-source/documentation/howto.html

http://openvpn.net/index.php/open-source/documentation/manuals/65-openv ...

Suchbegriff "--server network netmask"

Viele Grüße,
Pangu
aqui
aqui 19.02.2013 aktualisiert um 11:17:01 Uhr
Goto Top
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.
panguu
panguu 19.02.2013 um 11:29:38 Uhr
Goto Top
Nochmal: es ist kein standard-Verhalten bei OpenVPN. Der Multiclient-Betrieb wird durch folgende Direktive initiiert. Natürlich können durch OpenVPN mehrere Clients abgewickelt werden, aber durch diesen Modus erfolgt das auf eine ganz andere Art, und zwar indem Teilnetze (kleine Subnetze von OpenVPN und dessen initiierten DHCP-Server dafür initiiert werden!) Dieses Modell gibts erst ab OpenVPN Version 2.x
Was du beschreibst ist das klassische Modell, aber ich rede hier von einem anderen, und zwar nennt sich das eben nunmal Multi-Client Modell und du kannst es in jeder OpenVPN Doku nachlesen. Zur Hilfe: Aus meinem letzten Beitrag, der letzte Link, dort nach --server network netmask suchen, ergibt das hier:

Server Mode
Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode is supported, and can be enabled with the --mode server option. In server mode, OpenVPN will listen on a single port for incoming client connections. All client connections will be routed through a single tun or tap interface. This mode is designed for scalability and should be able to support hundreds or even thousands of clients on sufficiently fast hardware. SSL/TLS authentication must be used in this mode.

--server network netmask
A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.

For example, --server 10.8.0.0 255.255.255.0 expands as follows:


mode server
tls-server

if dev tun:
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool 10.8.0.4 10.8.0.251
route 10.8.0.0 255.255.255.0
if client-to-client:
push "route 10.8.0.0 255.255.255.0"
else
push "route 10.8.0.1"

if dev tap:
ifconfig 10.8.0.1 255.255.255.0
ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
push "route-gateway 10.8.0.1"

Und weswegen iroute steht hier beschrieben --> http://backreference.org/2009/11/15/openvpn-and-iroute/

Aber die ganze Diskussion hatten wir doch schonmal, ich erinnere nochmal --> Fragen zu OpenVPN unter OpenWRT

Grüße,
Pangu.
aqui
aqui 19.02.2013 aktualisiert um 11:36:34 Uhr
Goto Top
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.
panguu
panguu 19.02.2013 um 11:41:23 Uhr
Goto Top
der ledigliche "route"-Befehl wickelt den Verkehr zwischen Kernel und VPN-Server ab, wogegen "iroute" den Verkehr zwischen dem Server und den jeweiligen Clients leitet.

Steht doch alles in der offiziellen OpenVPN-HowTo aufrufen unter den Link --> http://openvpn.net/index.php/open-source/documentation/howto.html

und dort nach Including multiple machines on the client side when using a routed VPN (dev tun) suchen

Da werden alle Fragen beantwortet.

Gruß,
Pangu
orcape
orcape 19.02.2013 aktualisiert um 14:29:57 Uhr
Goto Top
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....
aqui
aqui 19.02.2013 aktualisiert um 14:31:30 Uhr
Goto Top
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...
panguu
panguu 19.02.2013 aktualisiert um 22:52:33 Uhr
Goto Top
Aqui, glaubst du wirklich, OpenVPN baut eine Funktion ein, die man hätte gar nicht benötigt? du hast es wohl entweder noch nicht durchgelesen, oder nicht verstanden. Ich erspar mir daher, noch irgendwas zu verlinken wo das deutlich beschrieben wird.
aqui
aqui 20.02.2013 aktualisiert um 12:07:05 Uhr
Goto Top
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.
panguu
panguu 20.02.2013 um 13:32:39 Uhr
Goto Top
Lieber aqui, das eine hat mit dem anderen nichts zu tun. Du stellst hier in den Raum, dass iroute und dass das Multiclient-modell von OpenVPN totaler Schwachsinn und kein Mensch benötige. Und das nur, weil du es nicht benötigst, nicht begreifst, oder nicht begreifen möchtest. Das ist so, als ob du behauptest kein Mensch braucht eine Gabel in der Küche, weil man eh töglich Suppe ißt. Das ist doch absurd und absolut lächerlich. Es geht hier nicht darum was DU brauchst oder für angemessen hältst, sondern darum dass es eben ein Multiclient-Modell von OpenVPN gibt, dieses ausagekräftig seitens Hersteller ausreichend dokumentiert ist, und dass auch weltweit wie beschrieben unter bestimmten Voraussetzungen eingesetzt wird. Wenn du es nicht brauchst, schön, dann lass es einfach. Aber werfe bitte nicht in den Raum, dass es Schwachsinn wäre und total irrelevant ist, denn du hast wirklich nicht verstanden wozu es das gibt. Du kannst aber gerne den developern von OpenVPN eine Nachricht mit deiner Meinung zukommen lassen, viel Erfolg!
aqui
aqui 20.02.2013 um 16:58:40 Uhr
Goto Top
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 !
panguu
panguu 20.02.2013 um 17:38:44 Uhr
Goto Top
Anhand meines Postings ganz am Anfang erkläre und verdeutliche ich deutlich, dass ich mit verschiedenen Clients aus dem Heim-Netz aus, Hosts ins entfernte Netz erreichen möchte. Dazu habe ich auch genau den Aufbau der Router beschrieben und alle hierzu notwendigen Details geliefert. Hier wird sofort klar, dass ich nicht von einem Dial-In-Blabla-Szenario rede wie du hier ständig immer wiederholst. Ich möchte ALLEN meinen Clients aus dem Heimnetz erlauben, Hosts aus dem Remotenetzwerk zu erreichen. Und da wirklich einfach nur stur oder zu faul zum Lesen bist, poste ich hier nochmal aus der Original OPENVPN-HOWTO die Erklärung hierzu:

Including multiple machines on the client side when using a routed VPN (dev tun)

In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate ("client2" in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"

This will cause the OpenVPN server to advertise client2's subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.


Am besten du scrollst nochmal hoch, liest dir mein Ursprungspost durch und merkst hoffentlich, was du hier zu diesem Thema gepostet hast. Nix für ungut, bei allem Respekt liber aqui. Ich kenne deine OpenVPN-HowTo, aber lies dir bitte genau das Problem durch, und poste nicht immer gleich einfach dein Link zur HowTo. Du wimmelst hier die Antworten der anderen helfenden User ab, nur weil du es a.) nicht verstehen willst, oder b.) dich stur stellst und es verbal so hindrehst, dass es eh kein Mensch braucht. Meine Frage bezieht sich auf die Thematik XYZ und weils dir nicht reinpasst gibst du deinen Senf dazu ab. Was soll man(n) denn dazu denken? Das ist wirklich lächerlich, ganz ehrlich! In diesem Sinne hab ich dir wirklich nicht meht dazu sagen, ich hab dir jetzt schon zig mal die ofiziellen Erklärungen zu diesem Thema seitens OpenVPN gepostet. Mach was du für richtig hältst, nur weiter so...

Und nochmals, danke an den Rest. Schönen Abend an Alle
orcape
orcape 20.02.2013 aktualisiert um 20:22:44 Uhr
Goto Top
Hi aqui,
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.
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
108012
108012 21.02.2013 um 05:17:50 Uhr
Goto Top
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 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
panguu 21.02.2013 aktualisiert um 10:10:53 Uhr
Goto Top
@108012:

- die statische Route WAR gesetzt ! Das steht auch in meinem Ursprungspost drin! wer lesen kann ist klar im Vorteil

- ich versuche so genau wie möglich mein Problem zu beschreiben und zu illustrieren. Nachdem das angeblich eurer Meinung nicht der Fall war, habe ich es nochmals verdeutlicht. Einfach mal hochscrollen und dir meine Postings mit all den Configs und Details durchlesen. Du kannst mir das also nicht unterstellen. Vielmehr merke ich, dass du hier auch vom Thema abschweifst und persönlich wirst. Das eine hat aber mit dem anderen nichts zu tun.

- den Link mit dem iRoute, den du hier postest kenne ich, denn ich hab ihn bereits in meinem letzten Beitrag zu dieser Angelegenheit (siehe --> Fragen zu OpenVPN unter OpenWRT) durch Recherche entdeckt gehabt und auch damals gleich gepostet. Dass du mir jetzt diesen gleichen Link nochmal präsentiert, wow ich bin gerührt.

- ich mach hier keinen an weil er mir helfen möchte, im Gegenteil: ich bedanke mich für die Hilfe. Aber du scheinst wohl ein ganz anderes Problem mit mir oder allgemeiner Natur zu haben und machst mich grad dumm an. Deine Art, wie du auf Beiträge antwortest habe ich bereits des Öfteren bemerkt und hast es auch in dem letzten Beitrag zu der OpenVPN/iRoute Geschichte wieder bewiesen (siehe Fragen zu OpenVPN unter OpenWRT).

Und um nicht weiter auszuschweifen und nach 10 Jahren hier in den Artikel schauende User noch mehr mit BlaBla abzulenken, lege ich dir oder sonstwem nochmal ans Herz dich mit iroute auseinanderzusetzen und wofür es gedacht ist. Dann wird du oder aqui HOFFENTLICH endlich mal verstehen, dass route und iroute zwei verschiedene Sachen sind, und dass es darauf ankommt ob ein Client nur einen einzelnen Host im entfernten Host ansprechen will, oder die Dienste für das gesamte Subnet anbieten möchte. Und deswegen und nur deswegen gibts auch in OpenVPN die Möglichkeit diese Bedürfnisse über iroute zu regeln. Und weils anscheinend auch bei dir nicht rübergekommen ist, hier nochmals:

Warum iroute ? Original Beschreibung aus der ofiziellen OpenVPN HowTo command reference!

--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.

This directive can be used to route a fixed subnet from the
server to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to
the system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.


This option must be specified either in a client instance config
file using --client-config-dir or dynamically generated using a
--client-connect script.

The --iroute directive also has an important interaction with
--push "route ...". --iroute essentially defines a subnet which
is owned by a particular client (we will call this client A).
If you would like other clients to be able to reach A's subnet,
you can use --push "route ..." together with --client-to-client
to effect this. In order for all clients to see A's subnet,
OpenVPN must push this route to all clients EXCEPT for A, since
the subnet is already owned by A. OpenVPN accomplishes this by
not not pushing a route to a client if it matches one of the
client's iroutes.

iroute und route sind zwei verschiedene Sachen, und es geht wie in meinem Ursprungspost deutlich beschrieben darum, mehrere Clients hinterm OpenVPN-Punkt zu versorgen. Und wenn du jetzt ebenso wie aqui beharrst, dass kein Mensch iroute braucht, dann viel Spass und viel Erfolg. Dann habt ihr wirklich noch mehr Durchblick in OpenVPN wie die Entwickler selbst und dessen Dokumentationen.
104286
104286 21.02.2013 um 11:23:18 Uhr
Goto Top
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
aqui
aqui 23.02.2013 um 14:18:54 Uhr
Goto Top
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 face-wink