Problem mit OpenVPN

[luftdieb]

Hallo,
ich bekomm das OpenVPN mit dem aktuellen Trunk und der AiO (FB7270) Firmware nicht zum laufen. Auf der Freetz Oberfläche kann ich OpenVPN wunderbar konfigurieren (Nach Anleitung von hier) und auch starten. Jedoch kann ich mich nicht einwählen. Ich verwende für den Anfang eine ganz einfache Konfiguration mit einem statischen Key. Ein lokaler und auch von Heise ausgeführter Portscan zeigt keine Reaktion am konfigurierten Standardport 1194. Das lokale Netz befindet sich im IP Range 192.168.178.x. Weiterhin hab eine zusätzliche IP 192.168.178.253 über VirtualIP eingerichtet. Port 1194 hab ich über AVM Firewall CGI geforwarded auf die Virtuelle IP. Die Lokale IP für VPN steht auf 192.168.200.1, bzw. die Remote IP auf 192.168.200.2.
Ein Portscan am zu testzwecken geöffneten Fernzugriff Port 443 ist erfolgreich. Über Telnet seh ich, das der OpenVPN Prozess läuft. Erhöhe ich in den Parametern von OpenVPN das Loglevel, kann ich folgendes aus dem Logfile entnehmen:

OpenVPN 2.1 requires '--script-security 2' Konfiguration in der aktuellen Sicherheitsstufe nicht verfügbar!
....
UDPv4 link local (bound): [undef]:1194

Das SecurityBit hab ich über "echo 2 > /tmp/flash/security" und anschließend modsave geändert. Der Dienst wurde danach noch mal neu gestartet.

Wie kann ich feststellen, ob ein Dienst an Port 1194 aktiv ist (nmap?)

Kennt jemand vielleicht dieses Problem?

Gruß
luftdieb

 

[MaxMuster]

Das mit der "script-security" ist OpenVPN intern (und betrifft automatische Skripts, die nach dem Verbindugsaufbau gestartet werden könnten, was freetz aber so nicht nutzt). Das hat nichts mit /var/flash/security zu tun.
Eine Freigabe auf eine IP der Box funktioniert mit neueren Firmwares nicht mehr; du müsstest diese Freigabe auf 0.0.0.0 ändern. Schau dazu mal ins Wiki oder nutze die Möglichkeiten der AVM-Firewall-GUI in Freetz, die das direkt kann.

Ob der Dienst richtig läuft, zeigt ein netstat auf der Box, oder ein interner Verbindungsversuch aud dem LAN heraus (der natürlich überflüssig ist, aber zeigt, ob der Prozess läuft).


Jörg

 

[colonia27]

Aber müsste luftdieb nicht dennoch die Sicherheitsstufe auf 0 stellen, also:

echo 0 > /tmp/flash/security

wobei es laut den FAQ's seit trunk-3318 eh so heißen sollte wenn ich das richtig verstehe:

echo 0 > /tmp/flash/mod/security

 

[luftdieb]

Hi MaxMuster,
danke für die Antwort. Im unten aufgeführten Link hab ich den Hinweis mit der virtuellen IP gefunden. Ich hatte denoch auch die Freigabe auf 0.0.0.0 probiert, jedoch erfolglos. Die Freigabe hatte ich mit der AVM-Firewall-GUI in Freetz durchgeführt.
Aus dem LAN heraus hatte ich es ja auch schon probiert, was aber keinen Verbindungsaufbau mir ermöglichte. Das mit netstat werd ich heute abend noch mal probieren.
Ich hab irgendwie die Vermutung, das der Dienst nicht am konfigurierten UDP Port 1194 läuft, obwohl ein Prozess openvpn gestartet ist...

Gruß
luftdieb

 

[matze1985]

Poste doch mal deine config und den bereich der ar7.cfg
ob der dienst auf besagtem Port läuft kannst du intern mit netstat sehen.

 

[luftdieb]

Hallo,
irgendwie versteh ich das nicht. Der DIenst läuft auf UDP:1194 und mit ps ist er auch zu sehen... Hier der Auszug von "ps" und "netstat"

/var/flash # netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:5060            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5031            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:49000           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:51112           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:2767            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN
tcp        0      0 localhost:1011          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1012            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8118            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN
tcp        0      0 localhost:8888          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1085            0.0.0.0:*               LISTEN
tcp        0      0 localhost:4908          localhost:1011          ESTABLISHED
tcp        0      0 localhost:1011          localhost:4908          ESTABLISHED
tcp        0    139 fritz.box:23            Bomberpilot.fritz.box:1284 ESTABLISHED
tcp        0      1 fritz.box:4686          MicroXP.fritz.box:14013 SYN_SENT
udp        0      0 0.0.0.0:1025            0.0.0.0:*
udp        0      0 0.0.0.0:1026            0.0.0.0:*
udp        0      0 0.0.0.0:1027            0.0.0.0:*
udp        0      0 0.0.0.0:1028            0.0.0.0:*
udp        0      0 0.0.0.0:1030            0.0.0.0:*
udp        0      0 0.0.0.0:7077            0.0.0.0:*
udp        0      0 0.0.0.0:5031            0.0.0.0:*
udp        0      0 0.0.0.0:1194            0.0.0.0:*
udp        0      0 0.0.0.0:53              0.0.0.0:*
udp        0      0 localhost:323           0.0.0.0:*
udp        0      0 0.0.0.0:5060            0.0.0.0:*
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp        0      0 0.0.0.0:5355            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
raw        0      0 0.0.0.0:2               0.0.0.0:*               2
raw        0      0 0.0.0.0:2               0.0.0.0:*               2
raw        0      0 0.0.0.0:2               0.0.0.0:*               2
raw        0      0 0.0.0.0:2               0.0.0.0:*               2

/var/mod/root #
/proc/tffs: info request: success
/var/mod/root # ps
  PID USER       VSZ STAT COMMAND
    1 root      1436 S    init
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW   [watchdog/0]
    4 root         0 SW<  [events/0]
    5 root         0 SW<  [khelper]
    6 root         0 SW<  [kthread]
   18 root         0 SW<  [kblockd/0]
   32 root         0 SW   [pdflush]
   33 root         0 SW   [pdflush]
   34 root         0 SW<  [kswapd0]
   35 root         0 SW<  [aio/0]
   72 root         0 SW   [pm_info]
   76 root         0 SW<  [CPMAC]
   80 root         0 SW   [mtdblockd]
  102 root         0 SW   [tffsd_mtd_0]
  302 root         0 SW   [cleanup_timer_f]
  313 root         0 SW   [dectuart_route]
  321 root         0 SWN  [jffs2_gcd_mtd5]
  330 root      1592 S    /bin/sh /etc/init.d/rc.S
  346 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  350 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  351 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  352 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  353 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  355 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  356 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  357 root      2848 S    /usr/sbin/dsl_daemon -f /lib/modules/vinax_fw_adsl.bin -y /nv/get_fw.sh
  362 root      1044 R    /usr/sbin/vinax_atmoam
  402 root         0 SW<  [capi_oslib]
  403 root         0 SW<  [capi_oslib]
  404 root         0 SW   [capitransp]
  410 root         0 SW   [glob_codecs]
  414 root         0 RW   [avm_dect_thread]
  431 root         0 SW<  [khubd]
  511 root      8792 S N  ctlmgr
  701 root         0 SW<  [scsi_eh_0]
  702 root         0 SW<  [usb-storage]
  902 root      8792 S N  ctlmgr
  906 root      8792 S N  ctlmgr
  907 root      8792 S N  ctlmgr
 1119 root      3044 S    hostapd -B /var/tmp/wlan_ath0_topology
 1148 root      3336 S    upnpd
 1152 root      3148 S    multid -u
 1165 root      3524 S    dsld -i -n -g
 1172 root      2708 S N  usermand
 1181 root      1620 R    telnetd -l /sbin/ar7login
 1182 root      6436 R    telefon a127.0.0.1
 1186 root      4804 S <  voipd
 1191 root      2796 S    pbd
 1192 root      2796 S    pbd
 1197 root      1624 S    /usr/sbin/inetd
 1201 root      1112 S    /bin/run_clock -c /dev/tffs -d
 1203 root      2796 S    pbd
 1204 root      2796 S    pbd
 1212 root      6436 S    telefon a127.0.0.1
 1213 root      6436 S    telefon a127.0.0.1
 1214 root      6436 S    telefon a127.0.0.1
 1220 root      3620 S    dect_manager
 1250 root      2824 S    /usr/bin/faxd -a
 1254 root      1888 S    capiotcp_server capiotcp_server -p5031 -m99
 1278 root      1636 S    syslogd -L -C
 1280 root      1620 S    /sbin/klogd -c 4
 1408 root      1760 S    privoxy --pidfile /var/run/privoxy.pid /mod/etc/privoxy/config
 1409 root      3336 S    upnpd
 1410 root      3336 S    upnpd
 1411 root      3336 S    upnpd
 1487 root      1436 S    init
 1494 root         0 RWN  [kdsld_token]
 1519 root      6436 S    telefon a127.0.0.1
 1520 root      6436 S    telefon a127.0.0.1
 1521 root      6436 S    telefon a127.0.0.1
 1558 root      1428 S    /sbin/chronyd -f /var/tmp/chrony.conf
 1787 root      1620 S    httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.conf -h /usr/mww/
 2043 root      1452 S    -sh
 2198 openvpn   1776 S    openvpn --config /mod/etc/openvpn.conf --writepid /var/run/openvpn.pid
 2453 root      1432 R    ps

Syslog meldet folgendes:

May 20 21:24:58 fritz daemon.notice openvpn[2195]: OpenVPN 2.1_rc15 mipsel-linux [SSL] [LZO2] [EPOLL] built on May 19 2009
May 20 21:24:58 fritz daemon.warn openvpn[2195]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
May 20 21:24:58 fritz daemon.notice openvpn[2195]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
May 20 21:24:58 fritz daemon.notice openvpn[2195]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May 20 21:24:58 fritz daemon.notice openvpn[2195]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
May 20 21:24:58 fritz daemon.notice openvpn[2195]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May 20 21:24:58 fritz daemon.notice openvpn[2195]: LZO compression initialized
May 20 21:24:58 fritz daemon.notice openvpn[2195]: TUN/TAP device tun0 opened
May 20 21:24:58 fritz daemon.notice openvpn[2195]: TUN/TAP TX queue length set to 100
May 20 21:24:58 fritz daemon.notice openvpn[2195]: /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
May 20 21:24:58 fritz daemon.notice openvpn[2195]: Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
May 20 21:24:58 fritz daemon.notice openvpn[2198]: chroot to '/tmp/openvpn' and cd to '/' succeeded
May 20 21:24:58 fritz daemon.notice openvpn[2198]: GID set to openvpn
May 20 21:24:58 fritz daemon.notice openvpn[2198]: UID set to openvpn
May 20 21:24:58 fritz daemon.notice openvpn[2198]: Socket Buffers: R=[108544->131072] S=[108544->131072]
May 20 21:24:58 fritz daemon.notice openvpn[2198]: UDPv4 link local (bound): [undef]:1194
May 20 21:24:58 fritz daemon.notice openvpn[2198]: UDPv4 link remote: [undef]

[Beim Client erfolgt folgendes:

Wed May 20 20:36:56 2009 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Wed May 20 20:36:56 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Wed May 20 20:36:56 2009 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 20 20:36:56 2009 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 20 20:36:56 2009 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 20 20:36:56 2009 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 20 20:36:56 2009 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{C90408A8-9D7D-405E-AA5D-B371B662E434}.tap
Wed May 20 20:36:56 2009 TAP-Win32 Driver Version 8.4 
Wed May 20 20:36:56 2009 TAP-Win32 MTU=1500
Wed May 20 20:36:56 2009 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.200.2/255.255.255.252 on interface {C90408A8-9D7D-405E-AA5D-B371B662E434} [DHCP-serv: 192.168.200.1, lease-time: 31536000]
Wed May 20 20:36:56 2009 Successful ARP Flush on interface [3] {C90408A8-9D7D-405E-AA5D-B371B662E434}
Wed May 20 20:36:56 2009 WARNING: You have selected '--ip-win32 dynamic', which will not work unless the TAP-Win32 TCP/IP properties are set to 'Obtain an IP address automatically'
Wed May 20 20:36:56 2009 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Wed May 20 20:36:56 2009 Local Options hash (VER=V4): '1db64539'
Wed May 20 20:36:56 2009 Expected Remote Options hash (VER=V4): '27d76c6d'
Wed May 20 20:36:56 2009 UDPv4 link local: [undef]
Wed May 20 20:36:56 2009 UDPv4 link remote: 87.146.72.195:1194

Ich bekomm auch eine IP zugewiesen (192.168.200.2) . Ein Ping an 192.168.200.1 geht jedoch ins leere...

Der Auszug aus der AR7.CFG

                dsldpconfig {
                        security = dpsec_firewall;
                        lowinput {
                                policy = "permit";
                                accesslist =
                                             "permit udp any host 0.0.0.0 eq 1194",
                                             "deny ip any 242.0.0.0 255.0.0.0", /*AVM*/
                                             "deny ip any host 255.255.255.255", /*AVM*/
                                             "deny udp any any range 161 162", /*AVM*/
                                             "deny udp any any eq 111";/*AVM*/
                        }
                        lowoutput {
                                policy = "permit";
                        }
                        highinput {
                                policy = "permit";
                        }
                        highoutput {
                                policy = "permit";
                                accesslist =
                                             "permit udp host 192.168.178.1 any eq 1194",
                                             "reject ip any 242.0.0.0 255.0.0.0", /*AVM*/
                                             "deny ip any host 255.255.255.255", /*AVM*/
                                             "reject ip any 169.254.0.0 255.255.0.0", /*AVM*/
                                             "reject udp any any range 161 162", /*AVM*/
                                             "reject udp any any eq 111";/*AVM*/
                        }
                        forwardrules = "tcp 0.0.0.0:443 0.0.0.0:443 0",
                                       "udp 0.0.0.0:1194 0.0.0.0:1194 0 # OpenVPN";

Und hier angefügt die .config

Hoffentlich kann jemand hier damit was anfangen...

Gruß
luftdieb

 

[colonia27]

bisher kann ich zumindest sagen, daß dein Dienst läuft. So siehts bei mir auch aus.

Was matze allerdings meinte, ist deine client-config des OpenVPN

 

[matze1985]

auch die server war nicht verkehrt, jetzt fehlt noch die client um Fehler auszuschließen.

 

[colonia27]

auch die server war nicht verkehrt,

habs ichs denn so auf den Augen? Wo ist denn die server-conf? :shock:
Oder fehlen bei deinem "war" nur die Punkte überm a ?

 

[luftdieb]

Allright. Hier also die client-config:

 remote 192.168.178.1
  proto udp
  dev tun
  ifconfig 192.168.200.2 192.168.200.1
  route 192.168.178.0 255.255.255.0
  secret client.key
  tun-mtu 1500
  float
  mssfix
  nobind
  verb 3
  keepalive 10 120

... und die server-config:

#  OpenVPN 2.1 Config, Wed May 20 23:32:20 CEST 2009
proto udp
dev tun
secret /tmp/flash/static.key
port 1194
ifconfig 192.168.200.1 192.168.200.2
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Mit einer falschen client.key Datei erscheint im Syslog folgendes:
May 20 23:23:30 fritz daemon.err openvpn[3839]: Authenticate/Decrypt packet error: packet HMAC authentication failed

Wird die richtige client.key verwendet, erscheint diese Zeile nicht. FAZIT: Irgendwie führt der Client einen Verbindungsaufbau durch... Aber halt nicht komlett.

Die IP 192.168.200.2 wurde dem TunnelAdapter am Client zugewiesen (ipconfig). Jedoch kann ich die IP 192.168.200.1 nicht anpingen und es wurde auch keine gatewayadresse zugewiesen. Wenn ich die IP 192.168.200.2 statisch dem TunnelAdapter zuweise und das Gateway eintrage, kann ich die 192.168.200.1 auch nicht anpingen.

Wird das detailierte Logging von OpenVPN aktiviert, kann ich bei der Einwahl keinerlei Veränderung feststellen:

/var/tmp # tail -f debug_openvpn.out
Wed May 20 23:32:20 2009 TUN/TAP device tun0 opened
Wed May 20 23:32:20 2009 TUN/TAP TX queue length set to 100
Wed May 20 23:32:20 2009 /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
Wed May 20 23:32:20 2009 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Wed May 20 23:32:20 2009 chroot to '/tmp/openvpn' and cd to '/' succeeded
Wed May 20 23:32:20 2009 GID set to openvpn
Wed May 20 23:32:20 2009 UID set to openvpn
Wed May 20 23:32:20 2009 Socket Buffers: R=[108544->131072] S=[108544->131072]
Wed May 20 23:32:20 2009 UDPv4 link local (bound): [undef]:1194
Wed May 20 23:32:20 2009 UDPv4 link remote: [undef]

 

[MaxMuster]

Zitat aus dem Wiki zum Paket unter "Ein paar Tips wenn es nicht gleich so klappt":

Wenn es was anderes ist, hilt nur noch der Vergleich der Konfigurationen Punkt für Punkt. Eigentlich gibt es nur zwei Arten von Parametern:
Solche, die identisch sein müssen und solche, die "spiegelverkehrt" auftreten müssen.

* Die "identischen" sind z.B. Cipher, "comp-lzo", tls-auth, das benutzte Protokoll (UDP/TCP) und der Port,
* "Spiegelbildlich" sind die IPs beim TUN, die Routing-Einträge, die Server- / Client-Parameter wie "tls-server/tls-client", push und pull.

Die Hervorhebung ist von mir...

Jörg

 

[luftdieb]

OK. Vielen Dank, wer lesen kann, ist klar im Vorteil :~(((
Hab den cipher BF-CBC und comp-lzo auf dem client hinzugefügt und siehe da, "Initialization sequence completed" erscheint im logfile des OpenVPN servers.
Jedoch bleibt der Client im Zustand "DHCP Adresse beziehen" hängen. Das OpenVPN Client Fenster schließt sich mit dem Vermerk "Initialization sequence completed". Ein ipconfig ergibt 192.168.200.2 mit Subnet Mask 255.255.252. Jedoch keine Gateway Adresse. Wähle ich die verbindung ab, erscheint im ipconfig "Media disconnected". Fazit: Die Einwahl erfolgt, jedoch ist keine Verbindung möglich. Oder liegt das jetzt daran, das ich im Moment nur lokal arbeite und dadurch 2 routen ins gleiche Netz möglich wären?
Mein Client hat ja den 1. Netzwerkadapter mit 192.168.178.29 und dann bei einer bestehenden Verbindung den 2. Netzwerkadapter mit 192.168.200.2...

EDIT: Wenn ich über den DynDNS account mich einwähle, kann ich auch die 192.168.200.1 anpingen. Ich muss das morgen mal von meinem Arbeitsplatz aus probieren ;-)

EDIT2: Auch wenn ich mich nicht eingewählt hab (client hat nur die 192.168.178.29) kann ich 192.168.200.1 anpingen. Fazit: Route in der FritzBox erfüllt wohl ihren Zweck. Komisch ist nur, das ich die IP nicht mehr anpingen kann, wenn ich mich über OpenVPN auf 192.168.178.1 einwähle. Wähle ich mich über DynDNS Adresse ein, ist die IP 192.168.200.1 erreichbar, obwohl mein TunnelAdapter immer die gleiche IP 192.168.200.2 zugewiesen bekommt. --> ???

Gruß
luftdieb

 

[MaxMuster]

Schön, wenn es klappt.
Eigentlich sollte es auch von intern gehen, dein Problem dürfte der zusätzliche Routingeintrag sein: Du routest 192.168.178.0 (auch) durch das VPN, sobald der Adapter da ist. Zugleich musst aber die Box im Netz (vermutlich 192.168.178.1) erreichen, um das VPN nutzen zu können und so hast du eine prima unendliche Routing-Schleife gebaut ;-).

Jörg

 

[luftdieb]

Hallo,
an alle vielen Dank für die Unterstützung. Mein Problem lag vermutlich an der Firewall in der Firma, die den Zugang zum OpenVPN Server über Port UDP1194 geblockt hat.

Gruß
luftdieb