29.04.29 und openvpn

Hi!

Ist ja alles schön und gut hier, aber hat denn schon jemand das Problem mit dem W-LAN hinbekommen wenn man diesen Befehl "mknod" ausgeführt hat?
 
... der Ton macht die Musik

Hallo Grobi,

grobi2000 schrieb:
Ist ja alles schön und gut hier, aber hat denn schon jemand [...snip...]
... ich finde deine Formulierung gelinde gesagt etwas ungeschickt, denn damit "disqualifizierst" du die anderen Mitglieder. Hier darf jeder fragen (und antworten) und einen garantierten Antwort- oder Lösungsanspruch gibt es nicht. Zumal wenn, gestatte mir den Einwurf, dein eigener Beitrag zu deinem Problem sich weder durch eine genaue Fehler- und Konfigbeschreibung hervortut
grobi2000 schrieb:
Das Problem habe ich auch!!!!
noch durch besonders konstruktive Eigenbeiträge zu Lösungsansätzen
grobi2000 schrieb:
Hatte mittlerweile die Schn... voll und habe wieder die alte Firmware (29.04.25) mit dem 2.4er Kernel aufgespielt.

Just my 2 cents

Jörg
 
Hallo MaxMuster

Also die PC-( mit 192.168.182.11 ) hinter 7170 Clientbox-(mit IP 192.168.182.1) hat doch zwar ein Ping an die PC-(mit IP 192.168.0.9) hinter 7050-Serverbox-( mit IP 192.168.0.1) aber keine Zugriff auf Freigaben Ordner!
umgekehrt ist Funktioniert einwanfrei! Ping und Zugriff auf Freigaben!

Habe ich auch die " net view und net use " befehl probiert finden aber keine PC bzw. Freigaben.

So habe ich die LMHOST editiert:
Code:
192.168.0.9     Homepc	#Homepc
192.168.0.15    PC-1 	# PC-1

Wie so Funktioniert von Server seite in die Netz hinter dem Client Funktioniert ganz einfach und umgekert aber nicht?

Danke für Antwort
Grüß
Hana
 
Hi!

Ich habe irgendwie das gleiche Problem. Ich hatte das OpenVPN mit static-key laufen und habe es auf Zertifikate umgestellt (siehe zwei bis eine Seite vorher).
Mit dem Static-Key konnte ich auch von überall auf alle Rechner in beiden Netzwerken zugreifen. Seit den Zertifikaten schaut es anders aus.

Meine Serverbox (7170) mit IP 192.168.188.1 kann das Netzwerk der anderen Box (7050) mit IP 192.168.178.1 nicht pingen. Umgekehrt läuft das. Interessant fand ich einen Eintrag unter telnet->route bei der Serverbox, wobei das 192.168.178.0-Subnet per "lan" und nicht per "tap0" geroutet wird. Bei der anderen Box ist der umgekehrte Eintrag ein tap0-Eintrag. Woran kann das liegen?

server-config
Code:
dev tap
dev-node /var/tmp/tun
mode server
tls-server
proto tcp-server
port 1194
tun-mtu 1500
ca /var/tmp/ca.crt
cert /var/tmp/fritzbox.crt
key /var/tmp/secret.key
dh /var/tmp/dh2048.pem
auth SHA1
cipher AES-256-CBC
server 192.168.200.0 255.255.255.0
client-to-client
ifconfig-pool-persist ipp.txt
float
keepalive 10 60
verb 4
mssfix
route 192.168.178.0 255.255.255.0
push "route 192.168.188.1 255.255.255.0"
daemon

Client-Config:
Code:
dev tap
dev-node /var/tmp/tun
proto tcp-client
tls-client
ns-cert-type server
ca /var/tmp/ca.crt
cert /var/tmp/fritz.crt
key /var/tmp/secret.key
auth SHA1
cipher AES-256-CBC
port 1194
ping 15
ping-restart 120
resolv-retry 60
tun-mtu 1500
mssfix
persist-tun
persist-key
verb 4
pull
route 192.168.188.0 255.255.255.0
push "route 192.168.178.1 255.255.255.0"

Der Client hat diese Route-Zeile drin und die umgekehrte Zeile fehlt am Server:
Code:
192.168.188.0   192.168.200.1   255.255.255.0   UG    0      0        0 tap0
Grüße
Alex
 
Zuletzt bearbeitet:
Schön

Hallo MaxMuster!

Finde es ja toll das du mich zitierst, aber du hättest mal genauer schauen sollen.
Dann hättest du nämlich gesehen, dass ich schon etwas zur Lösung des Problems beitrage:
Hi! Crevlon
Habe es mal versucht ein wenig zu erklären.
Hoffe es hilft dir!!

Zitat:
#!/bin/sh

# set hostname to fritz.box
hostname fritz.box

# load VPN-Server (OpenVPN)

Ab hier wird es interessant !!!
Die Fritzbox wartet bis die Internetverbindung hergestellt ist
# wait for server
while !(ping -c 1 google.de)
do
sleep 5
done

Hier wird das tun-device erstellt das OpenVPN benötigt
# Create tun-device
mknod /var/tmp/tun c 10 200

# change dir
cd /var/tmp

Die KEY Datei wird erstellt. Hier musst du den Inhalt deiner KEY Datei einfügen:
# write 'secret.key' to file
cat > /var/tmp/fritzbox.key << 'ENDSECRETKEY'
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ENDSECRETKEY
Die Frei-Zeile zwischen xxxxxxxxxxxxxx und ENDSECRETKEY ist sehr wichtig da ansonsten OpenVPN mit der erstellten Datei nichts anfangen kann. Weiß allerdings nicht warum. Ist einfach so!


Hier musst du den Inhalt deiner DH1024.PEM Datei einfügen:
# write 'dh1024.pem' to file
cat > /var/tmp/dh1024.pem << 'ENDDH1024'
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
ENDDH1024

Hier den Inhalt deiner CRT Datei einfügen:

# write 'fritzbox.crt' to file
cat > /var/tmp/fritzbox.crt << 'ENDFRITZ'
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
ENDFRITZ

Und den Inhalt der CA.CRT
# write 'ca.crt' to file
cat > /var/tmp/ca.crt << 'ENDCA'
-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
ENDCA

Und nun die Server Konfiguration
# write 'server.conf' to file
cat > /var/tmp/server.conf << 'ENDCONFIG'
# OpenVPN v2.0.5 config:
#
# Grundsaetzliches
port 1194
proto udp
dev tap
# Server-Einstellungen
mode server
tls-server
server 10.0.0.0 255.255.255.0 IP und SUBNETZ deines Servers
client-to-client Clienten können sich „sehen“
# Dies ist der IP-Bereich von eurem FritzBox-LAN
push "route 192.168.5.1 255.255.255.0" Das Rote ist die IP Adresse deiner Fritzbox im normalen Lan

192.168.0.0 ist der IP Bereich des Client 02, Das heißt wenn eine Anfrage auf z.B. die IP 192.168.0.5 kommt, leitet die Fritzbox an die 10.0.0.3 weiter.
route 192.168.0.0 255.255.255.0 10.0.0.3

192.168.100.0 ist der IP Bereich des Client 03, Das heißt wenn eine Anfrage auf z.B. die IP 192.168.100.5 kommt, leitet die Fritzbox an die 10.0.0.4 weiter.
route 192.168.100.0 255.255.255.0 10.0.0.4
# Authentifizierung und Verschluesselung
ca /var/tmp/ca.crt
cert /var/tmp/fritzbox.crt
key /var/tmp/fritzbox.key
dh /var/tmp/dh1024.pem
auth SHA1
cipher AES-256-CBC
# Sonstiges
ifconfig-pool-persist ipp.txt
status /var/media/ftp/USBBAR-Partition-0-1/status/openvpn-status.log
#comp-lzo
ping 10
push "ping 10"
ping-restart 60
push "ping-restart 60"
ENDCONFIG

In dieser Datei wird festgelegt welche IP die Clienten zugeteilt bekommen
# write 'ipp.txt' to file
cat > /var/tmp/ipp.txt << 'ENDIPP'
client01,10.0.0.2
client02,10.0.0.3
client03,10.0.0.4
client04,10.0.0.5
client05,10.0.0.6
ENDIPP


# load files

wget http://DeinWebSpace/openvpn

Die Dateien werden ausführbar gemacht
# make them executable
chmod +x /var/tmp/openvpn
chmod 600 /var/tmp/server.conf
chmod 600 /var/tmp/ipp.txt
chmod 600 /var/tmp/fritzbox.key

# start OpenVPN
/var/tmp/openvpn --cd /var/tmp –-daemon --config server.conf --dev-node /var/tmp/tun

Du kannst auch OpenVPN anstatt auf einem Webspace auf deinem USB-Stick der an der FB hängt kopieren und von dort aus starten

Diese Diskusionen hier haben meiner Meinung nach nichts mit OpenVPN speziell mit dem neuen 2.6er Kernel zu tun. Die Konfiguration ist bei dem 2.4er die selbe und wurde hier schon mehr als genug besprochen und es gibt super viele Anleitungen dazu!

Das Thema lautet: 29.04.29 und openvpn

und nicht wie richte ich OpenVPN auf der FritzBox ein.
Oder täusche ich mich da?

Schönen Gruß, Grobi
 
Die Diskussion hier begann auch mit dem kernel26 Problem, das dazu geführt hat, dass das Device auf /var/tmp/tun geändert werden musste. Das Folgeprobleme auftraten liegt in der Natur der Sache und würde wenig Sinn machen, diese woanders zu diskutieren. Wer den Thread hier verfolgt hat, weiß, womit ich zwei Seiten zuvor angefangen habe und nun geht mein Problem weiter. Im Übrigen ist mein Thema "Wie bekomme ich OpenVPN auf die FritzBox mit der Version 29.04.29" und passt somit hervorragend hier rein.
 
Hi Grobi,

ich glaube, da hast du mich missverstanden:
grobi2000 schrieb:
Hallo MaxMuster!

Finde es ja toll das du mich zitierst, aber du hättest mal genauer schauen sollen.
Dann hättest du nämlich gesehen, dass ich schon etwas zur Lösung des Problems beitrage:
Ich möchte hier keinen Kleinkrieg beginnen und habe nie gesagt, dass du "nie etwas beigetragen hättest". Was mich geärgert hat, war, dass ich deinen Beitrag nicht ganz fair den anderen gegenüber fand, weil er deren Probleme "kleinredet". Und war der Meinung, dass nur(!) bezogen auf deine oben gestellten Frage "...hat denn schon jemand das Problem mit dem W-LAN hinbekommen wenn man diesen Befehl "mknod" ausgeführt hat?" bislang wenig Infos von dir rüberkamen, was es anderen nicht unbedingt einfacher macht, das Problem genauer anzusehen...

Vielleicht war ich etwas dünnhäutig, aber für mich hörte sich das an wie "hört auf zu jammern mit euren (unwichtigen) Problemen und löst erstmal meins (denn das ist wichtig)".
Ich habe keineswegs vor jemanden zu beleidigen und sollte das so rübergekommen sein, tut es mir leid.

grobi2000 schrieb:
Das Thema lautet: 29.04.29 und openvpn

und nicht wie richte ich OpenVPN auf der FritzBox ein.
... vollkommen ACK. Ich denke, dass es in vielen Fällen zunächst nicht ganz klar ist, was der Auslöser für Probleme ist, da sollte man vielleicht etwas nachsichtig sein, aber grundsätzlich sollte der Thread nicht "abrutschen", da gebe ich dir Recht. Aber wenn das deine Aussage war, dafür hätte ich eben eine etwas andere Wortwahl besser gefunden...

Ich würde sagen: Lass uns das Thema voran bringen, o.k.?!?
Jörg
 
Hi MaxMuster,

Vergessen wir das ganze! Will ja auch keinen Kleinkrieg hier anfangen. Bin ja nicht der Meinung, dass die Probleme der Anderen unwichtig sind, aber mit ein bißchen Suche bei Google etc. finden man unendlich viele Anleitungen dazu!

Naja, egal!
Wie gesagt, vergessen wir das einfach und stecken unsere Energie in die Lösung der Probleme!!!

Schönen Gruß

Grobi
 
Hallo zusammen,

@Alex
AlGates schrieb:
Interessant fand ich einen Eintrag unter telnet->route bei der Serverbox, wobei das 192.168.178.0-Subnet per "lan" und nicht per "tap0" geroutet wird.
Ich gehe mal stark davon aus, dass darin das eine Problem liegt: Die Boxen haben immer noch die "Not-IP" 192.168.178.254 und damit eine Route in dieses Netz. Die müsstest du vermutlich rausnehmen oder auf der Serverbox eine "passendere" Route eintragen (so z.B. 192.168.178.0 255.255.255.128 auf den Client routen, damit sollte dann der IP-Bereich von 192.168.178.1-126 erreichbar sein). Ansonsten muss ich gestehen, habe ich immer ohne den server-Befehl gearbeitet. Mir scheint, dass in deiner Config die eigene Adresse in dem "TAP-Netz" fehlt (hat es überhaupt eine?): Du weist dem Client eine IP 192.168.200.1 zu, deine Server-Box hat aber keine IP in diesem IP-Netz?!? In meiner Konfig habe ich den Befehl (dann werden natürlich die IPs nicht ab der 192.168.200.1 vergeben)
Code:
ifconfig 192.168.200.1 255.255.255.0
ifconfig-pool 192.168.200.10 192.168.200.20
Dann sollten sowohl das Server- als auch das Client-TAP-Device im Netz 192.168.200.x sein...

@hanuta
Da die Pings funktionieren denke ich, dass das nicht mehr am openvpn liegt, sondern an der "Microsoft-Netz" Problematik, was hier (wie grobi2000 nicht ganz zu unrecht anmerkt) etwas den Rahmen sprengt. Dafür solltest du vielleicht wenn du garnicht weiterkommst ein "neues Thema" eröffnen. Trotzdem zum Thema noch kurz: Wenn die Net Befehle keine Fehlermeldung liefern ("Netzwerkpfad nicht gefunden" oder so), sollte die Sache eigentlich klappen.
hanuta schrieb:
So habe ich die LMHOST editiert:
Nur zur Sicherheit: die Datei heißt lmhosts! Ob's klappt zeigt ein Ping auf den Namen (also in der Art "ping Homepc")...

@grobi2000
grobi2000 schrieb:
Wie gesagt, vergessen wir das einfach und stecken unsere Energie in die Lösung der Probleme!!!
Gerne. Ich kann bei mir deine WLAN-Geschichte (mangels einer etsprechenden Box) nicht nachvollziehen, will aber gerne meinen begrenzten Hirnschmalz mit einbringen ;-).
Interessant wäre für mich diese Fragen (sofern du die nochmal "reproduieren" könntest)
- bei welchen WLAN-Änderungen tritt dieses Verhalten auf?
- steht zu dem Zeitpunkt, wenn die Box "die WLAN-Waffen streckt" was im Log?
- tritt das Verhalten auch auf, wenn du den "mknod-Befehl" nicht in der debug.cfg sondern im Terminal absetzt?
- gibt es Änderungen in den laufenden Prozessen (also z.B. ein ein "ps" vor und nach dem "WLAN-Absturz")?

Grüße

Jörg
 
Zuletzt bearbeitet:
MaxMuster schrieb:
Hallo zusammen,

@Alex

Ich gehe mal stark davon aus, dass darin das eine Problem liegt: Die Boxen haben immer noch die "Not-IP" 192.168.178.254 und damit eine Route in dieses Netz. Die müsstest du vermutlich rausnehmen oder auf der Serverbox eine "passendere" Route eintragen (so z.B. 192.168.178.0 255.255.255.128 auf den Client routen, damit sollte dann der IP-Bereich von 192.168.178.1-126 erreichbar sein). Ansonsten muss ich gestehen, habe ich immer ohne den server-Befehl gearbeitet. Mir scheint, dass in deiner Config die eigene Adresse in dem "TAP-Netz" fehlt (hat es überhaupt eine?): Du weist dem Client eine IP 192.168.200.1 zu, deine Server-Box hat aber keine IP in diesem IP-Netz?!? In meiner Konfig habe ich den Befehl (dann werden natürlich die IPs nicht ab der 192.168.200.1 vergeben)
Code:
ifconfig 192.168.200.1 255.255.255.0
ifconfig-pool 192.168.200.10 192.168.200.20
Dann sollten sowohl das Server- als auch das Client-TAP-Device im Netz 192.168.200.x sein...

Hallo Jörg,

danke erstmal für deine Mühen.
Ich habe vorhin selbst noch ein wenig dran gewerkelt und mir was ähnliches zu dem 178er-IP-Problem gedacht. Aus dem Grund hatte ich versucht, die andere FB von 192.168.178.1 auf 192.168.187.1 zu ändern. Trotzdem führt das zu keiner Verbesserung der Situation. Das gleiche Problem besteht weiterhin.

Ich muss gestehen, dass ich den server-Befehl selbst nicht so ganz verstehe. Die Server-Box bekommt dadurch irgendwie die IP 192.168.200.1 und aus der Datei ipp.txt sollte er eigentlich IPs für die ganzen Clients bereitstellen. Das funktioniert aber irgendwie nicht so richtig, da die clients andere IP-Adressen bekommen, als dort festgelegt. So habe ich in der Datei eigentlich 200.2-200.6 drinstehen und meine Client-Box hat vorhin mal die 192.168.200.10 bekommen.
Ich hab's auch mal mit ifconfig und ifconfig-pool versucht, aber das war auch nicht sehr erfolgreich. Hat nur dazu geführt, dass ich meine Client-Box nicht mehr pingen konnte, obwohl die im VPN war. :-(


Funktioniert der push-Befehl von der Client-Box auf den Server überhaupt? Auf jeden Fall gibt es eine Route auf das Client-IP-Subnet, aber dieses wird über das Gateway 192.168.200.2 geleitet. Das wäre auch das, was der Client aufgrund die IP-Tabelle bekommen müsste, was er aber leider nicht hat... :-(
 
Zuletzt bearbeitet:
Hi,
AlGates schrieb:
Funktioniert der push-Befehl von der Client-Box auf den Server überhaupt?
Ich glaube nicht, weiss es aber nicht genau. Aber da du den Befehl "route" auf dem Server drin hast, sollte das eigentlich auch nicht nötig sein...

Wenn eine Route da ist (wenn auch auf die "falsche IP") geht es ja in die richtige Richtung. Bliebe die Frage, warum der Client eine andere IP bekommt, als er per Config haben sollte. Die ipp.txt hast du sicher ja nochmal überprüft?? Vielleicht findest du noch einen Hinweis, wenn du den Server mit höherem log-Level (z.B.: verb 6) startest...

Jörg
 
hallo ich hab da nen pdf für dich vielleicht hilfts
 

Anhänge

  • Fritz!VPN.pdf
    917.3 KB · Aufrufe: 90
Hallo!

Habe ein Problem mit dem kompilierten OpenVPN am Anfang dieses Threads.
FB 7170, Firmware 29.04.29, dies ist die Server Box, der Client ist ein einzelner Rechner (das ist aber nicht das Problem).

In meiner debug.cfg steht folgendes:
Code:
		cd /var/tmp
		cp $openvpn_path/mt/server.ovpn server.ovpn
		cp $openvpn_path/openvpn openvpn
		
		cat > /var/tmp/secret.key << 'ENDSECRETKEY'
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
..... (hier steht der Key, den ich hier natürlich nicht poste)
-----END OpenVPN Static key V1-----

ENDSECRETKEY
		
		chmod +x /var/tmp/openvpn
		chmod 0600 /var/tmp/server.ovpn
		chmod 0600 /var/tmp/secret.key
		
		/var/tmp/openvpn --config /var/tmp/server.ovpn &
$openvpn_path ist der Pfad auf meinem angeschlossenen USB-Stick, in dem die Daten liegen,d as klappt auch soweit mit dem kopieren.

server.ovpn
Code:
#
dev tun0
dev-node /dev/misc/net/tun
ifconfig 192.168.200.2 192.168.200.1
tun-mtu 1500
float
mssfix

#Pfad zum Key File
secret /var/tmp/secret.key

#Protokoll auf TCP und Port 1194
proto tcp-server
port 1194

#Protokollierung auf 4
verb 4

#daemon

#Routen setzen, bei route Subnetz des Clients eintragen
route 192.168.2.0 255.255.255.0

#Verbindung erhalten
ping 15
ping-restart 120

Beim Start des Servers (/var/tmp/openvpn --config /var/tmp/server.ovpn &) kommt folgende Ausgabe:
Code:
Sat Jun 16 18:38:17 2007 us=186510 Current Parameter Settings:
Sat Jun 16 18:38:17 2007 us=188126   config = '/var/tmp/server.ovpn'
Sat Jun 16 18:38:17 2007 us=189013   mode = 0
Sat Jun 16 18:38:17 2007 us=190096   persist_config = DISABLED
Sat Jun 16 18:38:17 2007 us=190995   persist_mode = 1
Sat Jun 16 18:38:17 2007 us=192321   show_ciphers = DISABLED
Sat Jun 16 18:38:17 2007 us=193723   show_digests = DISABLED
Sat Jun 16 18:38:17 2007 us=194723   show_engines = DISABLED
Sat Jun 16 18:38:17 2007 us=195607   genkey = DISABLED
Sat Jun 16 18:38:17 2007 us=196472   key_pass_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=197345   show_tls_ciphers = DISABLED
Sat Jun 16 18:38:17 2007 us=198226   proto = 1
Sat Jun 16 18:38:17 2007 us=199077   local = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=199935   remote_list = NULL
Sat Jun 16 18:38:17 2007 us=200807   remote_random = DISABLED
Sat Jun 16 18:38:17 2007 us=202317   local_port = 1194
Sat Jun 16 18:38:17 2007 us=203195   remote_port = 1194
Sat Jun 16 18:38:17 2007 us=204057   remote_float = ENABLED
Sat Jun 16 18:38:17 2007 us=204933   ipchange = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=205804   bind_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=206676   bind_local = ENABLED
Sat Jun 16 18:38:17 2007 us=207546   dev = 'tun0'
Sat Jun 16 18:38:17 2007 us=209899   dev_type = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=210830   dev_node = '/dev/misc/net/tun'
Sat Jun 16 18:38:17 2007 us=212295   lladdr = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=213178   topology = 1
Sat Jun 16 18:38:17 2007 us=214035   tun_ipv6 = DISABLED
Sat Jun 16 18:38:17 2007 us=214914   ifconfig_local = '192.168.200.2'
Sat Jun 16 18:38:17 2007 us=215800   ifconfig_remote_netmask = '192.168.200.1'
Sat Jun 16 18:38:17 2007 us=216685   ifconfig_noexec = DISABLED
Sat Jun 16 18:38:17 2007 us=218039   ifconfig_nowarn = DISABLED
Sat Jun 16 18:38:17 2007 us=218925   shaper = 0
Sat Jun 16 18:38:17 2007 us=219781   tun_mtu = 1500
Sat Jun 16 18:38:17 2007 us=220640   tun_mtu_defined = ENABLED
Sat Jun 16 18:38:17 2007 us=222956   link_mtu = 1500
Sat Jun 16 18:38:17 2007 us=223836   link_mtu_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=224709   tun_mtu_extra = 0
Sat Jun 16 18:38:17 2007 us=226086   tun_mtu_extra_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=226967   fragment = 0
Sat Jun 16 18:38:17 2007 us=227830   mtu_discover_type = -1
Sat Jun 16 18:38:17 2007 us=228695   mtu_test = 0
Sat Jun 16 18:38:17 2007 us=229547   mlock = DISABLED
Sat Jun 16 18:38:17 2007 us=230417   keepalive_ping = 0
Sat Jun 16 18:38:17 2007 us=232847   keepalive_timeout = 0
Sat Jun 16 18:38:17 2007 us=234259   inactivity_timeout = 0
Sat Jun 16 18:38:17 2007 us=235246   ping_send_timeout = 15
Sat Jun 16 18:38:17 2007 us=236131   ping_rec_timeout = 120
Sat Jun 16 18:38:17 2007 us=237004   ping_rec_timeout_action = 2
Sat Jun 16 18:38:17 2007 us=237876   ping_timer_remote = DISABLED
Sat Jun 16 18:38:17 2007 us=238759   remap_sigusr1 = 0
Sat Jun 16 18:38:17 2007 us=239627   explicit_exit_notification = 0
Sat Jun 16 18:38:17 2007 us=240493   persist_tun = DISABLED
Sat Jun 16 18:38:17 2007 us=242155   persist_local_ip = DISABLED
Sat Jun 16 18:38:17 2007 us=243037   persist_remote_ip = DISABLED
Sat Jun 16 18:38:17 2007 us=243908   persist_key = DISABLED
Sat Jun 16 18:38:17 2007 us=244783   mssfix = 1450
Sat Jun 16 18:38:17 2007 us=245633   passtos = DISABLED
Sat Jun 16 18:38:17 2007 us=246517   resolve_retry_seconds = 1000000000
Sat Jun 16 18:38:17 2007 us=247395   connect_retry_seconds = 5
Sat Jun 16 18:38:17 2007 us=248266   connect_timeout = 10
Sat Jun 16 18:38:17 2007 us=249617   connect_retry_max = 0
Sat Jun 16 18:38:17 2007 us=250494   username = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=252572   groupname = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=253452   chroot_dir = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=254739   cd_dir = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=256314   writepid = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=257709   up_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=258580   down_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=259439   down_pre = DISABLED
Sat Jun 16 18:38:17 2007 us=260297   up_restart = DISABLED
Sat Jun 16 18:38:17 2007 us=261620   up_delay = DISABLED
Sat Jun 16 18:38:17 2007 us=262509   daemon = DISABLED
Sat Jun 16 18:38:17 2007 us=263369   inetd = 0
Sat Jun 16 18:38:17 2007 us=264210   log = DISABLED
Sat Jun 16 18:38:17 2007 us=265512   suppress_timestamps = DISABLED
Sat Jun 16 18:38:17 2007 us=266406   nice = 0
Sat Jun 16 18:38:17 2007 us=267253   verbosity = 4
Sat Jun 16 18:38:17 2007 us=268103   mute = 0
Sat Jun 16 18:38:17 2007 us=268951   gremlin = 0
Sat Jun 16 18:38:17 2007 us=269798   status_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=270670   status_file_version = 1
Sat Jun 16 18:38:17 2007 us=271997   status_file_update_freq = 60
Sat Jun 16 18:38:17 2007 us=273331   occ = ENABLED
Sat Jun 16 18:38:17 2007 us=274216   rcvbuf = 65536
Sat Jun 16 18:38:17 2007 us=275068   sndbuf = 65536
Sat Jun 16 18:38:17 2007 us=275922   sockflags = 0
Sat Jun 16 18:38:17 2007 us=276772   socks_proxy_server = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=278068   socks_proxy_port = 0
Sat Jun 16 18:38:17 2007 us=279658   socks_proxy_retry = DISABLED
Sat Jun 16 18:38:17 2007 us=280531   fast_io = DISABLED
Sat Jun 16 18:38:17 2007 us=282209   lzo = 0
Sat Jun 16 18:38:17 2007 us=283059   route_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=283923   route_default_gateway = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=284800   route_default_metric = 0
Sat Jun 16 18:38:17 2007 us=285654   route_noexec = DISABLED
Sat Jun 16 18:38:17 2007 us=286520   route_delay = 0
Sat Jun 16 18:38:17 2007 us=287378   route_delay_window = 30
Sat Jun 16 18:38:17 2007 us=288234   route_delay_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=289631   route_nopull = DISABLED
Sat Jun 16 18:38:17 2007 us=290534   route 192.168.2.0/255.255.255.0/nil/nil
Sat Jun 16 18:38:17 2007 us=291876   management_addr = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=292765   management_port = 0
Sat Jun 16 18:38:17 2007 us=293631   management_user_pass = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=294518   management_log_history_cache = 250
Sat Jun 16 18:38:17 2007 us=295402   management_echo_buffer_size = 100
Sat Jun 16 18:38:17 2007 us=296282   management_query_passwords = DISABLED
Sat Jun 16 18:38:17 2007 us=297667   management_hold = DISABLED
Sat Jun 16 18:38:17 2007 us=298973   management_client = DISABLED
Sat Jun 16 18:38:17 2007 us=300589   management_write_peer_info_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=301947   shared_secret_file = '/var/tmp/secret.key'
Sat Jun 16 18:38:17 2007 us=302850   key_direction = 0
Sat Jun 16 18:38:17 2007 us=303710   ciphername_defined = ENABLED
Sat Jun 16 18:38:17 2007 us=304585   ciphername = 'BF-CBC'
Sat Jun 16 18:38:17 2007 us=305927   authname_defined = ENABLED
Sat Jun 16 18:38:17 2007 us=306811   authname = 'SHA1'
Sat Jun 16 18:38:17 2007 us=307687   keysize = 0
Sat Jun 16 18:38:17 2007 us=308547   engine = DISABLED
Sat Jun 16 18:38:17 2007 us=309418   replay = ENABLED
Sat Jun 16 18:38:17 2007 us=310290   mute_replay_warnings = DISABLED
Sat Jun 16 18:38:17 2007 us=311586   replay_window = 0
Sat Jun 16 18:38:17 2007 us=312483   replay_time = 0
Sat Jun 16 18:38:17 2007 us=313816   packet_id_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=314697   use_iv = ENABLED
Sat Jun 16 18:38:17 2007 us=315566   test_crypto = DISABLED
Sat Jun 16 18:38:17 2007 us=316445   tls_server = DISABLED
Sat Jun 16 18:38:17 2007 us=317318   tls_client = DISABLED
Sat Jun 16 18:38:17 2007 us=318188   key_method = 2
Sat Jun 16 18:38:17 2007 us=319038   ca_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=320335   ca_path = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=323133   dh_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=324018   cert_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=324895   priv_key_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=325771   pkcs12_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=326643   cipher_list = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=327515   tls_verify = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=328390   tls_remote = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=329782   crl_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=330664   ns_cert_type = 0
Sat Jun 16 18:38:17 2007 us=332049   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=332924   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=333795   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=334671   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=336252   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=337655   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=338535   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=339402   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=340269   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=341547   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=342470   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=343742   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=345932   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=346845   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=347719   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=348593   remote_cert_ku[i] = 0
Sat Jun 16 18:38:17 2007 us=349466   remote_cert_eku = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=350342   tls_timeout = 2
Sat Jun 16 18:38:17 2007 us=351594   renegotiate_bytes = 0
Sat Jun 16 18:38:17 2007 us=352499   renegotiate_packets = 0
Sat Jun 16 18:38:17 2007 us=353865   renegotiate_seconds = 3600
Sat Jun 16 18:38:17 2007 us=354748   handshake_window = 60
Sat Jun 16 18:38:17 2007 us=355613   transition_window = 3600
Sat Jun 16 18:38:17 2007 us=356475   single_session = DISABLED
Sat Jun 16 18:38:17 2007 us=357339   tls_exit = DISABLED
Sat Jun 16 18:38:17 2007 us=358207   tls_auth_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=359093   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=359983   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=361613   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=362534   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=363419   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=364724   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=366326   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=367225   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=368111   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=369455   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=370368   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=371644   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=372559   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=373450   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=374339   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=375231   pkcs11_protected_authentication = DISABLED
Sat Jun 16 18:38:17 2007 us=376119   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=377490   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=378381   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=379259   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=380136   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=381017   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=382809   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=384424   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=385833   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=386720   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=387598   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=388479   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=389356   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=390235   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=391607   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=392554   pkcs11_cert_private = DISABLED
Sat Jun 16 18:38:17 2007 us=393915   pkcs11_pin_cache_period = -1
Sat Jun 16 18:38:17 2007 us=394788   pkcs11_slot_type = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=395656   pkcs11_slot = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=396525   pkcs11_id_type = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=397397   pkcs11_id = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=398418   server_network = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=399335   server_netmask = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=400229   server_bridge_ip = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=402065   server_bridge_netmask = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=403407   server_bridge_pool_start = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=405073   server_bridge_pool_end = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=405965   ifconfig_pool_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=406884   ifconfig_pool_start = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=407795   ifconfig_pool_end = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=408702   ifconfig_pool_netmask = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=410095   ifconfig_pool_persist_filename = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=411506   ifconfig_pool_persist_refresh_freq = 600
Sat Jun 16 18:38:17 2007 us=412467   n_bcast_buf = 256
Sat Jun 16 18:38:17 2007 us=413331   tcp_queue_limit = 64
Sat Jun 16 18:38:17 2007 us=414199   real_hash_size = 256
Sat Jun 16 18:38:17 2007 us=415073   virtual_hash_size = 256
Sat Jun 16 18:38:17 2007 us=415945   client_connect_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=417280   learn_address_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=418185   client_disconnect_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=419066   client_config_dir = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=419946   ccd_exclusive = DISABLED
Sat Jun 16 18:38:17 2007 us=420816   tmp_dir = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=422753   push_ifconfig_defined = DISABLED
Sat Jun 16 18:38:17 2007 us=424096   push_ifconfig_local = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=426174   push_ifconfig_remote_netmask = 0.0.0.0
Sat Jun 16 18:38:17 2007 us=427060   enable_c2c = DISABLED
Sat Jun 16 18:38:17 2007 us=427933   duplicate_cn = DISABLED
Sat Jun 16 18:38:17 2007 us=428807   cf_max = 0
Sat Jun 16 18:38:17 2007 us=429664   cf_per = 0
Sat Jun 16 18:38:17 2007 us=430517   max_clients = 1024
Sat Jun 16 18:38:17 2007 us=431899   max_routes_per_client = 256
Sat Jun 16 18:38:17 2007 us=433252   client_cert_not_required = DISABLED
Sat Jun 16 18:38:17 2007 us=434160   username_as_common_name = DISABLED
Sat Jun 16 18:38:17 2007 us=435045   auth_user_pass_verify_script = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=435936   auth_user_pass_verify_script_via_file = DIS
ABLED
Sat Jun 16 18:38:17 2007 us=436828   port_share_host = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=437707   port_share_port = 0
Sat Jun 16 18:38:17 2007 us=439653   client = DISABLED
Sat Jun 16 18:38:17 2007 us=440520   pull = DISABLED
Sat Jun 16 18:38:17 2007 us=442196   auth_user_pass_file = '[UNDEF]'
Sat Jun 16 18:38:17 2007 us=443110 OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EP
OLL] built on Jan  5 2007
Sat Jun 16 18:38:17 2007 us=451957 Static Encrypt: Cipher 'BF-CBC' initialized w
ith 128 bit key
Sat Jun 16 18:38:17 2007 us=454239 Static Encrypt: Using 160 bit message hash 'S
HA1' for HMAC authentication
Sat Jun 16 18:38:17 2007 us=456602 Static Decrypt: Cipher 'BF-CBC' initialized w
ith 128 bit key
Sat Jun 16 18:38:17 2007 us=458085 Static Decrypt: Using 160 bit message hash 'S
HA1' for HMAC authentication
Sat Jun 16 18:38:17 2007 us=463568 Note: Cannot open TUN/TAP dev /dev/misc/net/t
un: No such file or directory (errno=2)
Sat Jun 16 18:38:17 2007 us=464408 Note: Attempting fallback to kernel 2.2 TUN/T
AP interface
Sat Jun 16 18:38:17 2007 us=465993 Cannot open TUN/TAP dev /dev/misc/net/tun: No
 such file or directory (errno=2)
Sat Jun 16 18:38:17 2007 us=466787 Exiting

Was ist da falsch? Vorher hat es imemr so funktioniert, bis ich eben die neu kompilierte OpenVPN-Version draufgespielt habe. Muss ich in der Konfiguration dazu etwas ändern?

Danke für Eure Hilfe! :)
 
chimealheltei schrieb:
Cannot open TUN/TAP dev /dev/misc/net/tun: No such file or directory (errno=2)
Das ist dein Problem: Das Tunnel-Device ist nicht da.

Anlegen im tmp, dev-node ändern und vermutlich gehts (zur Not mal die Suchfunktion mit der Fehlermeldung, oder direkt z.B. in Post #111). Nur merkwürdig, dass es mit der Config vorher funktioniert hat, obwohl das Device nicht da ist ?!?

Jörg
 
Zuletzt bearbeitet:
In der Tat, Dir fehlt das Tunnel-Device.
So erzeugst Du es Dir:
Code:
# tun-device erzeugen
mknod /var/tmp/tun c 10 200
Dann noch den dev-node ändern:
Alt:
Code:
dev-node /dev/misc/net/tun
Neu:
Code:
dev-node /var/tmp/tun
Das sollte dann laufen.
 
Hallo zusammen,

wie bei so vielen von euch geht auch bei mir nach dem Firmware Wechsel mein openVPN nicht mehr.

Mittlerweile habe ich dank eurer Hilfe den Server wieder zum starten bekommen. Will ich mich nun aber von meinem W2K Client aus verbinden, bekomme ich ein Problem mit dem TLS.
Siehe Clientmeldung:
Code:
TLS Error: TLS key negotiation failed ....
TLS Error: TLS handshake failed

Siehe Logfile:
Code:
Fri Jun 22 22:28:37 2007 OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan  5 2007
Fri Jun 22 22:28:37 2007 WARNING: --keepalive option is missing from server config
Fri Jun 22 22:28:37 2007 WARNING: file 'openvpn/fritzbox.key' is group or
Fri Jun 22 22:28:37 2007 TUN/TAP device tun0 opened
Fri Jun 22 22:28:37 2007 /sbin/ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2 mtu 1500
Fri Jun 22 22:28:37 2007 Listening for incoming TCP connection on [undef]:1194
Fri Jun 22 22:28:37 2007 TCPv4_SERVER link local (bound): [undef]:1194
Fri Jun 22 22:28:37 2007 TCPv4_SERVER link remote: [undef]
Fri Jun 22 22:28:37 2007 Initialization Sequence Completed
Fri Jun 22 22:28:45 2007 Re-using SSL/TLS context
Fri Jun 22 22:28:45 2007 TCP connection established with 84.177.166.160:61027
Fri Jun 22 22:28:45 2007 TCPv4_SERVER link local: [undef]
Fri Jun 22 22:28:45 2007 TCPv4_SERVER link remote: 84.177.166.160:61027
Fri Jun 22 22:28:45 2007 84.177.166.160:61027 Re-using SSL/TLS context
Fri Jun 22 22:28:45 2007 84.177.166.160:61027 TCP: accept(3) failed: Resource temporarily unavailable (errno=11)
Fri Jun 22 22:28:45 2007 Re-using SSL/TLS context
Fri Jun 22 22:28:45 2007 TCP: accept(3) failed: Resource temporarily unavailable (errno=11)
Fri Jun 22 22:28:45 2007 Re-using SSL/TLS context
Fri Jun 22 22:28:45 2007 TCP: accept(3) failed: Resource temporarily unavailable (errno=11)
Fri Jun 22 22:28:45 2007 Re-using SSL/TLS context

Hat einer eine Idee woran sowas liegt?

Meine Configs, mit denen es früher ging:
Server:
Code:
port 1194
#proto udp
proto tcp
dev tun0
dev-node /var/tmp/tun
#dev tap
# Server-Einstellungen
mode server
tls-server
server 10.0.0.0 255.255.255.0
client-to-client
# Dies ist der IP-Bereich von eurem FritzBox-LAN
push "route 10.11.2.0 255.255.255.0"
# Authentifizierung und Verschluesselung
ca ca.crt
cert client01.crt
key client01.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC
# Sonstiges
ping 10
push "ping 10"
ping-restart 60
push "ping-restart 60"
Client:
Code:
# Grundsätzliches (Was soll der CLIENT nutzen)
port 1194
proto tcp-client
dev tap
# Client-Einstellungen
tls-client
ns-cert-type server
remote alias.dyndns.org 1194
# Authentifizierung und Verschlüsselung
ca ca.crt
cert client01.crt
key client01.key
auth SHA1
cipher AES-256-CBC
# Sonstiges
pull

Die forwardrules "udp 0.0.0.0:1194 0.0.0.0:1194", habe ich auch drin.
 
Zuletzt bearbeitet:
Hallo,

soweit ich das weiss, haben andere das geleiche Problem beschrieben, aber bislang wohl noch keine Lösung (schau mal hier).
Was mir allerdings auffiel: Du hast zumindest angegeben, das Portforwadrding auf udp Port 1194, die Konfig ist aber für tcp (wie bei den anderen auch). Hast du es mal mit udp versucht?

Jörg
 
Habe beides in der Forwardrules drin, TCP und UDP!

Wie gesagt, früher ging es auch. Wobei ich früher es immer nur vom Büro aus gemacht habe und jetzt bei den Tests immer von zu Hause, also ein VPN innerhalb meines eigenen Netzes. Könnte es vielleicht daran liegen?
 
Ja, es scheint tatsächlich ja ein neues Problem mit der .33-er Firmware zu sein. Aber wenn ich es richtig gesehen habe, immer nur bei einer tcp-Verbindung. Versuche es doch mal mit einer udp-Verbindung.
Und wenn der Port stimmt sollte es egal sein, ob es "von innen" oder extern versucht wird, eher im Gegenteil: Falls etwas mit den Forwardrules nicht stimmt, würde das intern garnicht auffallen...
Außerdem sind deine Konfigs nicht übereinstimmend:
Der Server steht auf tun, der Client auf tap. Zudem scheint der Server (zumindest Namenstechnisch) den gleichen Key / das gleiche Zertifikat wie der Client zu nutzen?? Der müsste doch Server-Key/Zertifikat benutzen, oder?
Ansonsten versuch es doch mal mit verb 6, vielleicht sieht man dann noch etwas mehr.

Jörg
 
Es scheint wirklich am TCP zu liegen!!!!

Habe den Client und Server mal auf UDP umgestellt und siehe da, es wird eine Verbindung aufgebaut. Leider habe ich keine Zeit es jetzt ausgiebig zu testen ob auch alles geht :-(

Leider funktioniert es per UDP nicht über den Proxy in meiner Firma :-(
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.