OpenVPN-Paket

[RalfFriedl]

Das könnte man sicher machen. Die Frage ist, wer sowohl motiviert als auch in der Lage ist, das zu tun.

 

[kriegaex]

Wie wäre es mit einem Ticket auf freetz.org? Priorisieren können wir das dann dort.

 

[MaxMuster]

Die Frage kam mir doch bekannt vor ...
Es gab hier mal einen Patch dafür, der das ansatzweise machte. Ist allerdings Stand 2008 ...

 

[wengi]

Hi,

der Patch ist doch schon mal genau das was ich will
Vielen Dank dafür.
kriegaex hat Recht. Ich würde mal ein Ticket aufmachen, wenn Du erlaubst Deinen Patch als Inspiration gleich mit anzuhängen.
Wenn man das noch auf eine eigene Seite bekommt wäre auch die Übersicht gewahrt.

wengi

 

[MaxMuster]

Habe das mal (auf die "normale Seite") reingebastelt. Nur als erste Idee, eine eigene Seite (oder ausblendbar) wäre vermutlich schon besser, aber als Anfang...

 

[MaxMuster]

Ich denke, sowas meintest du (o.k., der Inhalt ist "von Hand aufgehübscht", das gebe ich ja zu ;-))


Ich mache dafür ein Ticket mit dem Patch auf (Ticket 1551).

 

[wengi]

DAS ist die absolute Luxus Variante!
Wow.

Danke
wengi

 

[wengi]

Hi,

ich habe jetzt trunk 7770 drauf.
Das ist genau das was ich wollte.

Vielen Dank an alle Beteiligten.
wengi

 

[KingTutt]

CRL Bug in OpenVPN

Ich habe mal ein neues Ticket bzgl. der Verwendung von CRLs (certificate revocation list) aufgemacht.
Scheint ja in Zeiten wo ständig Einbrüchen bei CAs stattfinden immer interessanter zu werden. Ich hoffe, dass ich alles klar beschrieben habe. Ich hoffe, dass jemand von den Developpern das fixen kann...

 

[MaxMuster]

Ich habe ins Ticket mal einen Patch angehängt. Könntest du den bitte mal austesten?

 

[KingTutt]

Werde ich heute Abend mal ausprobieren.


Ergebnis:
Der Patch funktioniert gut, die CRL kann korrekt angelegt und wieder entfernt werden. Die Maske für die Datei key.box könnte zur Vermeidung einer Warnung des OpenVPN Servers noch auf 600 (bisher 644) beim erstellen gesetzt werden.

Nachtrag zum Inhalt der resolv.conf:
Ich weiß nicht, wie die Datei resolv.conf des OpenVPN Servers erstellt wird, habe aber festgestellt, dass die resolv.conf des Dnsmask schon nicht korrekt aus der Freetz GUI übernommen wird.

Beispiel:
Die Domain wird über die Freetz GUI (Dnsmask) auf bla.blupp gesetzt. Daraufhin wird unter /tmp/flash/ eine Datei "dnsmasq.diff" in der die Domain korrekt hinterlegt wird: export DNSMASQ_DOMAIN='bla.blupp'
Dennoch wird dieser Domainname nirgend verwendet. Das Verzeichnis /tmp/flash/dnsmasq ist leer. Die Datei /etc/resolv.conf verlinkt auf /var/tmp/etc-resolv.conf deren Inhalt ist nach wie vor "domain fonwlan.box".

Funktioniert nur bei mir Dnsmask nicht korrekt oder woran kann das liegen? Die Aktivierung des DHCP-Servers zeigt ein ähnliches Bild. Zwar langen die konfigurierten Daten korrekt in der Datei "dnsmasq.diff" (DHCP in der AVM GUI ist aus), aber z.B. die Lease Ranges sind nicht die spezifizierten.

 

[MaxMuster]

Zum dnsmasq kann ich nichts sagen, aber teste doch bitte auch den zweiten Patch im Ticket, ob das die Warnung wegbekommt...

Jörg

 

[KingTutt]

Hallo Jörg,

der zweite Patch im Ticket macht die Warnung weg (prima). Ich habe die Rechte der Datei box.key manuell auf 644 gesetzt, ein Firmwareupdate mit Deinem Patch gemacht und anschließend waren die Rechte wieder auf 600 gesetzt.
Bei der Durchsicht des syslog ist mir jedoch noch etwas bzgl. des OpenVPN daemon aufgefallen. Das dürfte zwar in keinem direkten Zusammenhang mit den neuen Patches stehen, aber in früheren Freetz builds war das nicht der Fall (z.B. als wir damals hier mal über die push option geredet haben):

Der Openvpn daemon warnt beim Start über ein fehlendes gateway für seine eigene route (funktioniert hat es bislang aber trotzdem)

Nov  7 14:13:12 fritz daemon.notice openvpn[1148]: OpenVPN 2.2.1 mipsel-linux [SSL] [LZO2] [MH] [IPv6 payload 20110424-2 (2.2RC2)] built on Nov  7 2011
Nov  7 14:13:12 fritz daemon.warn openvpn[1148]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: Diffie-Hellman initialized with 1024 bit key
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: Socket Buffers: R=[110592->131072] S=[110592->131072]
Nov  7 14:13:13 fritz daemon.warn openvpn[1148]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Nov  7 14:13:13 fritz daemon.warn openvpn[1148]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.0
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: TUN/TAP device tap0 opened
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: TUN/TAP TX queue length set to 100
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: /sbin/ifconfig tap0 10.0.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.0.0.255
Nov  7 14:13:13 fritz daemon.notice openvpn[1148]: Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: chroot to '/tmp/openvpn' and cd to '/' succeeded
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: GID set to openvpn
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: UID set to openvpn
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: UDPv4 link local (bound): [undef]
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: UDPv4 link remote: [undef]
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: MULTI: multi_init called, r=256 v=256
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: IFCONFIG POOL: base=10.0.0.2 size=10, ipv6=0
Nov  7 14:13:13 fritz daemon.notice openvpn[1152]: Initialization Sequence Completed

Gemeint ist diese Zeile:

OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

Schaut man in die generierte /mod/etc/openvpn.conf fehlt der "route option" tatsächlich ein Gateway:

#  OpenVPN 2.1 Config, Mon Nov  7 14:13:11 CET 2011
proto udp
dev tap0
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
crl-verify /etc/crl.pem
tls-server
port 1194
ifconfig 10.0.0.1 255.255.255.0
push "route-gateway 10.0.0.1"
push "route 192.168.39.0 255.255.255.0"
max-clients 10
mode server
ifconfig-pool 10.0.0.2 10.0.0.11
push "route 10.0.0.0 255.255.255.0"
route 10.0.0.0 255.255.255.0
client-config-dir /clients_openvpn
client-to-client
push "dhcp-option DNS 192.168.39.2"
push "dhcp-option WINS 192.168.39.2"
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Die Clients bekommt zwar das Gateway gepusht, der Server selbst bekommt es aber nicht mitgeteilt. Wenn es hilfreich ist, könnte ich noch einmal Deine damalige config hier aus dem Thread testen?

 

[MaxMuster]

Die Route ist in dieser Form überflüssig. Durch das "ifconfig 10.0.0.1 255.255.255.0" wird das angeschlossene Netz (10.0.0.0 255.255.255.0) schon im Routing bekannt sein.
Der Eintrag ist eigentlich nur für "tun" Configs ohne "topology subnet" erforderlich/sinnvoll (ohne "Multiclient"). Bei allen anderen Konfigs nicht.

Der Fehler macht aber nichts kaputt, ich schaue bei Gelegenheit mal, wie man das abfangen kann.

Jörg

EDIT:

Versuche doch bitte mal, ob diese Änderung in der "openvpn_conf" Besserung bringt (müste so ab Zeile 116 sein):

	if [ "$AUTH_TYPE" = "certs" ]; then
		if [ "$DHCP_RANGE" ]; then
			echo "mode server" >> $CONFFILE
			echo "ifconfig-pool $DHCP_RANGE" >> $CONFFILE
			if [ "$CLIENT2CLIENT" = "yes" ]; then
				echo "push \"route ${DHCP_RANGE%.* *}.0 255.255.255.0\"" >> $CONFFILE		
			else
				echo "push \"route $BOX_IP\"" >> $CONFFILE
			fi
			[B][U][ "$TYPE" = "tun" ] && [ ! $TUNSUBNET ] && [/U][/B]echo "route ${DHCP_RANGE%.* *}.0 255.255.255.0" >> $CONFFILE
		fi

 

[KingTutt]

Teste ich gerne. Ist das eine Änderung zum aktuellen freetz svn oder zu der im Posting 832 referenzierten Version?

EDIT: Frage hat sich erledit, die entsprechende Stelle ist bei beiden genannten Versionen identisch. Habe die Stelle entsprechend geändert, die Datei openvpn_conf nach /tmp/flash/ kopiert und mittels modsave auf der Box verewigt. Hier ist der syslog output nach einem Restart des daemon:

Nov  7 22:39:20 fritz daemon.err openvpn[3216]: event_wait : Interrupted system call (code=4)
Nov  7 22:39:20 fritz daemon.notice openvpn[3216]: TCP/UDP: Closing socket
Nov  7 22:39:20 fritz daemon.notice openvpn[3216]: Closing TUN/TAP interface
Nov  7 22:39:20 fritz daemon.notice openvpn[3216]: /sbin/ifconfig tap0 0.0.0.0
Nov  7 22:39:20 fritz daemon.warn openvpn[3216]: Linux ip addr del failed: could not execute external program
Nov  7 22:39:20 fritz daemon.notice openvpn[3216]: SIGTERM[hard,] received, process exiting
Nov  7 22:39:22 fritz daemon.notice openvpn[3545]: OpenVPN 2.2.1 mipsel-linux [SSL] [LZO2] [MH] [IPv6 payload 20110424-2 (2.2RC2)] built on Nov  7 2011
Nov  7 22:39:22 fritz daemon.warn openvpn[3545]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Nov  7 22:39:22 fritz daemon.notice openvpn[3545]: Diffie-Hellman initialized with 1024 bit key
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: Socket Buffers: R=[110592->131072] S=[110592->131072]
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: TUN/TAP device tap0 opened
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: TUN/TAP TX queue length set to 100
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: /sbin/ifconfig tap0 10.0.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.0.0.255
Nov  7 22:39:23 fritz daemon.notice openvpn[3545]: Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: chroot to '/tmp/openvpn' and cd to '/' succeeded
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: GID set to openvpn
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: UID set to openvpn
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: UDPv4 link local (bound): [undef]
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: UDPv4 link remote: [undef]
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: MULTI: multi_init called, r=256 v=256
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: IFCONFIG POOL: base=10.0.0.2 size=10, ipv6=0
Nov  7 22:39:23 fritz daemon.notice openvpn[3571]: Initialization Sequence Completed

Die Warnung beim Start des OpenVPN daemon [PID 3571] ist weg, den Error (Zeile 1) und die Warnung (Zeile 5) beim Stop [PID 3216] kann man vermutlich ignorieren.

 

[CannyDuck]

Freetz aus OpenVPN Client - VPN Zugang vom lokalen Netz

Ich habe meine FritzBox mit Freetz als OpenVPN-Client eingerichtet und verwende zur Authentifizierung Zertifikate. Die Verbindung wird auch erfolgreich hergestellt. Welche Einstellungen sind in Freetz/der FritzBox notwendig, damit die Rechner im lokalen Netz hinter der Fritzbox auch Zugang zum VPN haben?

VPN-Netz: 10.8.0.1 (Server IP)
Fritzbox-Netz: 192.168.0.1 (FritzBox IP)

Danke für euere Hilfe.

 

[RalfFriedl]

Wenn die Box das Default-Gateway der PCs ist, was normalerweise der Fall ist, muss man nichts ändern, damit die Rechner Zugang zum VPN haben. Die Frage ist, ob die Gegenstelle der VPN-Verbindung den Weg zu den PCs kennt.
Wenn das nicht der Fall ist. muss man ein NAT auf der Box einrichten, oder die Routing-Tabellen der Gegenstelle anpassen.

 

[CannyDuck]

Die Gegenstelle ist in diesem Fall der VPN-Server selbst auf dem ein Dienst läuft. Also ein Rechner hinter der FritzBox z.B. (192.168.0.3) möchte eine Verbindung zu 10.8.0.1 aufbauen. Sind in diesem Fall NAT oder spezielle Routingeinträge erforderlich?

 

[RalfFriedl]

Natürlich ist die Gegenstelle des VPN-Clients der VPN-Server.

Es reicht, wenn Du auf dem Server einen Routing-Eintrag für 192.168.0.0/24 auf das VPN erstellst.

 

[trk]

Hallo zusammen,

ich komme gerade mit OVPN nicht wirklich weiter, vielleicht weiss jemand von Euch Hilfe, mir fällt nichts mehr ein :/

Frisch installierte
Firmware-Version 29.04.87freetz-devel-8125 auf einer 7170.
openvpn external auf USB.

Zertifikate und Keys auf Linux erzeugt und eingetragen.



Debug log:

Wed Nov 16 20:07:12 2011 OpenVPN 2.2.1 mipsel-linux [SSL] [LZO2] [MH] [IPv6 payload 20110424-2 (2.2RC2)] built on Nov 16 2011
Wed Nov 16 20:07:12 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Nov 16 20:07:12 2011 Diffie-Hellman initialized with 1024 bit key
Wed Nov 16 20:07:12 2011 LZO compression initialized
Wed Nov 16 20:07:12 2011 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Nov 16 20:07:12 2011 Socket Buffers: R=[110592->131072] S=[110592->131072]
Wed Nov 16 20:07:12 2011 TUN/TAP device tun0 opened
Wed Nov 16 20:07:12 2011 TUN/TAP TX queue length set to 100
Wed Nov 16 20:07:12 2011 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Nov 16 20:07:12 2011 /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
Wed Nov 16 20:07:12 2011 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Nov 16 20:07:12 2011 chroot to '/tmp/openvpn' and cd to '/' succeeded
Wed Nov 16 20:07:12 2011 GID set to openvpn
Wed Nov 16 20:07:12 2011 UID set to openvpn
Wed Nov 16 20:07:12 2011 UDPv4 link local (bound): [undef]
Wed Nov 16 20:07:12 2011 UDPv4 link remote: [undef]

Portweiterleitung per AVM Firewall bringt in der ar7

"permit udp any any range 1194 1194", 
"permit udp any any range 1194 1194", 
"udp 0.0.0.0:1194 0.0.0.0:1194 0 # openvpn";

Problem:
Trotz richtiger Einträge im Client (Android und Linux) kommt die Verbindung nicht bei der Fritz Box an.

Wo habe ich den Denkfehler bzw. was habe ich übersehen?

Danke im Vorraus!