OpenVPN Server nimmt keine Verbindungen an

[milchbart]

Hallo Leute,

ich probiere jetzt schon eine Weile das Problem in den Griff zu bekomme, scheitere aber vergebens. In meiner Virtuellen Maschine läuft meine Konfig wunderbar, nur auf der Fritzbox will das ganze nicht so wie ich es will.

Der Server läuft und folgendes steht im Log:

Sun Feb  8 00:43:07 2009 OpenVPN 2.1_rc13 mipsel-linux [SSL] [LZO2] [EPOLL] built on Feb  5 2009
Sun Feb  8 00:43:07 2009 Diffie-Hellman initialized with 1024 bit key
Sun Feb  8 00:43:07 2009 WARNING: file '/tmp/flash/box.key' is group or others accessible
Sun Feb  8 00:43:07 2009 Control Channel Authentication: using '/tmp/flash/static.key' as a OpenVPN static key file
Sun Feb  8 00:43:07 2009 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb  8 00:43:07 2009 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb  8 00:43:07 2009 TLS-Auth MTU parms [ L:1592 D:168 EF:68 EB:0 ET:0 EL:0 ]
Sun Feb  8 00:43:07 2009 TUN/TAP device tap0 opened
Sun Feb  8 00:43:07 2009 TUN/TAP TX queue length set to 100
Sun Feb  8 00:43:07 2009 /sbin/ifconfig tap0 192.168.178.253 netmask 255.255.255.0 mtu 1500 broadcast 192.168.178.255
Sun Feb  8 00:43:07 2009 Data Channel MTU parms [ L:1592 D:1450 EF:60 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Feb  8 00:43:07 2009 Listening for incoming TCP connection on [undef]:1194
Sun Feb  8 00:43:08 2009 Socket Buffers: R=[43689->131072] S=[16384->131072]
Sun Feb  8 00:43:08 2009 TCPv4_SERVER link local (bound): [undef]:1194
Sun Feb  8 00:43:08 2009 TCPv4_SERVER link remote: [undef]
Sun Feb  8 00:43:08 2009 MULTI: multi_init called, r=256 v=256
Sun Feb  8 00:43:08 2009 IFCONFIG POOL: base=192.168.178.201 size=29
Sun Feb  8 00:43:08 2009 MULTI: TCP INIT maxclients=5 maxevents=9
Sun Feb  8 00:43:08 2009 Initialization Sequence Completed

Das gleiche steht auch im Log wenn ich mit dem Client versuche eine Verbindung herzustellen. Der Server registriert also gar nicht, dass jemand rein will.
Der Client-Log sieht folgendermaßen aus:

Sun Feb 08 00:49:48 2009 OpenVPN 2.1_rc7 Win32-MinGW [SSL] [LZO2] [PKCS11] built on Jan 29 2008
Sun Feb 08 00:49:48 2009 Control Channel Authentication: using 'static.key' as a OpenVPN static key file
Sun Feb 08 00:49:48 2009 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 08 00:49:48 2009 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 08 00:49:48 2009 LZO compression initialized
Sun Feb 08 00:49:48 2009 Control Channel MTU parms [ L:1592 D:168 EF:68 EB:0 ET:0 EL:0 ]
Sun Feb 08 00:49:48 2009 Data Channel MTU parms [ L:1592 D:1450 EF:60 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Feb 08 00:49:48 2009 Local Options hash (VER=V4): '88107939'
Sun Feb 08 00:49:48 2009 Expected Remote Options hash (VER=V4): 'ad144f1c'
Sun Feb 08 00:49:48 2009 Attempting to establish TCP connection with 212.202.xxx.xxx:80
Sun Feb 08 00:49:49 2009 TCP: connect to 212.202.xxx.xxx:80 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Sun Feb 08 00:49:55 2009 TCP: connect to 212.202.xxx.xxx:80 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)

Meine ar7.cfg wurde entsprechend angepasst:

"tcp 0.0.0.0:80 0.0.0.0:1149 0 # VPN";

Auch wenn ich vom internen Netz versuche eine Verbindung herzustellen (dann direkt auf Port 1149), passiert das gleiche, nichts. Des Weiteren wurde versucht das VPN Netz zu 192.168.200.1 mit einem IP-Pool von 192.168.200.100 - 192.168.200-150 zu erstellen, auch hier gleiches Szenario. Zertifikate und Schlüssel dürften funktionieren, funktionieren ja auf der VM-Ware auch und bis zu dem Teil kommt meine Fritzbox gar nicht. Es wurde auch Port 443-> 1149 und Port 1149->1149 getestet - ohne Erfolg.

Um euch vielleicht meine Konfigs noch zu geben:

server.conf

#  OpenVPN 2.1 Config, Sun Feb  8 00:43:07 CET 2009
proto tcp-server
dev tap
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
mode server
ifconfig-pool 192.168.178.201 192.168.178.229
push "route 192.168.178.253 "
push "route-gateway 192.168.178.253 "
ifconfig 192.168.178.253 255.255.255.0
push "route-gateway 192.168.178.253"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher AES-256-CBC
comp-lzo
keepalive 10 120

client.conf

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
proto tcp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote xxx.dnydns 80

# Most clients don't need to bind to
# a specific local port number.
nobind

# Try to preserve some state across restarts.
persist-key
persist-tun

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert client01.crt
key client01.key

# If a tls-auth key is used on the server
# then every client must also have the key.
tls-remote Fritz_Box_7050
tls-auth static.key 1
auth SHA1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
cipher AES-256-CBC

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

Ich wäre euch sehr dankbar, wenn ihr mir sagen könnt woran das liegt. Spanisch kommen mir die Leerzeichen vor den schließenden Anführungszeichen bei den Routen in der server.conf vor, aber das wird ja so von der Box erzeugt (server.conf wird automatisch anhand der WebCfg erstellt).

Bitte Leute, ihr seid meine letzte Hoffung

 

[cando]

Sun Feb 08 00:49:49 2009 TCP: connect to 212.202.xxx.xxx:80 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)
Sun Feb 08 00:49:55 2009 TCP: connect to 212.202.xxx.xxx:80 failed, will try again in 5 seconds: Connection refused (WSAECONNREFUSED)

Da steht was von port 80 drin, soll dein Tunnel über port 80 gehen?

 

[matze1985]

ja das schrieb er:

Meine ar7.cfg wurde entsprechend angepasst:

"tcp 0.0.0.0:80 0.0.0.0:1149 0 # VPN";

 

[cando]

Das beantwortet nicht die Frage. Warum leitest du nicht

tcp 0.0.0.0:1149 0.0.0.0:1149 0

weiter ? Dein Tunnel Deamon bindet doch auf die 1149, oder willst du einen Tunnel über das http port bauen?

 

[MaxMuster]

Hast du, wenn du auf dem TAP-Device das gleiche Netz wie im LAN nutzt, auch die Brücke eingetragen? Sonst dürfte das problematisch sein...

Auch bei einem Versuch mit dem Netz 192.168.200.x und Port 1194 intern kommt garkeine Reaktion? Dann solltes du es mal mit höherem "verb" versuchen, z.B. "verb 6".


Jörg

 

[milchbart]

Hallo!

Erst einmal danke für eure Antworten.
Ich habe verschiedene Konfigurationen ausprobiert, da aus meinem Client-Netzwerk nur Port 80 und 443 offen ist, habe ich eben Port 80 genommen, da 443 derzeit noch für mein SSH-Dropbear verwendet wird und ich diesen Port nicht zum Testen umstellen wollte (dann hätte ich mich komplett ausgeschlossen und käm nicht mehr rein).

Das Probleme wurde mittlerweile aber teilweise behoben. Ich habe meinen Dropbear abgeschaltet und OpenVPN auf 443 lauschen lassen (443 war def. offen!) und siehe da, die Verbindungen kamen an.

Jetzt aber folgendes Problem: Warum hat die alte Firewallregel nicht funktioniert? Ich ändere die ar7.cfg ab, mach ein ar7cfgchanged und/oder reboot, beide male ist die Regel aber nicht aktiv (nur die ewig alte 443er Regel!).

Würde gerne nach wie vor VPN auf 80 und SSH (zur Sicherheit) auf 443 laufen lassen. Könnt ihr mir da helfen?

Zweitens: Das VPN funktioniert nur wenn der VPN Server im gleichen Subnet läuft (derzeit 192.168.178.200 mit einem Pool von .201 - .210). Warum funktioniert mein VPN nicht, wenn ich den Server unter 192.168.200.1 mit einem Pool von 192.168.200.100 - 192.168.200.150 laufen lassen möchte? Muss ich dann zusätzlich was in der FW einstellen?

Lieben Dank!

Grüße,
Martin

 

[MaxMuster]

Da sind noch ein paar Merkwürdigkeiten zu klären:

- Warum bekommst du, selbst wenn die Portweiterleitung nicht funktioniert, intern keinerlei Ausgabe
- Warum willst du eine Brücke (TAP) nutzen, aber ein anderes Netz? Wäre da nicht "TUN" passender?
- Bist du sicher, dass Port 80 "komplett offen" ist und nicht nur HTTP "erlaubt" ist?


Welche Box und Firmware hast du denn? Vielleich geht eine Weiterleitung von Port 80 auf dei Box selbst garnicht?

Jörg

 

[milchbart]

[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht. Lies noch mal die Forumregeln.]

Hallo Jörg,

vielen Dank für deine Mühe im Voraus! Zu deinen Punkten:

1. Ich habe meine interne Config gerade angepasst und auch auf den 443 geleitet (nachdem der Server jetzt da läuft), jetzt funktionierts intern - wie gesagt, möchte dauerhaft da wieder den SSH-Dropbear und VPN woanders laufen lassen wenn die Firewallregeln mal funktionieren würden - die Lösung ist also noch nicht befriedigend!

2. TAP habe ich genutzt/ wollte ich nutzen damit ich Windowsfreigaben und Broadcasts nutzen kann. Geht meines Wissens nach nicht mit TUN devices? tap0 ist auch unter brinterfaces in der ar7.cfg eingetragen. Geht es also nicht mit TAP ein anderes Netz zu nutzen?

3. Port 80 ist offen, aber auch meinem Bruder (wo von intern keinerlei Beschränkungen existieren) ging es nicht auf einen anderen Port außer dem ganz alten 443.

Warum also werden meine Regeln nicht erkannt? Portscanner haben mir - egal bei welcher Konfiguration - nur den 443 als offen gekennzeichnet.

Meine Box ist die 7170 ohne Branding und Firmware wurde vor kurzem erst erstellt: Firmware-Version 29.04.59freetz-1.0.1

Wäre dir so dankbar wenn ich endlich meine Firewall hinbekomme :groesste:

 

[MaxMuster]

Ich würde zum einen mal testen, wie es mit anderen Weiterleitungen ist. Also z.B. 1194 auf 1194 (von deinem Bruder testen ;-)) .
Kannst du denn Port 80 von extern auf einen "echten" internen Server (also per WebGUI eingetragen z.B. auf 192.168.178.xy) weiterleiten?

Broadcasts werden nur per Bridge weitergeleitet, das stimmt schon, aber warum willst du dann, wenn eh alles weitergeleitet wird, ein anderes Netz?
Das Nutzen von Windows-Freigaben geht aber im übrigen auch per geroutetem Netz (per Tunnel), dann müsstest du entweder den Namen des freigebenden Rechners in die "lmhosts" Datei eintragen oder die Anbindung per IP machen (statt \\Name\Freigabe \\192.168.178.123\Freigabe).

Jörg

 

[milchbart]

[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht. Lies noch mal die Forumregeln.]

Also ich bin der Meinung 1149 auf 1149 und 443 auf 1149 getestet zu haben, das lief alles nicht. Ansonsten werde ich morgen mal den Portable-Webserver auf dem Desktop-Rechner starten und eine reguläre Regel erstellen, wäre ja dann: "tcp 0.0.0.0:80 192.168.178.xx:80", richtig? oder was hat das mit dem Teil hinter der eigentlichen Regel auf sich, also bspw: 0 # VPN? Muss das mit rein?

Werde dann morgen berichten was mit dem Webserver passiert ist und ob die Regel gegriffen hat. Eine direkt auf die 192.168.178.1:1149 gerichtete (via ar7.cfg erstellte) Regel hat auch nicht funktioniert. Warum schreibt man da als Ziel eigentlich immer 0.0.0.0?

Liebe Grüße und großen Dank!

 

[cando]

Das kann ich Dir verraten.

Der dsld von AVM (dsl Ansteuerung und NAT - Firewall) ist intern so gestrickt, dass er die IP Adressen der Fritzbox (die er anhand seiner Interfaces Liste erkennt) automatisch als Port-Forwarding Ziel blockt (Sicherheit). Das Port 443 TCP kann man aber per Fritz Software (Fernwartung) freischalten, da braucht man aber noch irgend eine Sonderlocke am Browser, damit es funzt.

Nun kann die Box aber als Telefonanlage auch VoIP und dafür muss sie doch auf externen Verkehr reagieren können. Da haben sich die Entwickler gedacht, eine Weiterleitung von 0.0.0.0:5060 auf 0.0.0.0:5060 (ist ja keine "interne IP Adresse am Interface) als Trick um die eigene Sperre zu umgehen, was natürlich auf Dauer diesem Forum nicht verborgen bleiben konnte.
Diese Mimik wird auch benutzt bei der Remote-Wartung und bei der AVM VPN (andere Ports).

Damit der Anwender keinen Blödsinn macht wird die 0.0.0.0 im Web-IF natürlich verhindert. Dank Freetz / AVM Firewall kann man als mündiger Besitzer sich diese Mimik auch zunutze machen und Freetz Dienste der Box nach aussen öffnen.

Auf andere interne Adressen kann man aber problemlos forwarden.

Was Firewallregeln angeht, intern arbeitet die Fritz-Box (7270) mit 169.254.2.1 (dsl)/ 169.254.1.1 (lan:0) wenn es z.B. um DNS Lookup, NTP, tr069 oder DynDNS geht (hab ich über Log-Auswertungen von iptables Log herausbekommen), ich vermute mal, dass auch diese Interfaces bei den Diensten der Box nach aussen benutzt werden, hab ich aber noch nicht verifiziert, da ich sie noch nicht gebraucht habe.

 

[milchbart]

Das kann ich Dir verraten.

Der dsld von AVM (dsl Ansteuerung und NAT - Firewall) ist intern so gestrickt, dass er die IP Adressen der Fritzbox (die er anhand seiner Interfaces Liste erkennt) automatisch als Port-Forwarding Ziel blockt (Sicherheit). Das Port 443 TCP kann man aber per Fritz Software (Fernwartung) freischalten, da braucht man aber noch irgend eine Sonderlocke am Browser, damit es funzt.

Nun kann die Box aber als Telefonanlage auch VoIP und dafür muss sie doch auf externen Verkehr reagieren können. Da haben sich die Entwickler gedacht, eine Weiterleitung von 0.0.0.0:5060 auf 0.0.0.0:5060 (ist ja keine "interne IP Adresse am Interface) als Trick um die eigene Sperre zu umgehen, was natürlich auf Dauer diesem Forum nicht verborgen bleiben konnte.

Also ist das Ziel mit einem Wert von 0.0.0.0 nur ein Pseudonym für 192.168.178.1, einfach um es "versteckt" zu halten? Das erklärt dann aber leider nicht, warum andere (neuere) Regeln in meiner ar7.cfg keine Wirkung zeigen.

"tcp 0.0.0.0:1149 0.0.0.0:443" sollte ja auch funktionieren um das Verhalten meiner ar7.cfg zu testen, leider bringt kein Reboot und kein ar7cfgchanged etwas, die Regel ist nicht aktiv

 

[cando]

Hast Du mal mit cat /var/flash/ar7.cfg mal geschaut, ob Deine Regeln drin sind?

P.S. Die neuen Regeln werden erst nach einem Restart vom dsld geladen, ein Reboot ist nicht zwingend nötig....

Was das port 80 angeht, ich würde der AVM zutrauen, dass sie einen forward auf 0.0.0.0:80 TCP auch noch gesondert im dsld gesperrt haben.... ist aber Spekulation.

Du kannst ja mal kurzzeitig ein Forward von 0.0.0.0:80 TCP auf 0.0.0.0:80 TCP einrichten und schauen, ob Du Dein Fritzbox - Interface von aussen erreichen kannst....