Freetz: OpenVPN-Client-Netzwerk im Server erreichbar machen

gauner · 16 Okt 2014

Ich habe zwei Fritzboxen, die ich mit OpenVPN vernetzen möchte.. Auf beiden läuft Freetz Das Netzwerk-Setup ist etwas kompliziert:

* Server-Fritzbox 7490 (öffentliche IPV4-Adresse) - lokales Netz: 192.168.4.0/24

* Client-Fritzbox 7390 (IPV6 mit DS-Lite-Stack, leider keine öffentliche IPV4-Adresse) - hinter Kabelbox 6360 von Unitymedia (sie stellt eine Verbindung zur Serverbox her) - lokales Netz 192.168.178.0/24, bekommt die feste IP 192.168.4.222 zugewiesen.

Beide Openvpn-TAP-Adapter sind jeweils mit dem lokalen Netzwerk gebrückt. IPV4-Forwarding ist auf beiden Boxen aktiviert.

Ziel: Erreichbarkeit des 192.168.178.0/24er (vom Client) Netzes von der Serverbox aus. Optimalerweise von allen Rechnern hinter der Serverbox, das ist aber derzeit ein schwieriges Thema, wie ich las. Es reicht erstmal die Erreichbarkeit des Netzes von der Serverbox aus.

Dazu habe ich bei bestehender Verbindung mal probiert eine statische Route einzurichten:

route add -net 192.168.178.0 gw 192.168.4.222 netmask 255.255.255.0 dev tap0

Leider ohne Erfolg.. Adressen aus dem 192.168.178.0er Netz sind nicht erreichbar..

Eine Verbindung über einen IPV6-Broker möchte ich nicht herstellen, da das für mich nicht performant genug läuft. Ich möchte die höchstmögliche Datenrate erzielen.

Hat hier jemand eine Idee?

RalfFriedl · 17 Okt 2014

Es reicht nicht, Routen im System zu setzen, die Routen müssen im OpenVPN konfiguriert werden, siehe dazu die Dokumentation (route und iroute). Bei der Gelegenheit kann man durch OpenVPN auch die System-Routen setzen lassen.

Es reicht, wenn die eine Box über IPv4 ansprechbar ist und die andere Box eine Verbindung dorthin aufbauen kann.

gauner · 19 Okt 2014

Danke für Deine Antwort. Das hat mich jetzt schon mal einen Schritt weitergebracht.

Die Route wird durch OpenVPN gesetzt. Allerdings kann ich nur den OpenVPN-Client (192.168.178.20) anpingen, der Rest des Netzwerks bleibt unerreichbar.

Hier mal meine durch freetz generierten configs:

Serverbox:

Code:

#  OpenVPN 2.1 Config, Thu Jan  1 01:01:04 CET 1970
proto udp6
dev tap1
#Helperline for rc.openvpn to add tap1 to lan bridge
ca /tmp/flash/openvpn/udp_ca.crt
cert /tmp/flash/openvpn/udp_box.crt
key /tmp/flash/openvpn/udp_box.key
dh /tmp/flash/openvpn/udp_dh.pem
tls-server
port 1234
ifconfig 192.168.4.240 255.255.255.0
push "route-gateway 192.168.4.240"
push "route 192.168.4.0 255.255.255.0"
max-clients 10
mode server
ifconfig-pool 192.168.4.220 192.168.4.240
push "route 192.168.4.0 255.255.255.0"
client-config-dir clients_openvpn_udp
route 192.168.178.0 255.255.255.0 192.168.4.222
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
float
keepalive 10 120
status /var/log/openvpn_udp.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Clientbox:

Code:

#  OpenVPN 2.1 Config, Sun Oct 19 11:43:45 CEST 2014
proto udp
dev tap2
#Helperline for rc.openvpn to add tap2 to lan bridge
dev-node /dev/tun
ca /tmp/flash/openvpn/hh_ca.crt
cert /tmp/flash/openvpn/hh_box.crt
key /tmp/flash/openvpn/hh_box.key
tls-client
remote xxx 1234
nobind
pull
route 192.168.4.0 255.255.255.0 192.168.4.1
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Was mache ich falsch?

RalfFriedl · 19 Okt 2014

Ich habe oben geschrieben "route und iroute"

MaxMuster · 20 Okt 2014

Das mit dem "client-config-dir" sieht schon ganz gut aus (darin erzeugt die GUI die iroute Einträge). Ist bei dem Client, der das Netz hat, das Netz auch in der erweiterten Clientkonfiguration ("Netz bei Client") eingetragen?
Wenn, stimmt auch der Name im Zertifikat genau? Das sollte das Log zeigen, ob der richtige Client "erkannt" und die passende Config gezogen wird.

gauner · 20 Okt 2014

So hatte ich es eigentlich auch gelesen. Der Client wird scheinbar richtig erkannt, denn ihm wird die korrekte IP-Adresse zugewiesen. Unter "Verbundene Clients" taucht er auch mit dem Namen auf.

Schaue ich allerdings ins client-config-dir sehe ich folgendes:

root@fritz:/var/tmp/openvpn/clients_openvpn# cat gelclient
ifconfig-push 192.168.4.222 255.255.255.0

Dort ist für den Client überhaupt kein iroute-Eintrag hinterlegt. Die entsprechenden Einstellungen habe ich aber schon vorgenommen:

MaxMuster · 20 Okt 2014

Mein Fehler. Du nutzt ja eine Brücke ("TAP"); dann braucht der Server kein iroute für Netze beim Client.
Das Routing-Ziel (der Client, an dem das Netz hängt) ist ja direkt "verbunden" und kann vom Routingprozess direkt angesprochen werden.

Ist denn die FB im Netz 192.168.178.0 auch das "Default-Gateway"? Nur dann wird sie automatisch die "Rückpakete" von anderen Geräten im LAN zum Server bekommen...
Sonst muss das DG (die Kabel-Box?) eine Route für das VPN-Netz (192.168.4.0 255.255.255.0) zur FritzBox bekommen.

gauner · 20 Okt 2014

Das könnte es natürlich sein.. Aber was ist das Gateway der Route? Die OpenVPN-Client-Fritzbox ist per Client-Modus an die 6360 Kabelbox angeschlossen und dient selbst natürlich nicht als Gateway. Sie hat lokal das TAP-Interface und kann so das 192.168.4.0 Netz erreichen.

MaxMuster · 20 Okt 2014

Dann müsstest du der "Client-FB" eine "feste IP" zuweisen (entweder bei den DHCP-Einstellungen da gab es sowas wie "immer die gleiche IP zuweisen" oder so), oder du machst es gleich "richtig" und stellst in der Client-FB eine feste IP (außerhalb des DHCP-Bereiches der Kabelbox) ein.
Auf diese IP routest du dann von der Kabelbox das VPN-Netz.

gauner · 20 Okt 2014

Das war es.. Vielen Dank. Die "Rückroute" fehlte..

dipsy · 22 Nov 2014

Hallo gauner,

ich habe das selbe Problem am telecolumbus Anschluss, kannst du mir die “Rückroute“ erklären? Ich kann derzeit bis zur VPN ip pingen.

greetz dipsy

MaxMuster · 23 Nov 2014

Ich zitier mich mal selbst:

MaxMuster schrieb:
Dann müsstest du der "Client-FB" eine "feste IP" zuweisen (entweder bei den DHCP-Einstellungen da gab es sowas wie "immer die gleiche IP zuweisen" oder so), oder du machst es gleich "richtig" und stellst in der Client-FB eine feste IP (außerhalb des DHCP-Bereiches der Kabelbox) ein.
Auf diese IP routest du dann von der Kabelbox das VPN-Netz.

dipsy · 23 Nov 2014

Hallo MaxMuster,

die box läuft bei mir direkt am Kabelmodem als Router ist also gateway und dnsserver im Lan, denoch komme ich über die Serverbox nur bis zur VPN-IP 10.10.0.10. Die Lan IP 192.168.10.1 erreiche ich schon nicht.

greetz dipsy

MaxMuster · 24 Nov 2014

Wenn die FB VPN-Client ist, muss im Server das Netz zu der Box geroutet werden und ein "iroute-Eintrag" für das (LAN-)Netz existieren.
Das passiert in der Regel auf dem Server mit "Client-config-dir" EInträgen für ein Zertifikat/einen Client.
Hast du sowas? Ist der Server auch eine FB? Dann geht das in der GUI mit den "erweiterten Clienteinstellungen".

dipsy · 25 Nov 2014

Hallo MaxMuster,

ja ich habe auf der Serverbox (7390) openvpn laufen und unter "erweiterten Clienteinstellungen" die zwei clients eingetragen, leider steht in der config nur

route 192.168.178.0 255.255.255.0 10.10.0.10
route 192.168.10.0 255.255.255.0 10.10.0.11

sollte ich aus dem route ein iroute machen?

greetz dipsy

MaxMuster · 26 Nov 2014

Nein, das passt. Die "iroutes" stehen im client-config-dir in der Datei zum Client.
Bekommen die Clients denn die "passende" IP, die du ihnen in der erweiterten Config eingetragen hast? Sonst weist das auf einen falsch gschriebenen Client-Namen an dieser Stelle hin.
Der erste Test ist auf jeden Fall der, den du schon gemacht hast, die Client-Box selbst mit ihrer LAN-IP ansprechen. Das muss erstmal klappen.
Du könntest sonst auf den beiden Geräten mal das "Debugging" einschalten und sehen, ob Fehlermeldungen auftreten, wenn du diese IP pingst. Wenn der iroute-Eintrag fehlt, werden beim Server solche Fehler auflaufen "MULTI: bad source address from client [...]".

dipsy · 26 Nov 2014

Hallo MaxMuster,

beim aktivieren des Debugging am Server hatte ich sofort folgende Ausgabe im syslog, das sieht mir so aus als hätte das image auf der Serverbox ein Problem.

Code:

Nov 26 19:22:49 fritz kern.warn kernel: system-load 1 curr: openvpn.cgi runnable: 3
Nov 26 19:23:38 fritz daemon.err openvpn[14213]: event_wait : Interrupted system call (code=4)
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: TCP/UDP: Closing socket
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: /sbin/route del -net 192.168.10.0 netmask 255.255.255.0
Nov 26 19:23:38 fritz daemon.warn openvpn[14213]: ERROR: Linux route delete command failed: could not execute external program
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: /sbin/route del -net 192.168.178.0 netmask 255.255.255.0
Nov 26 19:23:38 fritz daemon.warn openvpn[14213]: ERROR: Linux route delete command failed: could not execute external program
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: Closing TUN/TAP interface
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: /sbin/ifconfig tap1 0.0.0.0
Nov 26 19:23:38 fritz daemon.warn openvpn[14213]: Linux ip addr del failed: could not execute external program
Nov 26 19:23:38 fritz daemon.notice openvpn[14213]: SIGTERM[hard,] received, process exiting

Auch beim Client sieht der log für mich komisch aus.

Code:

Nov 26 19:34:22 Client daemon.err openvpn[3572]: event_wait : Interrupted system call (code=4)
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: TCP/UDP: Closing socket
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: /sbin/route del -net 192.168.10.0 netmask 255.255.255.0
Nov 26 19:34:22 Client daemon.warn openvpn[3572]: ERROR: Linux route delete command failed: could not execute external program
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: /sbin/route del -net 10.10.0.0 netmask 255.255.255.0
Nov 26 19:34:22 Client daemon.warn openvpn[3572]: ERROR: Linux route delete command failed: could not execute external program
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: /sbin/route del -net 192.168.11.0 netmask 255.255.255.0
Nov 26 19:34:22 Client daemon.warn openvpn[3572]: ERROR: Linux route delete command failed: could not execute external program
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: Closing TUN/TAP interface
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: /sbin/ifconfig tap0 0.0.0.0
Nov 26 19:34:22 Client daemon.warn openvpn[3572]: Linux ip addr del failed: could not execute external program
Nov 26 19:34:22 Client daemon.notice openvpn[3572]: SIGTERM[hard,] received, process exiting

mich irritieren die Fehler beim löschen der routen.

Kannst du mir sagen wie ich an die ausführlichen Logdateien komme, leider habe ich kein Vsftpd installiert.

greetz dipsy

MaxMuster · 28 Nov 2014

Die Fehler kommen vermutlich vom Beenden des OpenVPN, weil beim OpenVPN der Nutzer da "heruntergestuft" wurde und dann die Routen nicht ändern kann.
Interessanter wären die Ausgaben beim Starten/Verbinden.

Wenn du das "debug" mit dem Haken oben einschaltest steht da, wohin das Logfile geschrieben wird (z.B. /var/tmp/debug_openvpn.out). Anzeigen (und auch herunterladen) kannst du das dann z.B. mit der RudiShell:

cat /var/tmp/debug_openvpn.out

<Skript ausführen>

Wenn du dann noch "Download" anklickst, kannst du die Ausgabe abspeichern...

dipsy · 30 Nov 2014

Hallo MaxMuster,

ich habe den debug mit deiner Hilfe kopieren können der sieht für mich gut aus. Die "xx.xxx.xx.xx" entsprechen den öffentlichen Adressen.
Kannst du einen Fehler erkennen?

Code:

freetz-devel-11197M
Freetz – Rudi(mentär)-Shell


   Wiederholungsintervall  ms   Historie       Download (.tar  .gz )

Quelldatei	
Zieldatei	 
Rudi-Edit	 
 Sun Nov 30 13:56:56 2014 OpenVPN 2.2.2 mips-linux [SSL] [LZO2] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Sep 29 2013
Sun Nov 30 13:56:56 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Nov 30 13:56:56 2014 Diffie-Hellman initialized with 1024 bit key
Sun Nov 30 13:56:56 2014 WARNING: file '/tmp/flash/openvpn/server_static.key' is group or others accessible
Sun Nov 30 13:56:56 2014 Control Channel Authentication: using '/tmp/flash/openvpn/server_static.key' as a OpenVPN static key file
Sun Nov 30 13:56:56 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:56:56 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:56:56 2014 TLS-Auth MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Nov 30 13:56:56 2014 Socket Buffers: R=[204800->131072] S=[204800->131072]
Sun Nov 30 13:56:56 2014 TUN/TAP device tap1 opened
Sun Nov 30 13:56:56 2014 TUN/TAP TX queue length set to 100
Sun Nov 30 13:56:56 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sun Nov 30 13:56:56 2014 /sbin/ifconfig tap1 10.10.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.10.0.255
Sun Nov 30 13:56:56 2014 /sbin/route add -net 192.168.178.0 netmask 255.255.255.0 gw 10.10.0.10
Sun Nov 30 13:56:56 2014 /sbin/route add -net 192.168.10.0 netmask 255.255.255.0 gw 10.10.0.11
Sun Nov 30 13:56:56 2014 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Nov 30 13:56:56 2014 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Sun Nov 30 13:56:56 2014 GID set to openvpn
Sun Nov 30 13:56:56 2014 UID set to openvpn
Sun Nov 30 13:56:56 2014 UDPv4 link local (bound): [undef]
Sun Nov 30 13:56:56 2014 UDPv4 link remote: [undef]
Sun Nov 30 13:56:56 2014 MULTI: multi_init called, r=256 v=256
Sun Nov 30 13:56:56 2014 IFCONFIG POOL: base=10.10.0.100 size=101, ipv6=0
Sun Nov 30 13:56:56 2014 Initialization Sequence Completed
Sun Nov 30 13:58:57 2014 MULTI: multi_create_instance called
Sun Nov 30 13:58:57 2014 xx.xxx.xx.xx:49844 Re-using SSL/TLS context
Sun Nov 30 13:58:57 2014 xx.xxx.xx.xx:49844 LZO compression initialized
Sun Nov 30 13:58:57 2014 xx.xxx.xx.xx:49844 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Nov 30 13:58:57 2014 xx.xxx.xx.xx:49844 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Nov 30 13:58:57 2014 xx.xxx.xx.xx:49844 TLS: Initial packet from [AF_INET]xx.xxx.xx.xx:49844, sid=05624625 393aa13c
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=OpenVPN/CN=tc_querfurt/[email protected]
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 VERIFY OK: depth=0, /C=US/ST=CA/O=OpenVPN/CN=vpnclient03/[email protected]
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:49844 [vpnclient03] Peer Connection Initiated with [AF_INET]84.175.18.49:49844
Sun Nov 30 13:58:58 2014 vpnclient03/xx.xxx.xx.xx:49844 MULTI_sva: pool returned IPv4=10.10.0.100, IPv6=2acf:b470::47:2a38:47:29b0
Sun Nov 30 13:58:58 2014 MULTI: multi_create_instance called
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:2052 Re-using SSL/TLS context
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:2052 LZO compression initialized
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:2052 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:2052 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Nov 30 13:58:58 2014 xx.xxx.xx.xx:2052 TLS: Initial packet from [AF_INET]xx.xxx.xx.xx:2052, sid=649434a9 04c0fe16
Sun Nov 30 13:58:59 2014 vpnclient03/xx.xxx.xx.xx:49844 MULTI: Learn: 00:ff:93:9c:c0:d0 -> vpnclient03/xx.xxx.xx.xx:49844
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=OpenVPN/CN=tc_querfurt/[email protected]
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 VERIFY OK: depth=0, /C=US/ST=CA/O=OpenVPN/CN=vpnclient02/[email protected]
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Nov 30 13:59:00 2014 xx.xxx.xx.xx:2052 [vpnclient02] Peer Connection Initiated with [AF_INET]xx.xxx.xx.xx:2052
Sun Nov 30 13:59:00 2014 vpnclient02/xx.xxx.xx.xx:2052 OPTIONS IMPORT: reading client specific options from: clients_openvpn_server/vpnclient02
Sun Nov 30 13:59:01 2014 vpnclient03/xx.xxx.xx.xx:49844 PUSH: Received control message: 'PUSH_REQUEST'
Sun Nov 30 13:59:01 2014 vpnclient03/xx.xxx.xx.xx:49844 send_push_reply(): safe_cap=960
Sun Nov 30 13:59:01 2014 vpnclient03/xx.xxx.xx.xx:49844 SENT CONTROL [vpnclient03]: 'PUSH_REPLY,route-gateway 10.10.0.1,route 192.168.11.0 255.255.255.0,route 10.10.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.10.0.100 255.255.255.0' (status=1)
Sun Nov 30 13:59:02 2014 vpnclient02/xx.xxx.xx.xx:2052 PUSH: Received control message: 'PUSH_REQUEST'
Sun Nov 30 13:59:02 2014 vpnclient02/xx.xxx.xx.xx:2052 send_push_reply(): safe_cap=960
Sun Nov 30 13:59:02 2014 vpnclient02/xx.xxx.xx.xx:2052 SENT CONTROL [vpnclient02]: 'PUSH_REPLY,route-gateway 10.10.0.1,route 192.168.11.0 255.255.255.0,route 10.10.0.0 255.255.255.0,ping 10,ping-restart 120,route 192.168.10.0 255.255.255.0 10.10.0.11,ifconfig 10.10.0.10 255.255.255.0' (status=1)
Sun Nov 30 14:00:29 2014 vpnclient02/xx.xxx.xx.xx:2052 MULTI: Learn: c6:2a:fb:9a:4e:7c -> vpnclient02/xx.xxx.xx.xx:2052
30.11.2014 13:59 – up 14 days, 1:22 – optimiert für Mozilla Firefox

greetz dipsy

MaxMuster · 30 Nov 2014

Ich lag mit meiner Vermutung scheinbar garnicht so schlecht ;-)

Richtig läuft es beim "vpnclient02":

Code:

Sun Nov 30 13:59:00 2014 vpnclient02/xx.xxx.xx.xx:2052 OPTIONS IMPORT: [B]reading client specific options[/B] from: clients_openvpn_server/vpnclient02

Der bekommt, wie gewünscht, die richtige IP:

Code:

Sun Nov 30 13:59:02 2014 vpnclient02/xx.xxx.xx.xx:2052 SENT CONTROL [vpnclient02]: 'PUSH_REPLY,[...snip...],ifconfig 10.10.0.10 255.255.255.0' (status=1)

Falsch läuft es bei "vpnclient03", der bekommt eine Pool-IP und nicht die 10.10.0.11, wohin du das Netz 192.168.10.0 routest:

Code:

Sun Nov 30 13:58:58 2014 vpnclient03/xx.xxx.xx.xx:49844 MULTI_sva: [B]pool returned[/B] IPv4=10.10.0.100, IPv6=2acf:b470::47:2a38:47:29b0
[...snip...]
Sun Nov 30 13:59:01 2014 vpnclient03/xx.xxx.xx.xx:49844 SENT CONTROL [vpnclient03]: 'PUSH_REPLY,[...snip...],ifconfig 10.10.0.100 255.255.255.0' (status=1)

Also ziemlich sicher ein Fehler bei diesem Namen in der "erweiterten Konfig"...

Freetz: OpenVPN-Client-Netzwerk im Server erreichbar machen

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Statistik des Forums