Raspberry Pi FTP Server über no-ip.biz

2 Kardinalsfehler die du gemacht hast !
1.) Der DynDNS Client gehört niemals auf ein Endgerät hinter einer NAT Firewall (DSL Router) sondern immer auf dem Router selber !
Der Router hält die aktive IP Adresse die zum No-IP Hostnamen gehört und nicht das Endgerät !
Folglich gehört also der DynDNS Client auf dem Router mit den no-ip Daten konfiguriert und nicht der des RasPi

2.) FTP kann man nicht reverse per Port Forwarding übertragen, das geht nur im passive Mode !
Warum das so ist kannst du hier nachlesen:
http://slacksite.com/other/ftp.html
Du musst also zwingend darauf achten das dein FTP Server den Passive Mode supportet.

iptables hat das Wheezy Image per se gar nicht auf dem RasPi. Deshalb ist es auch überflüssig diese zu konfigurieren bzw. es geht gar nicht. Es sei denn natürlich du hast die iptables nachträglich installiert, was aber wenig Sinn macht in einem Home Netzwerk, da der Router ja schon einen Firewall betreibt.

Da der RasPI per se SSH macht musst du auch nicht unbedingt einen FTP Server installieren um Dateien zu transferieren.
Mit Linux Bordmitteln geht das remote bequem mit scp und wenn du einen remoten Winblows Client hast dann ist WinSCP das Tool der Wahl für dich.
Damit lässt sich dann einfach per Drag and Drop Dateien transferieren und das auch noch verschlüsselt.
Grundlagen dazu in diesem Tutorial:
Netzwerk Management Server mit Raspberry Pi

Bei PPTP sollte dir klar sein das du auf dem Router:

• TCP 1723
• GRE Protokoll mit der IP Protokoll Nummer 47 (nicht Port 47 !)

auf die lokale IP Adresse des RasPi forwarden musst !!
Ohne dieses Portforwarding beider Protokolle klappt natürlich niemals ein externer PPTP Zugriff auf ihn, da die Router NAT Firewall sonst den PPTP Zugriff verhindert, was sie ja auch soll...
Auch dafür hat ein Forumstutorial wieder mal alle Details für dich:
VPNs einrichten mit PPTP

Beachtet man das funktioniert der RasPi wunderbar als PPTP Server !

Noch ein Tip:
Installier dir mit sudo apt-get install tcpdump einen kleinen Sniffer auf dem RasPi und checke ob das Port Forwarding auf deinem Router sauber funktioniert und diese Pakete überhaupt alle am RasPi ankommen !!
Wie man tcpdump bedient kannst du u. a. hier nachlesen:
http://danielmiessler.com/study/tcpdump/

Und nochwas, was deine 3G Router Gurke von NetGear anbetrifft:
Wenn du dort nur einen billigen 3G Surf only Account hast, dann bekommst du vom Provider dort in der Regel eine RFC 1918 IP Adresse, Private IP am 3G Routerport !
http://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
Das bedeutet dann das der Provider irgendwo zentral in seinem Backbone NAT (IP Adress Translation) macht !
Ist das der Fall nützt dir dein Port Forwarding am Router natürlich herzlich wenig, denn diese Provider NAT Firewall kannst du niemals überwinden, da du ja dort logischerweise, da du keinen Zugriff darauf hast, kein Port Forwarding definieren kannst, was aber zwingend erforderlich wäre !!
Das musst du unbedingt am Router checken WAS ür eine WAN/Internet Port IP du vom Provider bekommen hast !
Ist es eine der obigen privaten IPs kannst du sämtlichen remote Zugang dann gleich vergessen !!
Zusätzlich filtern die Mobil Provider oft noch sämtliche VPN Protokolle die den teureren "Professional" oder "Business" Accounts vorbehalten sind !

Gehabt haben musst Du sie aber mal! ~chr@178.115.249.79.wireless.dyn.drei.com

Genau so etwas hatte ich eigentlich von Deiner öffentlichen erwartet!

Es kann aber auch gut sein das Dein ISP (Mobile Provider) viele oder sogar alle Dienste blockt, so
wie @aqui es auch schon angesprochen hat, um Dir bzw. allen seinen Kunden, die mehr mit Ihrem
Internetzugang machen wollen, eben einfach einen teureren und meist Business Tarif genannten Tarif
"an zu drehen"!

FTP hat gar keine Verschlüsselung! Und wenn jemand Deine No-IP Adresse heraus
bekommt dann kann er in Ruhe in Deinen FTP einbrechen und/oder einfach Deinen nächsten
Login Versuch mitzuschneiden oder sonst etwas zu machen was dieser jemand eben interessant findet!

Ich sage Dir jetzt einmal was, wenn ich VPN, FTP, SSH oder irgend etwas anderes, einen Dienst mittels
eines Protokolls, testen möchte, mache ich das nur und ausschließlich von außerhalb, denn von innerhalb
Deines Netzwerkes interessiert uns und Dich nicht wirklich!!!


Also ich würde von vorne herein versuchen immer via VPN mittels IPSec auf mein Heimnetzwerk zuzugreifen!
- Die Verschlüsselung gilt bis heute noch nicht als kompromittiert und somit als sicher und
- Ich müsste vorne an der Firewall und an dem Router auch keine Ports öffnen, was mir persönlich wichtig wäre.

Und erst wenn das nicht funktioniert, dann erst würde ich versuchen mittels eines VPN Servers in einer
richtigen DMZ und nur dort meinen Dateien zu erreichen, obwohl ich persönlich selbst davon schon Abstand
nehmen das es mir zu unsicher ist!!!!!

Denn wenn jemand erst einmal Bilder von kleinen nackten Kindern auf Deinem kleinen Linux Server ablegt hast Du
eigentlich schon verloren!!!! und in Österreich spricht sich das auch schnell herum warum die Polizei morgens um
frei Ihr bei Euch geklingelt hat!!!! Un das ist es einfach nicht wert glaube mir einfach, das ist die Bequemlichkeit
nicht wert!!!

Also erstens, schreib mal Deinen Provider an oder ruf da einfach mal an das kostet ja nichts und wir sind alle schlauer.
Sollte dieser mitteilen dass dort nichts geblockt wird, musst Du wohl oder übel vorne am Router der ja auch NAT und
SPI macht, ein paar Ports öffnen und per Portweiterleitung an Deinen FTP Server bringen! Und das wäre mir schon
zu lau seitens der Sicherheit!

- FTP sendet und empfängt unverschlüsselt und daher unsicher
- PPTP gilt als kompromittiert und ist somit auch nicht mehr sicher
- Offene Ports am Router sind auch unsicher und sollten auch nur in Zusammenhang mit einer DMZ genutzt werden

Eine Notlösung ist, wenn Deinen Eltern einen Kredit aufnehmen müssen,
um für Dich einen sehr guten Anwalt zu bezahlen, weil irgend jemand mit
Deinem kleinen Server herumgespielt hat und/oder von dort etwas anderes gemacht hat als nur zu surfen!

Meine Tipps an Dich:
- Kauf Dir einen richtigen echten VPN fähigen Router oder eine VPN fähige Firewall
- Leg Dir einen Internetzugang zu der alle Dienste und Protokolle zur Benutzung bietet
- Schaff Dir ein NAS an und/oder mach den kleinen RPI sicher und härte das System ab!
- Benutze ausschließlich ausreichend verschlüsselte Verbindungen durch das Internet nach Hause und am besten nur IPSec.
Man kann bei dem geeigneten Internetzugang auch auf OpenSource Software wie zum Beispiel pfSense oder IPFire zugreifen

Ist nicht böse gemeint von mir aber so wie Du das vorhast zu erledigen, würde ich da mal Abstand von nehmen wollen.
Hauptsache es läuft irgend wie und dann kann jeder in Deinem Netz herum rennen und machen was er will,.....

Gruß
Dobby

Noch ein Tip:
Viele dieser Router kommen nicht damit klar wenn die SIM eine PIN definiert hat. Das solltest du auch checken und ggf. die PIN löschen sofern du keinen Internetzugang im Mobilnetz bekommst.
Sollte auch im NetGear Handbuch stehen !

"...Wie check ich das ob nicht der Router oder die Sim diese Backbone NAT (IP Adress Translation) macht?? "
Nun, diese Frage ist ein wenig peinlich, aber nundenn...
Du gehst ganz einfach in das Setup GUI deines Routers. Dort gibt es mit Sicherheit einen "Status" oder WAN Port Status den man abfragen kann und der dir die aktuelle am WAN oder UMTS Stickport aktive IP Adresse ausgibt !
DIE ist relevant !
Das darf keine 10er, 172.16-32er und keine 192.168er IP sein !

Was deine interne Struktur anbetrifft ist das schon OK. Hinweise dazu findest du auch hier:
VPNs einrichten mit PPTP
im Kapitel "Tips zum IP Adressdesign" !!
Fazit: Tutorial lesen !! Dann machen...

"Also hier nochmal meine Verbindungsdaten:
Wieistmeineipadresse.at 178.115.249.xx "

Diese Info nutzt leider gar nix !! Damit ist ncht eindeutig sicher WO das NAT gemacht wird !!
Das kann zentral sein im Mobilfunk Provider Netz oder eben direkt am Router. Letzteres wäre für dich zwingend erforderlich damit es klappt !
"Wieistmeineip.de" zeigt ja nur an mit welcher Absender IP die Pakte bei ihm ankommen. Ob das die NAT Absender IP deines Routers ist oder die des zentralen NAT Gateways im Providernetz (wo du logischerweise keinen Zugriff hast) sagt es genau eben nicht !!

Wenn du oben mal genau gelesen hättest im Thread (was wie immer keiner macht... ) hättest du den Router Output hier gar nicht posten müssen....!!
Leider ist es genau das was befürchtet war:
Wireless-Broadband-Port
Verbindungsstatus Verbindung hergestellt
IP-Adresse 10.68.196.xxx <<--- zentrales Mobilfunk Provider NAT, denn die 10er Adresse ist KEINE öffentliche IP siehe HIER !!
Protokoll PPP

Du hast eine billige Surf ONLY SIM Karte und dort bekommst du einen RFC 1918 IP vom Provider mit zentralem NAT.
Da du auf dem NAT Gateway des Providers keinerlei Port Forwarding eintragen kannst, schlägt also jeglicher remoter Zugriff per Portforwarding auf Geräte hinter deinem Router generell fehl !

Du hast nur 2 Chancen das zu lösen:
1.) DU baust ein VPN irgendwohin auf, also die VPN Verbindung MUSS immer von dir initiiert werden ! Das klappt aber nur einzig mit SSL basierten VPN Protokollen wie Open VPN oder SSH Tunneling wie hier beschrieben:
VPN für Arme - TCP in SSH tunneln mit Putty
Alternativ geht noch IPsec mit aktiviertem NAT Traversal aber immer nur wenn DU die VPN Session initiierst, sonst kannst du das Provider NAT nicht überwinden !
Auf dem Raspberry geht das wunderbar mit dem IKE Package (Shrew Client) mit
sudo apt-get install ike
installierst du das schnell und problemlos auf dem RasPi. Open VPN wenn du das als VPN Protokoll vorziehst analog.
Dieses IPsec Tutorial sagt dir genau wie:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das IKE Package hat eine grafische Oberfläche auch auf dem RasPi zur bequemen Konfiguration !!
Bzw. für Open VPN gilt das hier auch für den RasPi:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das o.a. zitierte RasPi_Tutorial hat einzelne Infos und weiterführende Links zu diesen Themen !

Port Forwarding schlägt logscherweise durch das zentrale Provider NAT generell immer fehl in so einen Szenario mit billig Surf Only Account.

2.) Du besorgst dir einen anderen Surf Account (Business) wo du einen öffentliche IP vom Provider bekommst !
Andere Chancen hast du de facto nicht.

Welche Ports hast du denn genau freigegeben?Läuft der FTP als passiven oder aktiv?

@daropstyle
Die Frage ist überflüssig und sinnfrei wenn er einen zentralen NAT Account (Surf Account) vom Provider hat !
Dann kann er soviel Port Forwarden wie er will, das wird nichts nützen.
Ist ja auch klar, denn den relevanten Port Forwarding Eintrag müsste er im Provider NAT Gateway machen wo er keinen Zugriff hat. Außerdem würden das dann auch noch zig Millionen andere Kunden machen wollen....Utopisch, klar !
Da er ja so einen Account hat wie man unschwer an seiner RFC 1918 IP vom Provider 10.68.196.xxx oben sieht, hat er also technisch keine Chance....auch wenn du mit ihm zig mal das Port Forwarding durchgehst.
Oder was war die Intention deiner o.a. Frage ??

Er hat genau die 2 oben aufgeführten Chancen das technisch zum Fliegen zu bringen !
Klassischer Standard bei Billig nur Surf Accounts und remoten Zugriff. Kommt hier wöchentlich im Forum rein....

Was ist denn da bitte "nicht so einfach" ??? Das ist kompletter Blödsinn, denn unter Linux ist das erheblich einfacher als unter Winblows, da Linux alles dafür schon an Bord hat ! Und auch noch einfacher zu troubleshooten.
Keine Ahnung warum du zu einer unsinnigen Aussage kommst, denn wenn dann liegt das "Problem" höchstens an dir selber nicht aber am Raspberry !!
Es gibt hier genügend Forumstutorials die dir helfen:
Netzwerk Management Server mit Raspberry Pi
und
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
und
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Wenns das denn jetzt war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !

Wenn du dich ein wenig mit Open VPN beschäftigt hättest, dann hättest du schnell erkannt das die Konfiguration überall gleich ist !
Es ist völlig egal auf welcher OS Plattform man das konfiguriert die Schritte sind immer dieselben !! Sogra bei Winblows.
Halte dich also daran, dann machst du nix falsch.
Beachte die Punkte (Port Forwarding UDP 1194) wenn dein RasPi hinter einer Router NAT Firewall steht !
Das o.a. Raspberry Tutorial hat aber auch einen Link zur OVPN Installation (unter "Weiterführende Links"). Vermutlich hast du die auch "überlesen":
http://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
Aber als armer Winblows Klicki Bunti Knecht bist du ja nun mit dem Raspberry auf dem allerbesten Wege nun mal ein richtiges Betriebssystem kennenzulernen und den arg eingeengten MS Horizont drastisch zu erweitern. Allein das ist schon genug Anerkennung wert...

Fehlt ja dann nur noch
Wie kann ich einen Beitrag als gelöst markieren?

Ähhh..., was meinst du mit der Fehlermeldung ?? Das Uploaden von Bildern hier oder das Schliessen des Threads ??

So, und nun zum Rest...

• no ip client ?? Was soll das sein ? Open VPN Konfig ? Raspi Konfig ?
• NAS eingerichtet ?? Mmmhhh hat aber jetzt nix mit dem OVPN Konfig usw. zu tun, oder ?

Mit dem "Latein am Ende" meinst du damit das du jetzt nicht weisst wie es weiter geht oder das es nicht klappt ??

Um das zu klären solltest du erstmal folgende grundlegenden Fragen beantworten:

• Open VPN installation hast du gemacht, richtig ?
• Hast du alle Zertifikate generiert ? Und...hast du diese Zertifikate an die richtigen Stellen kopiert ?
• Dein Raspi soll als OVPN Server laufen, also du willst dich remote einwählen da per VPN, richtig ?
• Hast du die Server config Datei erstellt gemäss deines VPNs ( IP Adressen etc.) ?? Ggf. hier bitte posten

OK wenn das der Falls ist musst du OpenVPN erstmal stoppen, das geht mit etc/init.d/openvpn stop ("sudo su" davor natürlich)
Nun solltest du mit openvpn /etc/openvpn/openvpn.conf OpenVPN erstmal testweise manuell starten um zu sehen ob dort ggf. Fehlermeldungen auftauchen die auf Fehler in der Konfig hinweisen !
Siehe obiges OpenVPN Tutorial im Kapitel "Ist der OpenVPN Server aktiv ?" !
Ist das nicht der Fall kannst du das erstmal so lassen und mit einem lokalen OpenVPN Client die Verbindung aufbauen auf den Server.
Da er jetzt manuell gestartet ist wirst du bei der Verbindung des Clients etwaige Fehlermeldungen gleich Online sehen.
Zusätzlich siehst du sie auch im Client Log wenn denn welche kommen !
Ist alles richtig sollte sich der Client fehlerfrei verbinden !
Etwaige Fehlermeldungen dann hier posten...
Wenn der Client verbunden ist kannst du (bei einem Windows Client) einmal ipconfig eingeben. Ist alles sauber gelaufen wirst du am VPN Interface eine vom OVPN Server zugeteilte IP Adresse im VPN Tunnel sehen die der im Konfig File entspricht !

Wenn das alles so ist kannst du den manuell gestarteten OVPN Server auf der Konsole mit <ctrl> c stoppen und ihn mit etc/init.d/openvpn start dann als Daemon wieder im Hintergrund starten.
Damit wäre das Teil dann auch von remote einsatzbereit.
Bedenke das die Zieladresse des remoten Clients immer die öffentliche IP Adresse des Routers ist der das Port Forwarding macht ! Oder dessen DynDNS Hostname.
Aber erstmal wasserdicht lokal testen bevor man "nach draußen" geht !

Nur mal so nebenbei: ".. in der *.OVPN meinen no-ip Server Host eingebeben" DAS musst du aber nur einzig auf dem OVPN Client machen und NICHT auf dem Server ?! Ist dir hoffentlich klar ?!

push "redirect-gateway def1" Muss nicht sein, denn damit redirectest du den gesamten Internet Traffic deines Clients über den OVPN Tunnel. Es reicht hier einfach dein lokales Netz zu propagieren also push "route 192.168.15.0 255.255.255.0"

#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
Ist eigentlich auch überflüssig, denn einen DNS remote brauchst du nicht erzwingen, den bekommst du ja so.

Der Rest sieht gut aus !
Sinnvoll wäre nochmal der Output wenn du den OVPN Server manuell startest, ob dort fehlermeldungen passieren und...
was passiert wenn du den Server lokal im 192.168.15er Netz ansprichts mit einem Client !