OpenVPN-Paket

[rapt0r]

Was meinst du denn damit??? Das geht doch nur in der Server-Ansicht der GUI??

Ich meine die Option [x] auch IP-Adresse vom Server empfangen.

Der von dir gewählte Eintrag für "dhcp" (den ifconfig-pool) ist schonmal nicht sinnvoll. Schau dir dazu vielleicht mal die Doku an.
Jörg

Warum? Für den Fall mit einem Client ist die DHCP-Range für Clients ( <start-ip> <end-ip> ) von einer IP-Adresse doch sinnvoll.

Das verstehe ich nicht: Vom Server aus ist das am Server lokal angeschlossene Netz 192.168.178.0 nicht erreichbar, wohl aber vom Client aus??

Hab mich falsch ausgedrückt. Ich meine jeweils das entfernte Netz. Ich befinde mich jeweils per ssh auf den Konsolen der Boxen und lass dort die Pings los.
Der Server kann den clientseitigen Endpunkt anpingen aber nicht das Netz dahinter. Was der Client in die andre Richtung aber kann.
Routen falsch?
ServerBox:

192.168.60.0    192.168.10.2    255.255.255.0   UG    0      0        0 tun1

ClientBox:

192.168.178.0   192.168.10.1    255.255.255.0   UG    0      0        0 tun0

Ich hab das Gefühl, dass die ClientBox die Pakete nicht an das lan-interface weiterleitet. Denn das anpingen vom 60er Netz an 192.168.10.2 funktioniert zwar, aber nicht an 192.168.10.1. Daher kommen auch von zu Netz keine Pings durch.
Site-to-Site möchte ich realisieren.
Die ClientBox sitzt in einem Netz und nutzt nur die bestehende Internetverbindung. Also als Nat-Router mit IP.

[MaxMuster]

Für den Fall mit einem Client ist die DHCP-Range für Clients ( <start-ip> <end-ip> ) von einer IP-Adresse doch sinnvoll.

In dem Fall nicht wirklich. Damit wird ein Bereich vorgegeben, aus dem der Server "Mini-Netze" (/30 mit der Netmask 255.255.255.252) nutzt. Deshalb wird dabei immer gleich ein Bereich genutzt, und die erste IP im Netz bekommt (nur virtuell für Routingzwecke) der Server, die zweite der Client.

Wenn Netze beim Client sind und der "mode server" genutzt wird, muss der Server zusätzlich "iroute" Einträge dafür haben. Die kannst du nur im client-config-dir für den Client eintragen (z.B. in der erweiterten Clientconfig). Ansonsten bliebe nur, das auf eine "Single Client Config" umzustellen, ohne dhcp-range und mit "Max Clients" auf 1.

Im Client-Netz muss zusätzlich die Rückroute für den Server/das Servernetz zum VPN-Router bekannt sein, als erster test bietet sich ein Ping auf die LAN-IP des Clients an.

Jörg

[rapt0r]

Genau diese erweiterte Clientconfig scheitert eben:
ClientBox:

proto udp
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
ns-cert-type server
tls-auth /tmp/flash/static.key 1
remote *** 1196
nobind
pull
tun-mtu 1500
mssfix
fragment 1300
verb 3
daemon
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

ServerBox:

proto udp
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1196
mode server
ifconfig-pool 192.168.10.10 192.168.10.20
push "route 192.168.10.1"
ifconfig 192.168.10.1 255.255.255.0
client-config-dir /var/tmp/clients_openvpn_link_router
topology subnet
max-clients  1
push "route 192.168.178.0 255.255.255.0 192.168.10.1"
route 192.168.60.0 255.255.255.0 192.168.10.10
tun-mtu 1500
mssfix
fragment 1300
verb 3
daemon
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

ccd:

ifconfig-push 192.168.10.10 255.255.255.0
push "topology subnet"
iroute 192.168.60.0 255.255.255.0

resultiert in Log bei Client:

daemon.notice openvpn[1849]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
daemon.notice openvpn[1849]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.1,route 192.168.178.0 255.255.255.0 192.168.10.1,ping 10,ping-restart 120,ifconfig 192.168.10.10 255.255.255.0'
daemon.notice openvpn[1849]: OPTIONS IMPORT: timers and/or timeouts modified
daemon.notice openvpn[1849]: OPTIONS IMPORT: --ifconfig/up options modified
daemon.notice openvpn[1849]: OPTIONS IMPORT: route options modified
daemon.warn openvpn[1849]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warni
daemon.notice openvpn[1849]: TUN/TAP device tun0 opened
daemon.notice openvpn[1849]: TUN/TAP TX queue length set to 100
daemon.notice openvpn[1849]: /sbin/ifconfig tun0 192.168.10.10 pointopoint 255.255.255.0 mtu 1500
daemon.err openvpn[1849]: Linux ifconfig failed: external program exited with error status: 1
daemon.notice openvpn[1849]: Exiting

Danke für deine Hilfe.

Edit:
Mit dieser Client-Meldung hat alles angefangen, da hat mein bisher funktionierendes Site-to-Site, auf Basis der erweiterten Clientconfig, aufgehört zu funkionieren.
Damals hab ich ein Firmwareupdate gemacht und damit sind auch neue Versionen von Openvpn ins Freetz-image gekommen.

[stinkstiefel]

ifconfig-push 192.168.10.10 192.168.10.1

Obwohl moment mal, mode server und laut Log mode PtP sind ja eigentlich widersprüchlich.

[MaxMuster]

... ahh, endlich habei ich es, diese Server-Config war echt hilfreich . Versuche doch bitte mal den Patch aus Ticket 456.

Hintergrund: Bei der Einführung des chroot für openvpn wurde das client-config-dir nicht berücksichtigt.


Jörg

[stinkstiefel]

Max aber so wie es im Log ausschaut wird es doch berücksichtigt oder täusche ich mich da?
Siehe Warning im Log, das würde ich fast auf mode server in Kombination mit max-clients 1 zurückführen.

[MaxMuster]

Das Problem ist, dass der Eintrag für push "topology subnet" (nur) im client-config-dir steht, was wegen des chroot so nicht gefunden wird und nur der "normale" Eintrag zieht.

Jörg
EDIT: Generell ist das aber auch zusätzlich ein noch zu behebender Fehler, denn auch so müsste diese Option ja eigentlich gepushed werden....

[stinkstiefel]

Nun ja, "ifconfig-push 192.168.10.10 255.255.255.0" steht aber auch nur im ccd und es wird, wenn ich das richtig sehe, versucht dies beim Client auszuführen.

[MaxMuster]

... aber das ist auch die IP, die (zusätzlich) in der Config im Pool drinsteht (ifconfig-pool 192.168.10.10 192.168.10.20) und da in der Serverconfig topology subnet steht, bekommt der erste (wegen fehlendem ccd "unbekannte") Client die IP .10.

Jörg

[stinkstiefel]

Ah okay ich habs glaube verstanden, normalerweise sagt "subnet" der Server bekommt die 1. Adresse und Clients die 2. 3. usw. Weil der Server mit ifconfig aber schon die .1 bekommt erhält der Client also die 1. aus dem Pool.

Ich muss sagen ziemlich verwirrende Config die nicht besonders gut auf das eigentliche Ziel abgestimmt ist.

[MaxMuster]

Ja ja, meckert nur alle an der GUI rum (denn die hat das ganze ja erstellt).

Subnet bedeutet in der Tat, dass in Abweichung von der sonst gemachten Windows-Krücke, nur /30-er Netze zu vergeben, so echte "Einzeladressen" für die Clients vergeben werden können, die auch alle die "echte" tun-IP des Servers erreichen können.

Der Fehler liegt hier aber tatsächlich in zweifacher Hinsicht an dem Freetz-Paket: Die Nicht-Erreichbarkeit des ccd und noch die Tatsache, dass die anderen Clients dann kein "topology subnet" bekommen.

Jörg

[stinkstiefel]

Ups, das Fettnäpfchen hab ich nicht gesehen, hätte es sonst ganz anders formuliert. Ich wollte dir damit auch nicht auf die Füsse treten da ich in etwa abschätzen kann wie schwer es ist ein GUI immer ideal auf die einzelnen Anwendungsfälle abzustimmen.

[MaxMuster]

[OT]@stinkstiefel: Hey, ist doch nur Spaß; wäre ich beleidigt, würdest du das schon merken [/OT]
Ich habe im Ticket 456 einen neueren Patch angehängt, der beide Dinge beheben sollte. CCD sollte erreichbar sein und das "topology subnet" wird jetzt in der globalen Config an alle Clients gepushed.

Jörg

[rapt0r]

Danke, ab welcher Freetz-Version is dann der Patch drin?

[MaxMuster]

keine Ahnung, ich hoffe es geht jetzt recht fix. Aber der Patch sollte auch gegen die stable Versionen funktionieren...

Jörg

[rapt0r]

Wo und wie muss ich den Patch anwenden? Hab grad ein neues Image gebaut. Ein freetz-devel-3444M.

Dein Code-Workaround hat erstmal mein Site-to-Site wieder ermöglicht. Danke vielmals.

[MaxMuster]

Patch ins Freetz-Verzeichnis und dann dort:

## patch anwenden
patch -p0 openvpn-ccd-chroot-02.patch
## Danach noch das alte Paket löschen:
rm -rf package/openvpn*
rm package/.openvpn*

Der "Workaround" ist übrigens nicht von mir...


Jörg

[rapt0r]

Vielen Dank. Ihr seid spitze.

[MaxMuster]

Ist in Changeset 3449 eingeflossen und sollte jetzt gehen.

Jörg

[rapt0r]

Nochmals Danke für die Info.