[Gelöst] Port-Forward auf openVPN-Server

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
sweetie-pie

sweetie-pie

Neuer User
Mitglied seit
5 Feb 2005
Beiträge
118
Punkte für Reaktionen
0
Punkte
16
Hallo,

ich hab schon fleißig das Forum und das Wiki bemüht, aber leider keine Abhilfe gefunden:

Ich hab Dropbear und openVPN auf der Box (7390) installiert.
Code: 
Firmwareversion 84.06.23 
Freetz-Version freetz-devel-13181

Um das Portforwarding einzurichten, habe ich das Paket "AVM-Forwarding" genutzt.
Das hat aber irgendwie nicht richtig funktioniert,
deswegen habe ich es dann "oldschool" gemacht.

Nachdem ich die Fernwartung per AVM-GUI aktiviert habe, hatte ich die internet_forward-Rules in der ar7.cfg.
Diese habe ich dann per Hand editiert und natürlich neu gestartet und so weiter....

Ergebnis:
Der TCP-Forward auf Dropbear funktioniert.
Der UDP-Forward auf openVPN funktioniert nicht.
Code: 
cat /var/flash/ar7.cfg | grep -A 2 internet_f
        internet_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", 
                                "tcp 0.0.0.0:22 0.0.0.0:22 0 # ssh-fritzbox";

Auch bin ich dabei auf das Ticket hier gestossen, komme aber nicht wirklich weiter.

Kann es sein, dass über die Firmware einfach kein UDP-Forwad unterstützt wird?
Ich könnte natürlich auf TCP ausweichen, aber mein fertig konfigurierter CLient sitzt einigermaßen weit weg. :(
 
Zuletzt bearbeitet:
Könntest Du mal den kompletten Block aus der ar7.cfg, in der die konkrete(n) Regel(n) für OpenVPN stehen, hier einstellen ?
Ich vermute, daß die Regel(n) an der falschen Stelle stehen.
Bei einer 7270 stehen diese bspw. im Bereich "dslifaces".
 
Es steht an der Stelle, wo die Firmware es angelegt. Deshalb hatte ich zunächst einmal die Fernwartung (https auf 443 von extern) in der Gui aktiviert.
Habe es dennoch geprüft:
Code: 
ar7cfg {                                                                                                          
        mode = dsldmode_router;                                                                                   
        active_provider = .....
-------8<--------8<--------8<--------8<--------
        vccs {                                                                                                    
                VPI = 1;                                                                                          
                VCI = 32;                                                                                         
                traffic_class = atm_traffic_class_UBR;                                                            
                pcr = 0;                                                                                          
                scr = 0;                                                                                          
                priority = 0;                                                                                     
                dsl_encap = dslencap_pppoe;                                                                       
                ipbridgeing = no;                                                                                 
                ipbridgeing_igmp = no;                                                                            
                pppoeforwarding = no;                                                                             
                connections = "internet", "voip";                                                                 
        }                                                                                                         
        mcupstream = "internet";                                                                                  
        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",                                                      
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",                                                      
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";                                                   
        tr069_forwardrules = "tcp 0.0.0.0:8089 0.0.0.0:8089";                                                     
        voip_ip6_forwardrules = "udp 5060,7078-7109", "tcp 5060";                                                 
        tr069_ip6_forwardrules = "tcp 8089";                                                                      
        internet_in_nat_rules_enabled = yes;                                                                      
        internet_out_nat_rules_enabled = yes;                                                                     
        internet_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",                                      
                                "tcp 0.0.0.0:22 0.0.0.0:22 0 # ssh-fritzbox";                                   
        dslifaces {                                                                                               
                enabled = yes;                                                                                    
-------8<--------8<--------8<--------8<--------

Ich hatte vorher eine 7270v3 mit 6.05FW, da war das kein Problem...
 
Wird OpenVPN als Tunnel oder Brücke betrieben ?
 
/dev/tun - Device ist da

Code: 
crw-rw-rw-    1 root     root       10, 200 Jan  1  1970 /dev/tun

Hier nochmal die Konfig...
Code: 
cat /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Mon Jun 29 00:33:51 CEST 2015
proto udp
dev tun
dev-node /dev/tun
secret /tmp/flash/openvpn/static.key
port 1194
ifconfig 192.168.200.1 192.168.200.2
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Die Einstellungen sind identisch mit der Vorgängerbox (7270v3) und lief immer stabil.
Ist eine Netz-zu-Netz Kopplung.
 
Was steht denn in den Logs während des Verbindungsaufbaus, Server und Client ?

Edit:

Das hier
sweetie-pie schrieb:
Code: 
ifconfig 192.168.200.1 192.168.200.2
Zum Vergrößern anklicken....
sieht für mich ein wenig merkwürdig aus, fehlt da eine Netzwerk-Maske ?
Desweiteren: Wie ist denn die Config der 7270 in die neue Box gekommen ?
 
Zuletzt bearbeitet:
Der Client ist leider zu weit weg und ich hab auch keinen der in der Lage ist dort mal zu gucken.

Der Server sieht unauffällig aus:
Code: 
cat /var/tmp/debug_openvpn.out 
Wed Jul  1 15:31:48 2015 OpenVPN 2.3.7 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 24 2015
Wed Jul  1 15:31:48 2015 library versions: OpenSSL 0.9.8zg 11 Jun 2015, LZO 2.09
Wed Jul  1 15:31:48 2015 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jul  1 15:31:48 2015 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul  1 15:31:48 2015 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jul  1 15:31:48 2015 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul  1 15:31:48 2015 Socket Buffers: R=[204800->131072] S=[204800->131072]
Wed Jul  1 15:31:48 2015 TUN/TAP device tun0 opened
Wed Jul  1 15:31:48 2015 TUN/TAP TX queue length set to 100
Wed Jul  1 15:31:48 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jul  1 15:31:48 2015 /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
Wed Jul  1 15:31:48 2015 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Wed Jul  1 15:31:48 2015 GID set to openvpn
Wed Jul  1 15:31:48 2015 UID set to openvpn
Wed Jul  1 15:31:48 2015 UDPv4 link local (bound): [undef]
Wed Jul  1 15:31:48 2015 UDPv4 link remote: [undef]

Tausche ich testweise die 7390 gegen die alte 7270 aus, steht die Verbindung stabil.

Es kann nur die Freigabe sein, ein nmap Scan sagt ja schon, dass der Port dicht ist.
 
Du kannst das problemlos selbst überprüfen, was die Firmware da "versteht" ... mit

Code: 
msgsend dsld dumpfwrules

wird eine Datei /var/tmp/fwrules.txt mit den aktiven Weiterleitungen erstellt (auch auf einer 7390 mit 06.23 getestet).

So kannst Du "im laufenden Betrieb" ermitteln, ob die Firmware Deine Regeln versteht und der Traffic nur nicht durchkommt oder ob die gleich komplett ignoriert werden (was wohl nur bei Syntaxfehlern passiert - ich würde die Syntax für einzelne Geräte jedenfalls nicht 1:1 auf die Regeln für die Box übertragen (es geht um die "Kommentare"), aber das muß jeder selbst wissen).

Eine Alternative (wieder bei 84.06.23) wäre die Ausgabe von
Code: 
cat /proc/kdsld/dsliface/internet/ipmasq/forwards
die aber bei vorhergehenden Versionen abweichen kann, ich habe keine Ahnung, seit wann der kdsldmod.ko das auch im proc-FS unterstützt.

Zwar erklärt das dann auch noch nicht, warum die Dropbear-Freigabe gehen sollte, aber vielleicht überprüfst Du das ja auch noch einmal ... das o.a. Kommando sollte dabei helfen können.

Ich kann jedenfalls auf einer 7490 mit 06.24 problemlos eine weitere Regel unter "internet_forwardrules" hinzufügen (udp 0.0.0.0:85 0.0.0.0:85 0), wenn ich die (für mich überflüssigen) Kommentare weglasse.

Ob das vielleicht doch ein Problem der Anzahl der zusätzlichen Regeln ist, kannst Du ggf. durch Vertauschung der Reihenfolge bei Dir ermitteln ... wobei - wenn das oben stehende stimmt - ja bei Dir die (funktionierende) Dropbear-Weiterleitung auch erst die dritte wäre, solange der dsld da nichts intern umsortiert.
 
Danke, das bringt mich schon mal weiter...

Code: 
root@fritz:/var/mod/root# msgsend dsld dumpfwrules
root@fritz:/var/mod/root# cat  /var/tmp/fwrules.txt
normal:internet:udp 0.0.0.0:1194 0.0.0.0:1194 0 # openVPN
normal:internet:tcp 0.0.0.0:22 0.0.0.0:22 0 # ssh-fritzbox
voip:internet:udp 0.0.0.0:5060 0.0.0.0:5060
voip:internet:tcp 0.0.0.0:5060 0.0.0.0:5060
voip:internet:udp 0.0.0.0:7078+32 0.0.0.0:7078
vpn:internet:udp 0.0.0.0:500 0.0.0.0:500
vpn:internet:udp 0.0.0.0:4500 0.0.0.0:4500
root@fritz:/var/mod/root# cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
tcp 79.244.101.xx:5060 192.168.2.110:5060 0 (voip)
tcp 79.244.101.xx:22 192.168.2.110:22 0  (normal)
udp 79.244.101.xx:5060 192.168.2.110:5060 0 (voip)
udp 79.244.101.xx:7078+32 192.168.2.110:7078 0 (voip)
udp 79.244.101.xx:500 192.168.2.110:500 0  (vpn)
udp 79.244.101.xx:4500 192.168.2.110:4500 0  (vpn)
udp 79.244.101.xx:1194 192.168.2.110:1194 0  (normal)
---------------------------

Demnach müsste es eigentlich gehen. Tut es aber irgendwie noch nicht.

Ich habe jetzt mal mit netcat ein paar UDP-Pakete an das interne (LAN) und dann an das externe (DSL) Netzwerkinterface gesendet.
Das taucht jetzt doch im debug-Log auf, muss ich wohl beim ganzen Testen übersehen haben. Also am Portforward scheint es wohl nicht zu liegen.
Code: 
tail /var/tmp/debug_openvpn.out 
Wed Jul  1 19:56:51 2015 Re-using pre-shared static key
Wed Jul  1 19:56:51 2015 Socket Buffers: R=[204800->131072] S=[204800->131072]
Wed Jul  1 19:56:51 2015 Preserving previous TUN/TAP instance: tun0
Wed Jul  1 19:56:51 2015 UDPv4 link local (bound): [undef]
Wed Jul  1 19:56:51 2015 UDPv4 link remote: [undef]
Wed Jul  1 19:58:03 2015 Authenticate/Decrypt packet error: missing authentication info
Wed Jul  1 19:58:03 2015 Authenticate/Decrypt packet error: missing authentication info
Wed Jul  1 19:58:03 2015 Authenticate/Decrypt packet error: missing authentication info
Wed Jul  1 19:58:03 2015 Authenticate/Decrypt packet error: missing authentication info
Wed Jul  1 19:58:03 2015 Authenticate/Decrypt packet error: missing authentication info

Jetzt hab ich das Debug-Level nochmal hochgeschraubt:
Code: 
9d5 706bae4[more...]
Wed Jul  1 20:08:10 2015 us=56711  event_wait returned 0
Wed Jul  1 20:08:11 2015 us=245418  event_wait returned 0
Wed Jul  1 20:08:12 2015 us=434109  event_wait returned 0
Wed Jul  1 20:08:13 2015 us=622608  event_wait returned 0
Wed Jul  1 20:08:14 2015 us=811022  event_wait returned 0
Wed Jul  1 20:08:15 2015 us=998953  event_wait returned 0
Wed Jul  1 20:08:17 2015 us=187062  event_wait returned 0
Wed Jul  1 20:08:18 2015 us=374826  event_wait returned 0
Wed Jul  1 20:08:18 2015 us=586404  event_wait returned 1
Wed Jul  1 20:08:18 2015 us=586937 UDPv4 read returned 60
Wed Jul  1 20:08:18 2015 us=587507 UDPv4 READ [60] from [AF_INET]84.137.28.XX:3078:  DATA b79041e1 33bb1c3b 3e6cb997 3a4f432e 6a8ac6a6 4c5441af 19f4a34c dd18217[more...]
Wed Jul  1 20:08:19 2015 us=609026  event_wait returned 0
Wed Jul  1 20:08:20 2015 us=630300  event_wait returned 0
Wed Jul  1 20:08:21 2015 us=651826  event_wait returned 0
Wed Jul  1 20:08:22 2015 us=673078  event_wait returned 0
Wed Jul  1 20:08:23 2015 us=694294  event_wait returned 0
Wed Jul  1 20:08:24 2015 us=715091  event_wait returned 0
Wed Jul  1 20:08:25 2015 us=735818  event_wait returned 0
Wed Jul  1 20:08:26 2015 us=757158  event_wait returned 0
Wed Jul  1 20:08:27 2015 us=778407  event_wait returned 0
Wed Jul  1 20:08:28 2015 us=216096  event_wait returned 1
Wed Jul  1 20:08:28 2015 us=216402 UDPv4 read returned 60
Wed Jul  1 20:08:28 2015 us=216957 UDPv4 READ [60] from [AF_INET]84.137.28.XX:3078:  DATA 73770abd 0cdbf9f3 c84da5fa 795db041 517d8005 96557a39 e81c7651 93664e5[more...]
Es kommen also Daten von meinem Peer an, nur kommt keine Verbindung zu stande.
Da muss ich dann also nochmal in eine andere Richtung forschen/googeln...

Das Log hilft mir zwar noch nicht, aber bin ich schon etwas weiter... Danke.
 
So, ich habe dank Teamviewer auf der anderen Seite von einer Windows-Dose ssh Zugriff.
Hier das Log von der Gegenseite:
Code: 
Wed Jul  1 20:26:56 2015 us=569093 UDPv4 link local: [undef]
Wed Jul  1 20:26:56 2015 us=570994 UDPv4 link remote: 79.244.101.34:1194
Wed Jul  1 20:26:56 2015 us=583724  event_wait returned 1
Wed Jul  1 20:26:56 2015 us=692887 UDPv4 WRITE [60] to 79.244.101.34:1194:  DATA e0db05a8 18c0288e 70dbf8bb e613673f e4064fc2 8f937efb c9825a20 9e6f5ad[more...]
Wed Jul  1 20:26:56 2015 us=696066 UDPv4 write returned 60
Wed Jul  1 20:26:57 2015 us=750178  event_wait returned 0
Wed Jul  1 20:26:58 2015 us=810125  event_wait returned 0
Wed Jul  1 20:26:59 2015 us=870118  event_wait returned 0
Wed Jul  1 20:27:00 2015 us=930121  event_wait returned 0
Wed Jul  1 20:27:01 2015 us=991005  event_wait returned 0
Wed Jul  1 20:27:03 2015 us=50179  event_wait returned 0
Wed Jul  1 20:27:04 2015 us=110124  event_wait returned 0
Wed Jul  1 20:27:05 2015 us=170125  event_wait returned 0
Wed Jul  1 20:27:06 2015 us=230129  event_wait returned 0
Wed Jul  1 20:27:06 2015 us=231720  event_wait returned 1
Wed Jul  1 20:27:06 2015 us=234096 UDPv4 WRITE [60] to 79.244.101.xx:1194:  DATA cd344b27 2d06eeaf 777c5016 9f4a7e26 735166ab 0f9d47c6 465d7fb3 41777a1[more...]
Wed Jul  1 20:27:06 2015 us=235295 UDPv4 write returned 60
Wed Jul  1 20:27:07 2015 us=500123  event_wait returned 0
 
Wie so häufig lag der Fehler im Layer 8.

Code: 
Wed Jul  1 20:38:06 2015 UDPv4 link local (bound): [undef]
Wed Jul  1 20:38:06 2015 UDPv4 link remote: [undef]
Wed Jul  1 20:38:10 2015 Peer Connection Initiated with [AF_INET]84.137.28.xx:3079
Wed Jul  1 20:38:11 2015 Initialization Sequence Completed

Danke, ich habe es... auf dem Client war keine Komprimierung aktiv.
Das habe ich beim Übertragen nicht gesehen. Ich hatte dort noch eine weitere OpenVPN-Instanz mit Komprimierung, deswegen die Verwechslung.
Manchmal ist die Lösung so einfach und doch so fern. Man braucht nur mal einen Denkanstoss.... wobei ich das Verhalten von openVPN bei Debug Level 15 da auch auch schon grandios finde.... ;)

DANKE ZUSAMMEN.
 
Bitte auf "gelöst" setzen, wenn es erledigt ist oder auf "erledigt", wenn es gelöst ist ... :gruebel:

Danke.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 538 (Mitglieder: 40, Gäste: 498)

Neueste Beiträge

Statistik des Forums

Themen
244,857
Beiträge
2,219,600
Mitglieder
371,570
Neuestes Mitglied
mcom_jens
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück