OpenVPN-Paket

Diese Box hat sowohl die IP 134.34.31.1 (LAN) als auch 134.34.32.1 (guest). Klar, dass die dann antwortet.
Gleiche Netze lokal und auf der Gegenseite sind eher suboptimal ;-)
Wähle auf beiden Seiten verschiedene Netze, dann sollte das Phänomen weg sein, denke ich.
 
Danke für den Hinweis. Das Problem mit den IP-Adressen habe ich dadurch gefixt. Es bleibt jedoch das Problem mit dem SIP-Server. Der Sip-Server ist mit Firmware: 131.06.03 rev27365 ausgestattet. Von einer Ftitzbox mit der Firmware: 109.06.03 rev27365 funktioniert leider die Anmeldung nicht. Von einer Fritzbox 7170 funktioniert VoIP über die internen OpenVPN-IP-Adressen dagegen reibungslos. Habe auch die Einstellung von hier http://www.cswpro.de/Howto/FritzBox_VPN_VoIP.aspx ausprobiert. Hat überhaupt keine Auswirkung auf beiden Verbindungen gemacht. Gibt es dafür irgend-welche Tips?
 
Zunächst vorweg: Bitte keine crosspostings, dass verstößt gegen die Regeln hier im Forum, denn ein Beitrag genügt.

Im Log sieht man, dass der Server der Box keine IP schickt ("Sun Mar 16 09:25:27 2014 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10'"), dem PC schon ("Sun Mar 16 13:11:17 2014 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.211.1.5 10.211.1.6,dhcp-option DNS 10.211.254.254,dhcp-option DNS 8.8.8.8,route-gateway 10.211.1.6,redirect-gateway def1'").

Du könntest ein zusätzliches "pull" id er Config versuchen. Ich weiß aber nicht, ob das OpenVPN 2.2.4 auf der FB überhaupt die "in file" Daten (wie "<ca>....</ca>") kennt. Von daher würde ich es mit einem neueren Openvpn 2.3 versuchen, zum Beispiel dem Binary oben aus diesem Thread, in Beitrag #5.

Denke dran, dass nur die Fritzbox Client des Netzes wird, und kein Gerät im LAN das VPN nutzen kann, wenn dein LAN im OpenVPN-Server nicht zu deinem Client geroutet wird.

EDIT: Sehe, du hast ja keine 7390, sondern eine 7141, die braucht mipsel Binaries:
 

Anhänge

  • openvpn_2.3.2-mipsel-openssl-static.gz
    481.6 KB · Aufrufe: 12
  • openvpn_2.3.2-mipsel-polarssl-static.gz
    289 KB · Aufrufe: 7
Zuletzt bearbeitet:
Portfreigabe OpenVPN funktioniert nicht

Hallo!

Ich habe folgende Netzwerk-Architektur aufgebaut:
Code:
WAN <---> Kabel-Modem <---> FB7570 <---> FB7390
                                   <---> Server

Die FB7570 ist als Router konfiguriert und stellt keine Dienste bereit (mit Ausnahme von dropbear/SSH).
Direkt angeschlossen an die FB7570 ist ein Server und die FB7390.
Auf dem Server läuft ein Dienst mit dem Port 10000.
Auf der FB7390 läuft u.a. der OpenVPN-Dienst mit dem Port 1194 (siehe Screenshot FB7390_OpenVPN).

In der FB7570 sind im AVM-WebUI unter Internet -> Freigaben -> Portfreigaben die o.g. Ports eingetragen (siehe Screenshot FB7570_Portfreigaben.png).
Des Weiteren sind im Freetz-WebUI unter AVM-Firewall -> Port Forwarding dieselben Port Forwarding-Regeln definiert (siehe Screenshot FB7570_Port_Forward.png).

In der FB7390 sind im Freetz-WebUI unter AVM-Firewall -> Port Forwarding die Port Forwarding-Regeln für Port 1194 definiert (siehe Screenshot FB7390_Port_Forward.png).

Somit müsste also sichergestellt sein, dass für den Port 1194 eine Port Forwarding-Regel von FB7570 nach FB7390 eingerichtet ist und damit der Port 1194 nach "aussen" offen ist.

Dies ist allerdings nicht der Fall, d.h. der Port 1194 ist geschlossen (siehe Screenshot Port-Check_1194.png).
Hingegen funktioniert der Port-Check auf den anderen geöffneten Port 10000 fehlerfrei.
Die Überprüfung der offenen Ports erfolgte mittels http://canyouseeme.org/.

Und somit stellt sich die Frage nach der Ursache.
Hängt es an der Port Forwarding?
Da ich im lokalen Netzwerk hinter der FB7390 eine VPN-Verbindung zum OpenVPN-Server aufbauen kann, ist diese Vermutung naheliegend.

Interessant ist in diesem Zusammenhang:
Wenn ich den OpenVPN-Dienst auf der FB7570 laufen lasse und eine entsprechende Port Forwarding-Regel auf der FB7570 einrichte, dann ist der Port 1194 nach "aussen" immer noch geschlossen.

Wie kann die mögliche Ursache analysiert genauer werden?

THX
 

Anhänge

  • FB7390_OpenVPN.png
    FB7390_OpenVPN.png
    49.2 KB · Aufrufe: 22
  • FB7390_Port_Forward.png
    FB7390_Port_Forward.png
    65.2 KB · Aufrufe: 24
  • FB7570_Port_Forward.png
    FB7570_Port_Forward.png
    75.3 KB · Aufrufe: 18
  • FB7570_Portfreigaben.png
    FB7570_Portfreigaben.png
    41.4 KB · Aufrufe: 15
  • Port-Check_1194.png
    Port-Check_1194.png
    12.8 KB · Aufrufe: 15
Zuletzt bearbeitet:
Dass du auf Adressen in verschiedenen IP-Netzen freigegeben hast ist Absicht? Wenn, wie funktioniert das? Wenn nicht, korrigiere es ;-)
 
canyouseeme prüft nur TCP Ports, kein UDP.
Hast Du andere Hinweise darauf, dass es nicht funktioniert?

RalfFriedl hat natürlich (wie immer) Recht:
Der Openportcheck funktioniert nicht mit UDP.
Ich konnte heute (glücklicherweise) erfolgreich von aussen den OpenVPN-Zugang zu meinem Netzwerk testen; es funktioniert alles so wie gewünscht.

Jetzt muss ich nur noch die "Konvertierung" von TAP zu TUN hinkriegen...

Dass du auf Adressen in verschiedenen IP-Netzen freigegeben hast ist Absicht? Wenn, wie funktioniert das? Wenn nicht, korrigiere es ;-)
Ja, das Zuweisen unterschiedlicher Netzwerke an den verschiedenen LAN-Ports (1-4) der FB7570 ist beabsichtigt und mit dem Paket cpmaccfg realisiert.
 
Hallo!

Jetzt ist doch der unerwartete Fall eingetreten, dass OpenVPN nicht mehr funktioniert.
Das heißt, bis gestern konnte man mit einem Client von außerhalb des Netzwerks, in dem der OpenVPN-Server steht, eine VPN-Verbindung aufbauen.

Ich habe mit 2 unterschiedlichen Clients (Android-Smartphone, Debian-PC), die vorher ohne Probleme funktionierten, dies überprüft und den Fehler festgestellt.

Auf dem Debian-PC habe ich hier den relevanten Auszug aus /var/log/syslog (das Log auf dem Android-Smartphone sieht praktisch gleich aus):
Code:
Mar 28 18:27:57 pc1-asus NetworkManager[3850]: <info> Starting VPN service 'openvpn'...
Mar 28 18:27:57 pc1 NetworkManager[3850]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 5072
Mar 28 18:27:57 pc1 NetworkManager[3850]: <info> VPN service 'openvpn' appeared; activating connections
Mar 28 18:27:57 pc1 NetworkManager[3850]: <info> VPN plugin state changed: starting (3)
Mar 28 18:27:57 pc1 NetworkManager[3850]: <info> VPN connection 'VPN-FB7390' (Connect) reply received.
Mar 28 18:27:57 pc1 nm-openvpn[5075]: OpenVPN 2.3.2 i486-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
Mar 28 18:27:57 pc1 nm-openvpn[5075]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mar 28 18:27:57 pc1 nm-openvpn[5075]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 28 18:27:57 pc1 nm-openvpn[5075]: Control Channel Authentication: using '/etc/openvpn/config/static.key' as a OpenVPN static key file
Mar 28 18:27:57 pc1 nm-openvpn[5075]: UDPv4 link local: [undef]
Mar 28 18:27:57 pc1 nm-openvpn[5075]: UDPv4 link remote: [AF_INET]94.124.xxx.xxx:1194

Ab diesem "UDPv4 link remote" passiert nichts mehr.

Frage:
Wie kann ich die Ursache des Problems genauer analysieren?
Welche Netzwerk-Tools sollte ich hierfür einsetzen? Wireshark?

Der Portscanner auf dem Server zeigt den geöffneten Port richtig an:
Code:
root@FB7390:/var/mod/root# netstat -tulpen | grep vpn
udp        0      0 0.0.0.0:1194            0.0.0.0:*                           5937/openvpn
 
Zuletzt bearbeitet:
Interessant wäre natürlich vor allem das Log des Servers...
 
Ich habe das Log des Servers zunächst nicht gepostet, weil darin nichts drin steht, was auf eine Client-Verbindung hinweisen würde.

Jetzt aber das Log:
Code:
root@FB7390:/var/mod/root# cat /var/media/ftp/system/log/openvpn.log 
Fri Mar 28 18:27:29 2014 OpenVPN 2.3.1 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Nov 17 2013
Fri Mar 28 18:27:29 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Mar 28 18:27:30 2014 Diffie-Hellman initialized with 2048 bit key
Fri Mar 28 18:27:30 2014 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Fri Mar 28 18:27:30 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 28 18:27:30 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 28 18:27:30 2014 Socket Buffers: R=[202752->131072] S=[202752->131072]
Fri Mar 28 18:27:30 2014 TUN/TAP device tap0 opened
Fri Mar 28 18:27:30 2014 TUN/TAP TX queue length set to 100
Fri Mar 28 18:27:30 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Mar 28 18:27:30 2014 /sbin/ip link set dev tap0 up mtu 1500
Fri Mar 28 18:27:30 2014 /sbin/ip addr add dev tap0 192.168.178.1/24 broadcast 192.168.178.255
Fri Mar 28 18:27:30 2014 chroot to '/tmp/openvpn' and cd to '/' succeeded
Fri Mar 28 18:27:30 2014 GID set to openvpn
Fri Mar 28 18:27:30 2014 UID set to openvpn
Fri Mar 28 18:27:30 2014 UDPv4 link local (bound): [undef]
Fri Mar 28 18:27:30 2014 UDPv4 link remote: [undef]
Fri Mar 28 18:27:30 2014 MULTI: multi_init called, r=256 v=256
Fri Mar 28 18:27:30 2014 IFCONFIG POOL: base=192.168.178.201 size=10, ipv6=0
Fri Mar 28 18:27:30 2014 Initialization Sequence Completed

Ich kann mich per ssh zum remote Debian-PC verbinden und auch dort Analysen durchführen.
Es wäre aus meiner Sicht sinnvoll, wenn man ermitteln könnte, "wie weit" der Client beim Aufbau der VPN-Verbindung kommt.
 
Zuletzt bearbeitet:
Nimm tcpdump auf dem Server, das sollte anzeigen, ob überhaupt etwas ankommt.

Ich musste ein neues Image mit dem Paket "tcpdump" erstellen. Dies ist noch nicht installiert und ich habe noch keine Ergebnisse.

Frage:
Was kann ich auf dem Client tracen?
Und wie?

Mich würde auch interessieren, was der Client sendet bzw. (vom Server) empfängt.

THX
 
Auf dem Client (Debian PC) kannst du auch mit tcpdump bzw. wireshark (GUI) arbeiten.

Gruß
Oliver
 
Routingfrage für Freetzbox als OpenVPN-Client

Hallo,
ich habe folgende Konstellation:
Versch. PCs und eine Freetzbox* in Netz1 (192.168.178.0) von Fritzbox1
OpenVPN-Server (mit Netz 10.0.0.0 für openVPN), anderer Server, und versch. PCs in Netz2 (192.168.179.0) von Fritzbox2
Die Freetzbox in Netz 1 macht als OpenVPN-Client über das Internet eine Verbindung zum OpenVPN-Servers in Netz2. Die PCs in Netz 1 werden bei Bedarf durch einen Routing-Eintrag in Fritzbox 1 über die Freetzbox in das Netz des OpenVPN-Server (10.0.0.0) geleitet. Im OpenVPN-Server ist die Rückroute zum Netz1 eingestellt.
Das funktioniert alles.
Jetzt habe ich ein "Advertising" im OpenVPN-Server eingestellt, sodaß er eine Verbindung zwischen openVPN-Netz (10.0.0.0) und Netz2 (192.168.179.0) macht. Ein normaler OpenVPN-Client als Software auf einem PC im 192.168.178.0-Netz kann nun den anderen Server im 192.168.179.0-Netz ohne Probleme erreichen, aber kein PC, wenn er den Weg über die Freetzbox geht.
In der Fritzbox 1 habe ich daher ein zweites Routing zum 192.168.179.0-Netz über die Freetzbox als Gateway eingerichtet. Wie bringe ich jetzt der Freetzbox bei, das sie eine Anfrage in das 192.168.179.0-Netz weiterleitet?
*) eine Fritzbox 7050 mit Firmware 14.0.33freetz-1.1.4. OpenVPN-Paket-Einstellungen: Client, UDP, Brücke(TAP), "mit LAN brücken" aktiviert.
Wo und wie muss ich das Routing einstellen? Unter "VPN IP-Adresse und Routing im VPN" habe ich es schon erfolglos probiert.

Gruss
 
Zuletzt bearbeitet:
Routing im VPN ist aber richtig, es sei denn, es ist überflüssig, weil der Server die Routen pushed.

Wenn du eine Multi-Client Umgebung hast, sind zudem auch "iroute" Einträge auf dem Server nötig, die das Netz mit dem FB-VPN-Client verknüpfen. Hast du ein "CCD" (client-config-dir) für den Client oder Skripte bei der Verbindung, die das tun können?
 
OpenVPN Portweiterleitung 7390

Hi,

ich bin heute von einer 7270 auf eine 7390 umgestiegen und wollte jetzt mein OpenVPN-Server in Betrieb nehmen. Jetzt musste ich aber feststellen, dass es die AVM-Firewall in Freetz nicht mehr gibt und ich weiß jetzt nicht, wie ich den VPN-Port auf die FritzBox weiterleiten soll.
In der ar7.cfg finde ich den Abschnitt forwardrules nicht. Die Regeln sind unter den jeweiligen IP-Devices definiert.
Kann mir jemand helfen? Wie kann ich den Port auf 0.0.0.0 leiten?

Danke!
 
Keiner eine Idee??
 
Immer ruhig, es sitzt keiner vor dem PC und wartet nur darauf, eine Anfrage von dir umgehend zu beantworten ;-)
Lies bitte auch nochmal dazu die Forenregeln, speziell 5.10.

Für die neueren Firmwares gibt es das Paket AVM-Forwarding, dafür musst du aber im menuconfig "experte" sein.

Bitte dieses Paket nur für Forwardings auf die Box selbst benutzen.
 
Zuletzt bearbeitet:
Vielen Dank für Deine Antwort MaxMuster und Deine Vorschläge zur Lösung meines Problems!
Da ich den OpenVPN-Service von einem Zentyal-Server nutze, muss ich mal schauen, wie der intern funktioniert damit ich Deinen Vorschlägen nachkommen und Deine Frage beantworten kann. Ist schon eine Weile her, dass ich mich mit OpenVPN beschäftigt habe und bisher lief ja alles zur Zufriedenheit.
Wie diese "advertising"-Option des OpenVPN-Service von Zentyal umgesetzt wurde, interessiert mich besonders.
Gruss
 
Aber wie machen die answere leute !

eine Leute benutzen Openvpn mit fritzbox 7390 oder ?
z.B: http://injelea-blog.de/2013/08/10/auf-der-suche-nach-einem-vpn-anbieter/

oder

http://www.ip-phone-forum.de/showthread.php?t=268976

geht das für manchen und manchen nicht ?

Ich hab noch nie das probiert ! wenn möglich würde Ich gerne vorher wissen... ansonsten muss Ich mehrer Tagen mit Freetz+ openvpn kampfen. ( weil Ich wenig ahnung habe :-( )

wie schnell kann Ich mit fritzbox 7390 + openvpn provider downloaden ? ( Maximal ?)

z.B mit Asus RT-N66U hat gute prozessor , kann es max 16Mbps schaffen ...
 
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.