Freetz OpenVPN - Probleme nach Verbindung

[MaxMuster]

Moin,

nimm mal bitte beide Einträge für das Routing raus (lokales und entferntes Netz), das ist in deiner Konfiguration überflüssig.
Wenn der Client die Server-Box als Defaultgateway bekommen soll, muss du "Clientverkehr umleiten" anwählen.

Das mit der Config ist "mit Absicht" so, die wird immer "frisch" aus den GUI-Einstellungen erzeugt. Wenn du das nicht willst, kannst du den Client natürlich auch manuell mit einer eigenen Konfiguration starten...

Jörg

 

[m4xL]

Moin moin,
hab die einträge rausgelöscht. Aber nochmal eine Frage von mir, in der Hoffnung das ich das nicht falsch verstanden habe.
Netz A indem der VPN-Server steht, kann das gleiche Netz sein wie das Netz B indem der VPN-Client steht?!

Hab Folgendes erfolgreich ausprobiert:
OpenVPN-Server(Fritz!Box) Netz 192.168.210.0/24
OpenVPN-Client(Windows) Netz 192.168.10.0/24
Ping in das 192.168.210.0/24 Netz funktioniert Problemlos

Folgendes ohne erfolg ausprobiert:
OpenVPN-Server(Fritz!Box) Netz 192.168.210.0/24
OpenVPN-Client(Windows) Netz 192.168.210.0/24
Ping in das 192.168.210.0/24 Netz funktioniert nicht :-/ OpenVPN Server auf der Fritz!Box bzw. die Fritz!Box selbst startet neu?! :-/

Folgendes wiederum ohne erfolg ausprobiert:
OpenVPN-Server(Fritz!Box 7270) Netz 192.168.210.0/24
OpenVPN-Client(Fritz!Box 7050) Netz 192.168.210.0/24
Ping in das 192.168.210.0/24 Netz funktioniert auch nicht.

Hier das Log des Servers:

/var/mod/root # cat /var/tmp/debug_openvpn.out
Sun Mar 21 21:10:35 2010 OpenVPN 2.1_rc15 mipsel-linux [SSL] [LZO2] [EPOLL] built on Mar 15 2010
Sun Mar 21 21:10:35 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Mar 21 21:10:35 2010 Diffie-Hellman initialized with 1024 bit key
Sun Mar 21 21:10:35 2010 WARNING: file '/tmp/flash/box.key' is group or others accessible
Sun Mar 21 21:10:35 2010 Control Channel Authentication: using '/tmp/flash/static.key' as a OpenVPN static key file
Sun Mar 21 21:10:35 2010 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:35 2010 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:35 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Sun Mar 21 21:10:35 2010 TLS-Auth MTU parms [ L:1582 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Mar 21 21:10:35 2010 TUN/TAP device tap0 opened
Sun Mar 21 21:10:35 2010 TUN/TAP TX queue length set to 100
Sun Mar 21 21:10:35 2010 /sbin/ifconfig tap0 192.168.210.10 netmask 255.255.255.0 mtu 1492 broadcast 192.168.210.255
Sun Mar 21 21:10:35 2010 Data Channel MTU parms [ L:1582 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Mar 21 21:10:35 2010 Socket Buffers: R=[108544->131072] S=[108544->131072]
Sun Mar 21 21:10:35 2010 UDPv4 link local (bound): [undef]:1194
Sun Mar 21 21:10:35 2010 UDPv4 link remote: [undef]
Sun Mar 21 21:10:35 2010 MULTI: multi_init called, r=256 v=256
Sun Mar 21 21:10:35 2010 IFCONFIG POOL: base=192.168.210.30 size=6
Sun Mar 21 21:10:35 2010 Initialization Sequence Completed
Sun Mar 21 21:10:41 2010 MULTI: multi_create_instance called
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 Re-using SSL/TLS context
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 LZO compression initialized
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 Control Channel MTU parms [ L:1582 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 Data Channel MTU parms [ L:1582 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Mar 21 21:10:41 2010 79.208.239.231:2058 TLS: Initial packet from 79.208.239.231:2058, sid=d2775aa0 6ceb4a32
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 VERIFY OK: depth=1, /C=DE/ST=Bayern/L=City/O=home.net.local/CN=m4xL/emailAddress=max.m4xL@local
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 VERIFY OK: depth=0, /C=DE/ST=Bayern/O=home.net.local/CN=m4xL22/emailAddress=max.m4xL@local
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Mar 21 21:10:43 2010 79.208.239.231:2058 [m4xL22] Peer Connection Initiated with 79.208.239.231:2058
Sun Mar 21 21:10:44 2010 m4xL22/79.208.239.231:2058 PUSH: Received control message: 'PUSH_REQUEST'
Sun Mar 21 21:10:44 2010 m4xL22/79.208.239.231:2058 SENT CONTROL [m4xL22]: 'PUSH_REPLY,dhcp-option DNS 192.168.210.10,dhcp-option DNS 192.168.210.1,route 192.168.210.10 ,route-gateway 192.168.210.10,ping 10,ping-restart 120,ifconfig 192.168.210.30 255.255.255.0' (status=1)
Sun Mar 21 21:10:44 2010 m4xL22/79.208.239.231:2058 MULTI: Learn: f6:5d:f8:35:42:36 -> m4xL22/79.208.239.231:2058

Hier das Log des Clients:

/var/mod/root # cat /var/tmp/debug_openvpn.out
Sun Mar 21 21:10:34 2010 OpenVPN 2.1_rc15 mipsel-linux [SSL] [LZO2] [EPOLL] built on Mar 14 2010
Sun Mar 21 21:10:35 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Mar 21 21:10:35 2010 WARNING: file '/tmp/flash/box.key' is group or others accessible
Sun Mar 21 21:10:35 2010 WARNING: file '/tmp/flash/static.key' is group or others accessible
Sun Mar 21 21:10:35 2010 Control Channel Authentication: using '/tmp/flash/static.key' as a OpenVPN static key file
Sun Mar 21 21:10:35 2010 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:35 2010 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:35 2010 LZO compression initialized
Sun Mar 21 21:10:35 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Sun Mar 21 21:10:35 2010 Control Channel MTU parms [ L:1582 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Mar 21 21:10:35 2010 Data Channel MTU parms [ L:1582 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Mar 21 21:10:35 2010 Socket Buffers: R=[110592->131072] S=[110592->131072]
Sun Mar 21 21:10:35 2010 UDPv4 link local: [undef]
Sun Mar 21 21:10:35 2010 UDPv4 link remote: 79.208.136.92:1194
Sun Mar 21 21:10:35 2010 TLS: Initial packet from 79.208.136.92:1194, sid=729b8fcb 5002a1ba
Sun Mar 21 21:10:35 2010 VERIFY OK: depth=1, /C=DE/ST=Bayern/L=City/O=home.net.local/CN=m4xL/emailAddress=max.m4xL@local
Sun Mar 21 21:10:35 2010 VERIFY OK: nsCertType=SERVER
Sun Mar 21 21:10:35 2010 VERIFY OK: depth=0, /C=DE/ST=Bayern/O=home.net.local/CN=m4xL/emailAddress=max.m4xL@local
Sun Mar 21 21:10:36 2010 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Mar 21 21:10:36 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:36 2010 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Mar 21 21:10:36 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Mar 21 21:10:36 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Mar 21 21:10:36 2010 [m4xL] Peer Connection Initiated with 79.208.136.92:1194
Sun Mar 21 21:10:38 2010 SENT CONTROL [m4xL]: 'PUSH_REQUEST' (status=1)
Sun Mar 21 21:10:38 2010 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.210.10,dhcp-option DNS 192.168.210.1,route 192.168.210.10 ,route-gateway 192.168.210.10,ping 10,ping-restart 120,ifconfig 192.168.210.30 255.255.255.0'
Sun Mar 21 21:10:38 2010 OPTIONS IMPORT: timers and/or timeouts modified
Sun Mar 21 21:10:38 2010 OPTIONS IMPORT: --ifconfig/up options modified
Sun Mar 21 21:10:38 2010 OPTIONS IMPORT: route options modified
Sun Mar 21 21:10:38 2010 OPTIONS IMPORT: route-related options modified
Sun Mar 21 21:10:38 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Mar 21 21:10:38 2010 TUN/TAP device tap0 opened
Sun Mar 21 21:10:38 2010 TUN/TAP TX queue length set to 100
Sun Mar 21 21:10:38 2010 /sbin/ifconfig tap0 192.168.210.30 netmask 255.255.255.0 mtu 1492 broadcast 192.168.210.255
Sun Mar 21 21:10:38 2010 OpenVPN ROUTE: omitted no-op route: 192.168.210.10/255.255.255.255 -> 192.168.210.10
Sun Mar 21 21:10:38 2010 Initialization Sequence Completed

Server Konfiguration:

/var/mod/root # cat /var/mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Sun Mar 21 21:10:35 CET 2010
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
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 1194
push "dhcp-option DNS 192.168.210.10"
push "dhcp-option DNS 192.168.210.1"
mode server
ifconfig-pool 192.168.210.30 192.168.210.35
push "route 192.168.210.10 "
ifconfig 192.168.210.10 255.255.255.0
push "route-gateway 192.168.210.10"
max-clients 3
tun-mtu 1492
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120

Client Konfiguration:

/var/mod/root # cat /var/mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Sun Mar 21 21:10:34 CET 2010
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
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 dyndns.org
nobind
pull
tun-mtu 1492
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite

Hab grad nochmal das zweite Netz umgestellt auf 192.168.211.0/24 Ping geht auch nicht durch :-/

Gruß m4xL

 

[MaxMuster]

Das müsstest du jetzt genauer erklären: Der Cilent ist in einem anderen(!) LAN (an einem anderen Standort), was aber den gleichen IP-Kreis benutzt, wie das Netz beim Server?

Dann müssten
- Zwingend alle IPs auf beiden Seiten unterschiedlich (einmalig) sein. Keine IP darf es auf beiden Seiten geben, das gilt auch für den "DHCP-VPN-Nummernkreis" und alle anderen DHCPs
- Die Netze müssen dann auch auf beiden Seiten jeweils gebrückt werden, sonst wäre das gleiche Netz auf verschiedenen Adaptern.

Jörg

EDIT: Wenn die IPs in den Netzen verschieden sind, wird zunächst nur die Verbindung vom Client aus möglich sein, nicht von anderen Geräten im Clinet-LAN. Dafür muss dann auf dem Server eine Route ins Client-LAN eingerichtet werden. Bridging ersetzt nicht das Routing (zumindes meistens;-)).

 

[m4xL]

Der Client Verbindet sich übers Internet mit dem Server jedoch sollten beide "LANs" das gleiche Netz haben. Das sich keine IP-Adresse überschneidet bzw. Doppelt vorhanden ist ist gegeben und sollte aber das kleiner übel sein. Also LAN A und LAN B haben beide das Netz 192.168.210.0/24 und jede Adresse ist nur einmal vergeben.
Bei Client und Server ist jeweils Brücke(TAP) ausgewählt mit "LAN Brücken". Auf beiden Seiten steht jeweils eine Fritz!Box als Gateway

Als Server eine 7270 und Client 7050.

Gruß m4xL

 

[MaxMuster]

Diese Config sollte prinzipiell gehen (z.B. mit zwei Boxen).
Kommt es dabei zu Problemen bedenke bitte, dass Bridging auf den "neueren Boxen" oft nicht geht, wenn du WLAN nutzt und oft sogar zu Reboots führt.

Jörg

 

[m4xL]

Also wenn ich das jetzt richtig verstanden habe, Funktioniert LAN A == LAN B nicht. Dann ändere ich einfach LAN B auf ein anderes Netz und trage das Routing nach und sollte dann Funktionieren.

 

[MaxMuster]

Die Problematik liegt im Bridging im Zusammenhang mit den AVM-WLAN-Modulen.
Wenn du mit "normalem" Routing auskommst (TUN), ist das Problem weg. Dann musst du zwar routen, das Ganze wird aber auch vom Aufbau her "deutlicher" ;-) .

Jörg

 

[m4xL]

Sorry steh grad voll auf der Leitung
Meine "Server" und die wichtigsten Drucker stehen im LAN mit dem x.210.0/24 Netz. Jetzt glaub ich zu meinen, das ich im Wiki gelesen hab, das dafür das Bridging besser wäre, und dadurch der Client in das gleiche Netz wie der Server kommt?!

[EDIT]
Jörg vergib mir hatte in der ar7.cfg der Clientbox bei den brinterface vergessen tap0 zu setzen nun läuft alles sooo wies soll

Gruß m4xL

 

[m4xL]

Hallo zusammen,
bin nun nach einiger Zeit drauf gekommen, dass das Bridging nicht meinen Anforderungen gerecht wird (Lange zugriffszeiten ins andere entfernte Netzwerk usw.). Nun wollte ich das ganze auf Tunneling umbauen. Leider gelingt mir das ganze nicht soo wie es soll.

Vorab, die Verbindung von einem Windows Client auf den Server und einen Ping auf Komponenten im Netzwerk hinter der Server Box ist erfolgreich.

Eine Verbindung zwischen den zwei Boxen wird auch erfolgreich aufgebaut. Ein Ping aus dem 192.168.211.0/24 in das 192.168.210.0/24 Funktioniert teilweise. Ping auf den OpenVPN Box Server Funktioniert und auch der Ping auf das Gateway im Gegennetz funktioniert. Ping auf Andere Komponenten wie Clients funktioniert nicht :-/

Aus dem 192.168.210.0/24 Funktioniert kein Ping

Hier mal meine Einstellungen vom Client und Server



Gruß m4xL

 

[MaxMuster]

Zunächst solltes du dem Server eine IP in dem Netzbereich geben, in dem er IPs vergibt (zumindest ist im Screenshot 192.168.210.13 eingetragen), das sollte was aus dem Netz 192.168.212.x sein, in dem der DHCP-Range liegt...

Dann muss der Server noch wissen, welches Netz beim Client ist. Das kannst du (bei mehrereh Clients) nur eintragen, indem du die erweiterte Clientconfig nutzt, und dort für dein CLient-Zertifikat eine "feste" IP vergibst und das Netz beim Client einträgst.

Jörg

 

[m4xL]

Hallo,
ich danke dir für die Infos ; )
du hast mir mal wieder perfekt geholfen! :groesste:

Eine Frage hätte ich aber dennoch! Wenn ich zwei Instanzen des OpenVPN Servers laufen lasse, muss ich dann ein weiters "tap-Device" in der ar7.cfg hinzufügen? Also ein "tap1"? Und wie lösche ich beim Server einen Client? Beim löschen und übernehmen steht der client wieder drin : (

[EDIT]
Jetzt grad funktioniert wieder nichts ;( Webinterface genauso eingestellt...
Ping ist nur wieder von Server Box auf die Client Box möglich
ein Ping aus dem "Clientboxen" bereich in den "Serverboxen" bereich geht nur auf das Gateway und den Server selbst andere Komponenten wieder nicht...

Gruß m4xL

 

[m4xL]

Hallo zusammen,
Funktionierten tuts noch immer nicht richtig!

Im Anhang nochmal Bilder von der Konfiguration



Ping aus 192.168.211.0/24 auf 192.168.210.10(Gateway) und 192.168.210.13(OpenVPN Server) ist möglich alles andere ergibt eine Zeitüberschreitung

Ping aus dem 192.168.210.0/24 Bereich in 192.168.211.0/24 Reagiert weder der Client noch eine andere Komponente.

Im Syslog der Clientbox findet sich noch folgende Zeilen:

[...]
Jun  3 11:55:26 fritz daemon.notice openvpn[1803]: [fuchs] Peer Connection Initiated with 192.168.10.11:1194
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: SENT CONTROL [fuchs]: 'PUSH_REQUEST' (status=1)
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.210.10,dhcp-option WINS 192.168.210.1,route 192.168.212.13,route-gateway 192.168.212.13,topology subnet,route 192.168.210.0 255.255.255.0 192.168.212.13
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OPTIONS IMPORT: timers and/or timeouts modified
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OPTIONS IMPORT: --ifconfig/up options modified
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OPTIONS IMPORT: route options modified
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OPTIONS IMPORT: route-related options modified
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: TUN/TAP device tun0 opened
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: TUN/TAP TX queue length set to 100
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: /sbin/ifconfig tun0 192.168.212.30 netmask 255.255.255.0 mtu 1492 broadcast 192.168.212.255
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: /sbin/route add -net 192.168.210.0 netmask 255.255.255.0 gw 192.168.212.13
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: OpenVPN ROUTE: omitted no-op route: 192.168.212.13/255.255.255.255 -> 192.168.212.13
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: /sbin/route add -net 192.168.210.0 netmask 255.255.255.0 gw 192.168.212.13
Jun  3 11:55:27 fritz daemon.warn openvpn[1803]:[B] ERROR: Linux route add command failed: external program exited with error status: 1[/B]
Jun  3 11:55:27 fritz daemon.notice openvpn[1803]: Initialization Sequence Completed

Gruß m4xL

 

[MaxMuster]

Die Fehlermeldung kommt wohl, weil die Route für das Netz beim Server (192.168.210.0/24) beim Client doppelt einzutragen versucht wird: Der Server meldet das Netz (per push), beim Client ist es nochmal in der GUI eingetragen. Das sollte aber reine Kosmetik sein...

Damit das ganze so funktioniert, muss der VPN-Server auch die Pakete für 192.168.211.0/24 bekommen. Ist diese Box (192.168.210.13) dort nicht das Default-Gateway, muss eine Route auf den Clients (oder auf dem "richtigen" DG) für dieses Netz zur VPN-Box eingetragen werden...

Zu der Frage mit den TAP-Devices: Nur wenn du TAPs per ar7.cfg brücken willst, müssen sie dort eingetragen werden. Für das jetzt genutzte Routing durch den Tunnel muss da nichts rein...

Jörg

 

[m4xL]

Heyo,
ja das gute alte Routing... Funktioniet soweit!!

Zu meiner Frage wegen den Schnittstellen in der ar7.cfg:
Ich habe ja die möglichkeit einen weiteren OpenVPN Server auf der Box laufen zu lassen.
Da ich ja beim Tunneling die Adresse des Gegennetzes kennen muss eignet sich dieses eig. nicht für Zugriff aus z.B. einem Internetcaffe. Auch sind evtl. Ports blockiert. Hier würde ich gern zusätzlich noch einen OpenVPN Server als Bridge laufen lassen. Muss für diesen eine weitere Schnittstelle erstellt werden oder Teilen sich beide dann das tap0 Device?

Gruß m4xL

 

[MaxMuster]

Ein Server nutzt jeweils das nächste freie Device:
Der erste "Bridging"-Server nutzt das tap0, der nächste tap1 ...
Der erste "Tunnel"-Server nutzt das tun0, der nächste tun1 ...

Für je einen "Tunnel"- und "Bridging"-Server reicht also das "Nuller"-Device.

Im Internetcaffee wirst du aber wohl kaum einen eigenen Router (mit Geräten dahinter) haben, sondern nur den Client? Der ist aber mit seiner VPN-IP immer direkt erreichbar.
Wenn du allerdings nur von einem Client zugreifst, kannst du per Bridging natürlich "einfacher" den ganzen Windows-Kram (Freigabenamen und so) nutzen...

Jörg