Ob das nun ein grundsätzliches Problem ist oder nur auf meine Fritzbox in Kombination mit DynDNS.com zurückzuführen ist, ist mir noch nicht wirklich klar. Fällt mir auch nicht wirklich auf, da ich nicht täglich auf die DDNS Dienste angewiesen bin. Wenn man allerdings beispielsweise VPN über sein iPhone nutzen möchte und die Verbindung nicht aufgebaut werden kann, dann sucht man schon erstmal ein wenig
Einfach mal unter Internet -> Onlinemonitor nachsehen, ob dort bei Dynamic DNS unter Status ebenfalls Fehler steht.

Gibt es noch andere Nutzer, die derzeit Probleme haben und die Aktualisierung nicht mehr automatisch und problemfrei funktioniert? Würde mich interessieren…..

Update 1, 04.01.2012
Es handelte sich wohl um eine temporäre Problematik bei DynDNS. Seit nunmehr einigen Tagen ist es nicht wieder aufgetreten. Daher sehe ich also mal die FritzBox als unschuldig an

    Wozu könnte man nun den FTP Speicher brauchen?

Eine Variante ist wohl, seine Backups dort abzulegen. Hat man seine lokalen Backups (auf seinem NAS) nicht nur gerne an einem Platz in den eigenen vier Wänden sondern auch außerhalb, so kann der FTP Speicher hierfür herhalten.
Allerdings sollte man gerade bei dieser Situation vorsichtig sein!
Alle Daten gehen unverschlüsselt durch das Netz und sind auch unverschlüsselt auf dem FTP Speicher. Das hat zur Folge, dass u.U. jemand unberechtigt diese Daten mitlesen kann! Man sollte sich also lieber vorher dessen im Klaren sein und u.U. lieber nur einen TrueCrypt Container auf dem Speicher ablegen. Diesen könnte man dann ebenfalls über den FTP Zugang als “lokalen” Speicher mounten, mit TrueCrypt öffnen und dann mit rsync seine Daten syncen. Das hat zumindest den gewaltigen Vorteil, dass keiner die Daten unberechtigt mitlesen kann.

    Mounten des entfernen Speicherplatzes

Die unten beschriebenen rsync Aufrufe gehe von der Situation aus, dass der lokale Speicher zu dem FTP Speicher “hoch”gesynct werden soll. Möchte man den umgekehrten Weg gehen (also Speicher vom FTP Server zu seinem lokalen Rechner syncen), so müssen die Quell- und Zielnamen getauscht werden.

Wir legen auf dem Quellsystem (dort, wo der FTP Speicher hingemountet werden soll) ein Verzeichnis an, in welches der remote FTP Speicherplatz “reingemountet” wird:

shell #> sudo mkdir /media/remoteftphost/

Nun rufen wir auf der Kommandozeile curlftpfs auf und geben den remote FTP Host mit:

shell #> sudo curlftpfs -o user=ftpusername -r -s ftp.hostname.zieltld /media/remoteftphost/

Hiermit mounten wir den Speicher per FTP von ftp.hostname.zieltld nach /media/remoteftphost/ auf unserem lokalen System. Der speicher steht zur Verfügung. Geht man nach /media/remoteftphost, so sieht man die auch per FTP sichtbaren Dateien und Verzeichnisse. Voilá.

Nun können wir ganz normal mit cp, rsync und was sonst noch so anfällt auf den Speicher zugreifen. Natürlich können wir auch auf dem Speicher neue Dateien anlegen und diese direkt bearbeiten. Man muss nur im Hinterkopf haben, dass alles unverschlüsselt übertragen wird. Ebenfalls muss bedacht werden, dass die Übertragung zum Teil etwas Zeit benötigt. Es ist halt kein richtiger lokaler Speicher. Und das FTP Protokoll glänzt durch unnötigen Overhead in diesem Zusammmenhang auch nicht unbedingt mit Performance…

    Warum man lieber kein FTP nehmen sollte….

  FTP ist zwar fast überall zu bekommen, hat aber Nachteile. Sicherheitsnachteile, da alles unverschlüsselt und ohne Absicherung des Datenverkehrs durchs Internet geroutet wird. Somit werden auch der Benutzername und das Passwort unverschlüsselt übertragen. Sollte irgendwer den Datenverkehr mitlesen können, kann der somit auch die Zugangsdaten herausbekommen. Daher sollte man immer zusehen, verschlüsselte Kommunikationswege zu nutzen: Also SFTP, scp, rsync über SSH usw. usf.
Leider hat sich FTP trotz dieser Sicherheitsprobleme als Protokoll für Datenverbindungen/ -austausch durchgesetzt. Die Absicherung des Datenverkehrs genießt bei vielen leider keine große Priorität. Vermutlich machen sich einige erst Gedanken über diese Probleme, wenn es zu spät ist. Also erst, wenn illegale Daten über den Speicherplatz getauscht wird und der Datenverbrauch massiv ansteigt.

    Wo man es einsetzen kann….

  Den FTP Speicher im lokalen Netzwerk von z.B. einem Netzwerkgerät (FritzBox, bilig-NAS usw.) mounten und nutzen ist, sofern man seinem Netz vertraut, wohl kein Thema. Solche Boxen gibt es ja leider immer wieder, die von richtigen Netzwerkprotokollen (AFP, NFS usw.) nicht gehört haben.
Den “FTP Speicher” seiner FritzBox mounten um dort die Konfigurationsdateien für OpenVPN & Co. zu bearbeiten ist halt doch etwas angenehmer als per FTP die Datei herunterladen oder, sofern der FTP Client das unterstützt, live zu ändern.

    Absicherung des Datenverkehrs durch VPN

  Gibt es für den Zugriff tatsächlich nur FTP und man möchte die Daten während der Übertratung absichern, so ist der Weg über einen VPN Tunnel ideal. Einfach einen OpenVPN/ IPsec VPN Tunnel zum Zielsystem aufbauen und den Datenverkehr durch diesen Tunnel tunneln. Damit hat man zumindest den Datenverkehr zwischen den Tunnelendpunkten (sein Heimnetz bzw. PC und dem Zielsystem) gesichert. Der Datenverkehr lässt sich beim Transport durch das Internet nicht mehr mitlesen. Natürlich kann dann trotzdem noch immer auf dem Zielsystem dieser dann entschlüsselte Datenverkehr gelesen werden, dieses ist im Vergleich zu dem komplett unverschlüsselten Datenverkehr wohl das geringste Risiko.
Nimmt man dann einen TrueCrypt Container als Speicher auf dem FTP Server, so ist man wohl recht gut gesichert. Der Container auf dem Zielsystem lässt sich nicht entschlüsseln, der Datenaustausch findet über den OpenVPN Tunnel statt. Das Risiko ist somit deutlich reduziert und sollte auch einen paranoid angehauchten Menschen beruhigt schlafen lassen….

Hinweise

  Man sollte bei rsync immer vorsichtig damit sein, vorschnell die Optionen --delete oder sogar --delete-after zu nutzen. Macht man hierbei etwas falsch, so könnten Daten schnell mal den Weg allen irdischen gehen… Hat man dann nicht noch ein drittes Backup, so sieht es schlecht aus….
Also vor allem bei der Nutzung von Scripten Vorsicht walten lassen. Lieber einmal zu viel prüfen, ob der Speicher wirklich gemountet ist und nicht voreilig mit delete-Optionen sein.

Ebenfalls, wie weiter oben schon angesprochen, sind alle Daten beim FTP Protokoll unverschlüsselt! Ohne weitere Maßnahmen können Benutzername und Passwort sowie der komplette Datenverkehr mitgelesen werden!

  Nun hat es sich ergeben, dass mein Android Smartphone HTC Desire S entgegen meiner Hoffnung mehr als unbrauchbar ist, was VPN (und ein paar Dinge mehr…) angeht. Vom iPhone habe ich bisher ohne Probleme einen IPsec VPN Tunnel zur FritzBox herstellen können. Das derzeit installierte (und von HTC in der Aktualisierung vernachlässigte) Android 2.3.3 macht kein normales IPsec sondern L2TP/IPsec. Und das kann die FritzBox (die nur “reines” IPsec macht) wiederum nicht. PPTP und OpenVPN kann das Android (und iPhone) ebenfalls auch nicht. Also musste etwas VPN-ähnliches her, was das Android ebenfalls kann. Wenn möglich natürlich auch das MacBookAir, das iPhone…

“Aus Gründen” probiere ich mich hier an einem MikroTik 750G mit dem derzeit (August 2011) offiziellen Release RouterOS 5.6 aus. Eine sehr kleine und äußerst geniale Kiste, die alles kann, was IP macht. Naja, fast alles

Die VPN Möglichkeiten sind derer vielfältig: OpenVPN, IPsec, PPTP, SSTP, LT2P.
PPTP ist somit leider quasi der einzige, kleinste gemeinsame Nenner zwischen Android, iPhone, MacBookAir und dem MikroTik Router OS. PPTP gehört schon seit Jahren nicht mehr zu den Protokollen, die man einsetzen wollen würde. Aber, es hilft leider nix ;-(
Das MacBookAir ließe sich auch mit OpenVPN einrichten und über dieses ein VPN Tunnel herstellen. Die Vorbereitungen, d.h. der benötige OpenVPN Server wären ja da. Aber wenn man das nicht über auf den Smartphones einsetzen kann, ist es auch unnötig. Als zusätzliche oder alternative Anbindung kann es ja bestehen bleiben.
Also beiße ich in den sauren Apfel und erstelle mir einen PPTP Zugang, um von remote wieder in mein LAN zu kommen. Und auch gleich, um darüber ins Internet und auch den OpenVPN Tunnel zu kommen. Somit also gar nicht sooo schlimm, auch wenn man sicherheitsrelevante Verbindungen sicherlich nicht über den PPTP Tunnel fahren wollen würde. Da hätte ich schon immense Bauchschmerzen. Aber das ist eine andere Geschichte…

Zum Aufbau:
Die FritzBox terminiert das Internet und wählt sich per PPPoE ins Internet ein. Der MikroTik Router ist wiederum an die FritzBox angeschlossen. Ein LAN Port des MikroTik ist quasi der Weg ins LAN (nachfolgend “Uplink Port”). An die anderen Ports des MikroTik sind derzeit keine weiteren Geräte dauerhaft angeschlossen, die LAN Ports sind als Switchports konfiguriert.
LAN Port 1 ist mit einer festen IP Adresse (IP -> Adresses; zugeordneter Switchport) aus dem normalen LAN (wir nennen es mal Intranet) konfiguriert. Ein zweiter LAN Port des MikroTik erhält eine IP Adresse aus einem ganz anderen IP Bereich und dient der Einrichtung u.a. der Firewall. AUf diesem wird ein DHCP Server eingerichtet, der IP Adressen vergibt. An den damit für den “internen Gebrauch” konfigurierten LAN Port wird erstmal ein Laptop zur Konfiguration angeschlossen. Somit kann man die Firewall-Regeln anpassen und sägt sich bei einem Fehler nicht gleich den Ast ab
Hat man den MikroTik so eingerichtet, dass man zur Not auch noch per SSH o.ä. vom Intranet drauf kommt, kann man sich das natürlich auch sparen.

Einrichten eines PPTP-Zugangs auf dem MikroTik per WebFig unter RouterOS 5.6

  Den Benutzern (Clients) weise ich statische IP Adressen zu. Dieses macht es nachher einfacher, Firewallregeln und ähnliche Dinge zu regeln. Man möchte ja vll. auch Benutzer haben, die nur per VPN und dann ins Internet, jedoch nicht ins Intranet kommen sollen.
Unbedingt default-encryption wählen. PPTP ist ja schon nicht der Hit. Aber ohne Verschlüsselung (gut, die ist auch eher einfach zu knacken) wäre das alles noch viel sinnfreier. So hat man zumindest MPPE128 Verschlüsselung. Besser als gar nix…

PPP > Secrets > Add new
Name: irgendeinbenutzername
Password: einMoegl1chstSIcher3sPazzworD
Service: pptp
default profile: default-encryption
Local Address: 192.168.1.1
Remote Address: 192.168.1.123

(Das IP Netz ist völlig unabhängig vom eigentlichen Intranet-IP-Bereich. Hier kann man sich frei auslassen und ein für sich brauchbares Netz wählen. Überschneidungen mit anderen IP Netzen sollte man natürlich vermeiden.)

Der Client kann sich nun mit seiner Benutzer-Passwortkombination anmelden. Zum Testen kann man nun einfach mal einen Rechner am internen LAN Port des MikroTik anschließen und den PPTP Zugang auf die (für die Switchports konfigurierte) IP des Routers verbinden. Das sollte schon einmal funktionieren. Klappt es, so ist der erste Schritt erfolgreich erledigt und man kann sich um die Firewall für den Uplink-Port kümmern.

Firewallregeln

  Der Router soll natürlich nicht alles von außen erlauben. Wie es sich gehört wird erstmal alles verboten. Wir machen in der Firewall nun die für den PPTP Zugang nötigen Ports auf, so dass man aus dem Intranet (also dem Netz, was an den Uplink-Port angeschlossen ist) per PPTP zugreifen können.
Zwei Regeln unter IP -> Firewall sind nötig, damit die PPTP Verbindung erfolgreich auf dem MikroTik ankommen kann und nicht direkt geblockt wird:

Chain: Input
Protocol: 6 (tcp)
Dst. Port: 1723
In. Interface: Name des Uplink Ports
Action: accept

Chain: Input
Protocol: 47 (GRE)
In. Interface: Name des Uplink Ports
Action: accept

Diese Regeln werden irgendwo sinnvoll zwischen der ersten und vor der letzten Regel (deny-any) durch drag&drop einsortiert. Ist man sehr restriktiv empfiehlt es sich, die Regeln vor allen deny-Regeln einzusortieren. Fertig.

Zum Testen kann man nun versuchen, sich per PPTP aus dem Intranet zu verbinden. Hat man alle Regeln korrekt eingerichtet wird die PPTP Verbindung erfolgreich aufgebaut. Firewall und PPTP Zugang sind somit korrekt eingerichtet. Bingo

Portweiterleitung aus dem Internet über die FritzBox auf den MikroTik

  Funktioniert der PPTP Tunnel aus dem Intranet, so hat man schon ein gutes Stück geschafft. Nun gilt es, die FritzBox zu überzeugen, die Verbindungen aus dem Internet anzunehmen und an den MikroTik Router weiterzuleiten.
Hierzu sind auf der FritzBox ein paar Portweiterleitungen einzurichten, die sich unter Internet -> Freigaben -> Portfreigaben finden. Dort sind zwei Einträge anzulegen, einer für GRE (Generic Routing Encapsulation), einer für Port 1723 (die PPTP Kontrollverbindung).
Router, die die Option “VPN Passthrough” unterstützen brauchen diese Einstellungen nicht. Einfach aktivieren, dann sollte das auch ohne Probleme gehen.

Portfreigabe für die Kontrollverbindung:

Portfreigabe aktiv für: Andere Anwendung
Bezeichnung: PPTP Kontrollverbindung zu MikroTik (oder irgendein anderer Name für die Verbindung)
Protokoll: TCP
von Port: 1723
an Computer: Manuelle Eingabe der IP Adresse
an IP Adresse: 192.168.178.123
an Port: 1723

(Hier nehme ich exemplarisch die IP 192.168.178.123 als IP des MikroTik. Diese ist entsprechend dein eigenen Begebenheiten anzupassen.)

Und die GRE Verbindung wird wie folgt eingerichtet:

Portfreigabe aktiv für: Andere Anwendung
Bezeichnung: PPTP GRE-Verbindung zu MikroTik (oder irgendein anderer Name für die Verbindung)
Protokoll: GRE
an Computer: Manuelle Eingabe der IP Adresse
an IP Adresse: 192.168.178.123

(Auch hier ist die IP 192.168.178.123 entsprechend den eigenen Begebenheiten anzupassen.)

Das sieht auf der FritzBox dann so aus:

Die Porweiterleitung sollt nun alle Anfragen auf dem entsprechenden Port bzw. dem entsprechenden Protokoll zum MirkoTik Router weiterleiten.Ein Verbindungsversuch dem Internet per PPTP kommt nun auf dem MikroTik an. Hier kann man entweder in den Logs oder beispielsweise der Firewall unter den empfangenen Paketen eine Erhöhung sehen.

Einrichtung auf dem MacBook Air/ Mac OS-X 10.7

  Die Einrichtung beschränkt sich natürlich nicht nur auf ein MacBook Air. Da dieses jedoch bei mir das portable MacBook ist, was ich unterwegs mit VPN nutze, bezieht sich die Beschreibung auf das “Air”. Die PPTP-VPN Einrichtung sollte bei jedem anderen, MacOS-X 10.7 Gerät identisch sein. Auch Einrichtungen unter OS-X 10.6 und älter sollten nach dieser Anleitung einwandfrei funktionieren (oder zumindest die richtigen Hinweise geben)…
Einstellungen -> Netzwerk, hier unten auf das Pluszeichen. In dem darauffolgenden Fenster kann man sich einen Namen für die Verbindungen wählen, als Verbindungstyp PPTP.



Danach sind die Einstellungen für den PPTP Host, Benutzername und Verschlüsselungsstärke zu setzen:

Und das Passwort unter Authentifizierungseinstellungen eingeben, abspeichern.

Wenn mit diesen Einstellungen die PPTP aus dem internen Netz funktioniert, so kann die Serveradresse auf die externe (feste) IP Adresse (sofern vorhanden) oder einen DNS (auch dynamische DNS Dienste wie DynDNS.org usw.) Namen umgestellt werden.

Der VPN Tunnel kann über das in der oberen Statuszeile befindliche VPN Symbol einfach gestartet und beendet werden. Über den laufenden Timer ist man bestens im Blick, wie lange der Tunnel schon up ist.

Einrichtung auf dem Android

  Da dieses ganze Konstrukt nur wg. des Android-Smartphones entstanden ist, hier also endlich noch ein paar Infos zur Einrichtung unter Android…

Unter Einstellungen -> Drahtlos und Netzwerke -> VPN Einstellungen wird über “VPN hinzufügen” ein neuer VPN Zugangspunkt definiert:
VPN-Name: irgendein Name für die Verbindung
VPN-Server festlegen: Der DNS, dynamische DNS Name oder eine feste, öffentliche IP Adresse
Verschlüsselung aktivieren: aktivieren

Abspeichern. Versucht man sich nun zu verbinden wird noch der Benutzername und das Passwort abgefragt. Beides eingeben, den Haken bei “Benutzername speichern” setzen. Fertig.

(Und wenn es unter Android eine Möglichkeit gäbe, einfach und schnell und ohne Zusatzapp und ohne sein Android rooten zu müssen einen Screenshot zu erstellen, dann wäre dieser Screenshot hier zu sehen. Das ist aber wohl auch nicht vorgesehen, braucht ein Android-Nutzer wohl nicht “von Haus” aus….)

Einrichtung auf dem iPhone

  Wie auch andere VPN Einstellungen wird die PPTP Verbindung unter Einstellungen -> VPN -> VPN hinzufügen neu angelegt (oder eine eingerichtete Verbindung verändert).

Der DNS Name (hier beispielhaft: irgendeinDNSname.tld) muss mit der externen IP Adresse oder einem DNS Namen (auch DynDNS Dienste) konfiguriert werden.

Eine bestehende VPN Verbindung wird einem in der Statuszeile mit dem VPN Symbol angezeigt. Leider fehlt den Einstellungen auf dem iPhone die Möglichkeit, eine Verbindung “dauerhaft” aufzubauen. Schön wäre es, wenn man angeben kann, dass das Gerät immer (sofern irgendwie Internet da ist), den Tunnel aufbauen und bestehen lassen soll. Aber, man darf hoffen, dass das irgendwann vll. auch noch mal kommt…

Proxy oder kein Proxy?

Möchte man die Datenbandbreite /-volumen von unnötigen Werbebannern, Zählpixeln und sonstigem Datenmüll befreien und hat einen Proxyserver, so kann unter Proxy dieser eingetragen werden. HTTP-Verbindungen werden dann bei bestehender VPN Verbindung automatisch über den Proxy geschoben, man bekommt im Browser nur noch gesäuberte Inhalte. Das spart z.T. Zeit bei der Übertragung und verringert auch die zu übertragenden Daten. Lohnt sich nicht immer, aber für weniger Werbung sicherlich eine gute Udee.

Probleme

  Ein Problem bei den VPN Verbindungen speziell vom iPhone (und eingeschränkt auch vom Android) nerven mich: Die Verbindung wird nicht dauerhaft aufrecht erhalten. Gerade beim iPhone nervt es, da dieses schon nach kurzer Zeit der Inaktivität die VPN Verbindung beendet. Das Android ist dort etwas besser und lässt den Tunnel auch länger bestehen. Nicht immer auch netzübergreifend (Wechsel beispielsweise vom WLAN in UMTS und zurück), trotzdem schon deutlich länger und besser als das iPhone. Und vor allem auch, wenn das Android einfach im WLAN dauerthaft eingebucht ist aber nicht wirklich genutzt wird. Damit kann man dann sogar schon über einen SIP-Softphone Client nachdenken, der eine SIP Verbindung durch den Tunnel aufbaut. Man sollte sich aber sicherlich nicht drauf verlassen und davon ausgehen, dass der Client “immer” angemeldet ist und man somit über seine SIP Rufnummer (beispielsweise an der FritzBox) erreichbar ist.

Fazit

  Wenn man sicher und ohne große (Sicherheits)Probleme eine VPN Verbindung aufbauen möchte, würde ich selbstverständlich OpenVPN oder IPsec bevorzugen. Ist das nicht (aus welchen Gründen auch immer) einrichtbar, muss man sich halt andere VPN Verbindungen einfallen lassen.
PPTP ist hierbei leider nur eine Notlösung. Das Protokoll, der Verbindungsaufbau usw. ist schon lange nicht mehr state-of-the-art. (Und von Microsoft.) Seit Jahren gibt es sichere, deutlich bessere VPN Protokolle. Diese sollte man immer bevorzugen. Gibt es keine andere Wahl, so kann man natürlich auch auf PPTP zurückgreifen. Aber man sollte sich immer der Problematik bewusst sein die man hiermit eingeht. Für Verbindungen, die man über ein offenes WLAN einigermaßen sicher verschlüsselt haben möchte, ist es OK. Also dann, wenn man in einem offenen WLAN seine komplette IP Kommunikation einigermaßen gesichert übertragen möchte Aber für alles, was sicher ein soll ist es keien Lösung. Dafür ist das gesamte Protokoll lange überholt…. Und es kommt ursprünglich aus dem Hause “Microsoft”. Das würde mich ja normalerweise schon von sowas abhalten……….

Eine kleine, äußerst geniale Kiste ist der MikroTik Router. Und das wird sicherlich nicht der letzte Blogpost über den sein. Schließlich bietet der (was IP angeht) alles, was man braucht. Und zum Rumspielen und Experimentieren ist der einfach klasse…

VPN-Verbindung Der VPN-Server antwortet nicht

gestolpert.
Das verwunderte mich dann schon etwas, zumal es sonst immer geklappt hat. Warum also jetzt nicht mehr?
Etwas in der (Gedächtnis)Änderungsliste der letzten Wochen gesucht und siehe da, was gefunden. Zu Testzwecken hatte ich vor einigen Tagen mal mit der Portfreigabe in der FritzBox die UDP Ports 500 und 4500 auf einen anderen Router weitergeleitet. Und diese sorgen nun natürlich dafür, dass die VPN Verbindung zur FritzBox nicht mehr auf derselben verbleiben sondern weitergeleitet werden. Das ist dann natürlich nicht gewollt gewesen. Also erstmal wieder deaktiviert. VPN Verbindung kann wieder hergestellt werden.

Wer gleiche oder ähnliche Probleme hat sollte das einfach mal prüfen. Sofern man ausschließen kann, dass es nicht an der Konfiguration liegt…

    Inbetriebnahme

Beide Geräte lassen sich nur in Betrieb nehmen, wenn man sich dem einen oder anderen Anbieter anvertraut. Ohne eine iTunes Installation auf dem Rechner wird sich das iPhone nicht in Betrieb nehmen lassen. Über iTunes muss dieses aktiviert werden. Der Androide erfordert ein Google Konto, welches man sich im Inbetriebnahmeprozess einrichten kann. Erst durch dieses Google Konto kann der Android seinen Dienst aufnehmen.
Es ist also kaum ein Unterschied, welchem Unternehmen vertrauen muss. Einzig die derzeit in iOS4 (und in iOS5 endlich behobene) Prozedur, dass alles nur per Kabel geht, unterscheidet sich. Ohne Datenkabel an iTunes kann es nicht aktiviert werden. Hat man also keinen MAC/ PC zur Hand oder kann kein iTunes nutzen kann man das iPhone nicht aktivieren. Auch sehr unschön.

    Backup und Synchronisation

Hier kommen wir zu einem für mich neuralgischen Punkt. Es ist für mich immens wichtig, auf ein funktionsfähiges Backup zurückgreifen zu können. Alle Einstellungen eines Gerätes müssen ohne viel Aufwand und, am Besten ohne dass man sich hierdrum kümmern muss, sichern und im Falle eines Falles wiederherstellen lassen. Und alle Einstellungen bedeutet auch, alle Einstellungen. Das beinhaltet alle Konfigurationen, die man gemacht hat. Alle Programme, die man nachträglich installiert hat. Alle eMail Konten(einstellungen), alle Fotos, Filme usw. usf. Einfach alles, was auf dem Gerät verändert wurde.
Und hier kommen wir zu dem ersten großen Unterschied. Sofern man iTunes hat, hat man auch gleich seine Backup- und Synchronisationssoftware auf dem Rechner. Diese erstellt automatisch (gut, lässt sich auch ausschalten) Sicherungen des Gerätes und synchronisiert die Kontakte, Kalendereinträge zwischen iPhone und Mac. Eigentlich genau das, was man auch auf dem Android haben möchte.
Nun ist das aber scheinbar nicht vorgesehen, eine Sicherung aller seiner Einstellungen, quasi seines kompletten Gerätes auf dem lokalen Rechner zu erstellen. Vielmehr soll der Weg beschritten werden, dass man alle seine Kontakte an Google übermittelt. Ebenfalls kann der Kalender mit Google synchronisiert werden. Alle eigentlich privaten Daten gehen zu Google…. Will man das? Und warum soll ich den Weg gehen müssen, mein Android (welches im Heimnetzwerk oder sogar direkt per USB an den Rechner angeschlossen ist) über Google zu synchronisieren um dann wieder meinen Rechner mit Google synchronisieren zu müssen, obwohl meine Kontakte auf dem selbigen liegen?

Dann gäbe es ja noch die Lösung, das Smartphone per Bluetooth mit iSync auf dem Mac zu synchronisieren. Die Synchronisation mit meinem Nokia Communicator (mittlerweile auch ein paar Jahre alt) klappt hier auch einwandfrei. Wäre doch gelacht, wenn es mit dem Androiden nicht klappen kann. Und siehe da, klappt auch nicht. Eine Bluetooth Verbindung kann mit iSync scheinbar nicht erfolgreich hergestellt werden. Das Gerät wird zwar gefunden, iSync möchte aber nicht mit dem Gerät synchronisieren. Ein Kollege gab mir den Tipp, dass es sich hierbei um ein bekanntes Bluetooth Problem handeln könnte. In Android ist der BT Stack wohl “nicht ganz gut programmiert”. Auch einige Headsets sollen Probleme haben.
  Im Google Market findet sich hierzu auch eine App “Bluetooth Repair Fix”. Problem hierbei: Die benötigt ein gerootetes Gerät. Und, oh Wunder, das geht mit dem Desire S auch nicht, da “secure on” im Bootloader ist. Juchei….
Leider muss man wohl auch von iSync Abstand nehmen: Android Geräte gehören nicht zu den unterstützten Geräten von iSync ;-(

Für dieses eigentlich einfache und elementar wichtige Problem (es sei denn, man synct mit Google) scheint es wohl derzeit keine (kostenfreie) Lösung zu geben. Zumindest nach den ersten Stunden und Tagen der Suche.
Aber findige Entwickler scheinen hier eine Lösung gebastelt zu haben: SyncMate. Leider kostet diese Lösung auch wieder Geld, rund 40 US Dollar bzw. 30 Euro werden fällig für eine Software, die in dem benötigten Funktionsumfang “synchronisieren” auf dem Mac mitgeliefert wird. Gut, diese Software macht deutlich mehr als “nur” das Android zu syncen. Mehrere Macs untereinander syncen, iOS Geräte mit Mac, Android mit Mac usw. Also deutlich mehr, als ich anfangs eigentlich benötige. Ich will doch nur das komplette Gerät backup’en und meine Kontakte und Termine mit meinem Rechner syncen. Mehr doch nicht….

    Bevorzugte (iOS) Apps

Ein weiteres Manko sind die Apps, die auf dem iPhone seit langer Zeit für bequemes Arbeiten sorgen, Funktionen bereitstellen, Dienste liefern oder auch nur der Unterhaltung dienen. Einige dieser Apps sind leider nicht im (offiziellen) Android Market verfügbar bzw. existieren für Android nicht. Und werden vielleicht auch nicht für Android kommen.

  Remote
  Eine iTunes-Fernbedienung für das iPhone. Hiermit lässt sich iTunes recht komfortabel fernsteuern: Musik wiedergeben oder pausieren, die Lautstärke verändern oder einfach die Musikauswahl verändern. Alles in allem eine nützliche App, wenn man beispielsweise seinen MacMini an seiner Stereoanlage angeschlossen hat und nicht immer zum Ändern der Lautstärke oder des Titels durchs halbe Haus laufen möchte.
Und genau solche App (in kostenlos) fehlt dem Android-Market. Kostenpflichtige Apps, die eine vergleichbare Funktion bereitstellen sollen, gibt es wohl. Für rund 3 Euro. Ob man mit diesen zufrieden ist oder ob die wie gewünscht funktionieren heißt es dann, selber zu testen. Immerhin kann man ja den Kauf binnen 15 Minuten rückgängig machen. Welch Hilfe.

  Skype
  Ich bin noch nicht lange Nutzer von Skype. Aber aus ein paar Gründen hat Skype nun auch bei mir Einzug gehalten, um Videocalls zu machen. Gut, bei einem 3GS nicht sooo sinnvoll, da keine Frontkamera existiert
Um so idealer nun das Android mit einer Rück- und einer Frontkamera. Das müsste doch dann funktionieren…
Und wieder ein “denkste”! Weder kann das Gegenüber gesehen werden noch überträgt man selber ein Bild. Ist wohl auch bekannt, Skype verspricht seit ein paar Monaten, dieses nachzuliefern.
// Update
Mittlerweile gibt es seit dem 30. Juni 2011 auch Videotelefonie per Skype auf dem Android. Das Update lässt sich über die Update-Funktion des Markets installieren. Beim Update wird einem zwar mitgeteilt, dass die Benutzerdaten bestehen bleiben, das scheint aber nicht zu gehen. Skype Name und Passwort waren futsch.
Die Funktion macht das, was sie macht: Videotelefonie. Hierbei kann zwischen der Front- und der Rückkamera umgeschaltet werden. Bildqualität ist OK und hängt natürlich auch von der Gegenseite, der Bandbreite usw. ab. Bisherige Tests zeigen aber, dass es genau so funktioniert, wie es soll. Natürlich wird der Akku bei Nutzung von Videotelefonie gut ausgelutscht. Also eher nur was für eine Nutzung über einen kürzeren Zeitraum bzw. in der Nähe einer Steckdose
Ein Wunder ist geschehen. Skype auf dem iPhone konnte das übrigens schon seit laaanger Zeit.
// Update ENDE

  EyeTV
  In meiner heilen Apple-Welt gibt es neben dem iPhone natürlich noch einen Mac, ausgestattet mit der hervorragenden Software EyeTV von Elgato. Eine MAC-TV Software, die sich ebenfalls per App von remote zur Steuerung nutzen lässt: EPG ansehen, Programmierungen vornehmen, je nach Anbindung auch Live-TV Streaming. Also genau das, was man zwischendurch mal braucht um schnell mal eine Aufnahme anzustoßen, die man zur Programmierung vergessen hat oder um die man gebeten wird.

  Flightradar24 Pro
  Nun kommen wir zu einer App, die ich mir für rund 3 Euro auf dem iPhone gekauft habe: Flightradar24 Pro. Eine ganz nett gemachte und informative App, die einem Flugzeuge auf einer Karte sowie Infos wie Flugroute, Typ, Geschwindigkeit usw. anzeigt. Einfach mal nett für zwischendurch
Diese App kann auch für Android gekauft werden. Nicht aus dem offiziellen Market, lässt sich aber über http://www.androidpit.de/de/android/market/apps/app/com.flightradar24pro/Flightradar24-Pro installieren. Kostet natürlich wieder

    VPN – IPSec – OpenVPN

Und nun zu einem Punkt, der eine richtige Katastrophe ist. Weder kann das Android von Haus aus OpenVPN, noch kann es reines IPSec oder Cisco VPN. Unterstützt wird L2TP/IPSec. Das hilft nicht viel, da beispielsweise FritzBox’en damit nicht umkönnen. Man kann also keine Verbindung per VPN vom Android zur FritzBox hergestellt werden. Einige Dinge kann man halt nur machen, wenn eine VPN Verbindung ins Heimnetzwerk besteht. Sei es Telefonie über die FritzBox, sei es mal schnell auf das FritzNas zugreifen oder Einstellungen der FritzBox ändern (ja, man könnte die Konfigurationsoberfläche für die Welt freigeben -> Sicherheitsproblem!). Nebenbei fühlt man sich doch etwas besser wenn man die VPN Verbindung in fremden Netzen zum Surfen und für Mails nutzt. Ich traue meinem Anbieter zu Hause mehr über den Weg als irgendwelchen (öffentlichen oder auch offenen) WLAN Netzen, die man mal schnell nutzt.
Und das ist mal wirklich richtig Scheiße und ein Showstopper vor dem Herrn!
Im Vergleich dazu das iPhone: Ein leichtes. Wenige Instellungen und das iPhone kann sich mit der vorbereiteten FritzBox verbinden. Warum also nicht auch unter Android? Wieso nehmen die kein normales IPSec sondern verbasteln da noch L2TP? Was soll das?
Ohne VPN fällt der Verwendungszweck des Androiden in vielen Fällen Weg: SIPtelefonie über VPN zur FritzBox ins Festnetz, Surfen über VPN, Zugang zum Heimnetzwerk usw. usf.

    Telefonie über (s)eine FritzBox

In einigen meiner Blogeinträge habe ich schon über die Möglichkeit geschrieben, sein iPhone per VPN an seine FritzBox anzubinden und hierdrüber (z.B. über Adore SIPhone) Telefonate zu führen. Dieses hat den Vorteil, dass man aus quasi jedem WLAN (VPN pass-trough vorausgesetzt) kostenfrei über seine Festnetzleitung zu Hause telefonieren kann. Je nach Anbindung sogar in guter Sprachqualität. Die FritzBox kann (und das ist auch sehr gut so) nicht von außen als Registrar für SIP Clients genutzt werden. Und natürlich möchte man auch nicht, dass das Telefonat ungeschützt und somit einfach mitgeschnitten werden kann.
Ohne VPN fällt diese Möglichkeit leider weg. Und das ist auch wieder ein Punkt, der eine massive Einschränkung der Funktion darstellt. Nicht selten nutze ich dieses um von unterwegs kostenfrei über den eigenen Telefonanschluss zu telefonieren. Abgesichert durch die VPN Verbindung und somit nicht von Fremden im fremden WLAN mitsniffbar zu telefonieren ist schon eine super Geschichte. Aus Hotels, aus dem Urlaub, bei Freunden. Solange man WLAN hat, die Anbindung einigermaßen schnell ist und VPN passtrough erlaubt ist geht das. Wenige Klicks und man kann quasi kostenfrei telefonieren.

    Multimedia – Radio vs. Medienplayer

  Jetzt noch eine Geschichte, die vermutlich in Zusammenhang mit HTC (und deren mitgeliefertem Headset), der Android Version und vll. auch dem Desire S steht. Ich bin, naiv wie ich als Apfeljünger bin, davon ausgegangen, dass der Play/ Pause Button u.U. auch eine Art Mute-Funktion bei beispielsweise Radionutzung darstellt.
FM Radio läuft, man hört Musik über das Headset. Nun möchte man, da sich die Lautstärke mit dem mitgelieferten Headset nicht verstellen lässt, das Radio muten, pausieren oder gar ausschalten. Im Ideal-Wunschfall würde sowas wie Timeshift funktionieren: Das Radio wird nach Betätigung der Pause-Taste aufgenommen und kann dann zeitversetzt wieder mit Play gestartet werden. Dieses muss ja nicht über lange Zeit gehen, ein Speicher von rund 30 Minuten würde reichen.
Noch ein Denkste. Ich habe also die Play/ Pause Taste betätigt. Und zu meiner wundersamen Überraschung fängt der Medienplayer an, noch eine MP3 Datei zu spielen. Natürlich parallel zu dem Radio. Das ist total klasse. Wer denkt sich denn solch einen Scheiß aus? Es gibt ein Audio-Device. Dieses wird von Programm X genutzt. Versucht nun Programm Y dieses Device anzusprechen muss es entweder

• eine Fehlermeldung für Progamm Y geben, da das Device belegt ist oder
• das Radio ausgeschaltet und der MedienPlayer gestartet werden
• oder es kommt eine Abfrage, welches Programm denn nun die Ausgabe nutzen kann/ soll/ darf

Aber mit Sicherheit nicht beide gleichzeitig. Zumal die Lautstärke im Radio leiser war als im MedienPlayer mit der MP3 Wiedergabe. Gibt es keine korrekte Systemlautstärke???

Tolles Multimediaerlebnis. Hier bekommt der Begriff Multi wieder eine ganz neue Dimension.
Gefühlt ist das überhaupt nicht zu ende gedacht, Android ;-(

    Hardwarehandling & -ausstattung

  Nicht nur die Bedienung der Software ist eine Umgewöhnung, auch die Hardware. Ist man vom iPhone noch den Home-Button gewöhnt fehlt dieser gänzlich auf dem Desire S. Daran kann man sich gewöhnen.
Woran ich mich wohl nicht gewöhnen werde, da es einen deutlichen Rückschritt darstellt: Die fehlende Laut-Leise Funktion am Kabel-Headset. Play & Pause sowie Titel vor/ zurück sind dran. Aber keine Möglichkeit, die Lautstärke zu verändern. Das ist ebenfalls total lästig, in der Tasche rumsuchen zu müssen um dann die Lautstärke zu verändern. Angeblich gibt es ein HeadSet von HTC, welches dieses kann (was ja wohl nicht sooo schwer ist). Alle bisherigen Tests mit länger drücken, kürzer drücken und verschiedene Player (FM Radio, Winamp, VLC usw) zeigten das gleiche Verhalten.
Das Headset ist, gelinde gesagt, totaler Müll. Ein Klang wie mit der Butterdose am Bindfaden. Keine Lautstärkeregelung (wobei es eines von HTC geben soll, welches das kann).
Gut, ein iPhone Headset glänzt auch nicht mit ausgewogenem Klang. Aber es ist um Welten besser als das HTC Teil. Beide Kosten den Hersteller in der Produktion wenige Cents. Trotzdem sollte man doch erwarten können, dass ein paar Cent des Gerätepreises über bleiben und das Headset zahlen. HTC, sowas ist scheiße. Muss ich mir nun noch ein brauchbares Gerät kaufen, was vll. noch die Lautstärke regulieren kann???

    Erstes Fazit nach ein paar Tagen

Der erhoffte “Wow-Effekt” ist definitiv ausgeblieben. Es ist eher totale Ernüchterung und vielleicht auch der Anfang eines Endes. Als “Umsteiger” von iPhone zu einem Android ist man sicher nicht gut beraten. Hätte ich vorher noch so ein Kaugummi-Handy à la Nokia 6310 gehabt, dann wäre es sicher ein Quantensprungt geworden. Aber so fühlt man sich von der Bedienung, der Qualität der Hardware und dem Gesamtkonzept doch nicht wirklich überzeugt.
Trotzdem werde ich das Gerät erstmal behalten. Noch habe ich wohl nicht stark genug leiden müssen um aus Verzweiflung das Gerät an die Wand zu werfen

Auf dass noch viele Blogposts über Android und HTC Desire S kommen werden. Bei dem Gerät bzw. OS ist es nur eine Frage der Zeit, bis der nächste Post kommt…

Nun ist aber Schluss mit der Fritz!App. Warum?

Ich habe ja schon beschrieben, wie man sein iPhone mit der App per VPN Tunnel an seine FritzBox anmelden kann um darüber von extern (über das Internet) zu telefonieren.
Leider habe ich nun aus eigener und leidiger Erfahrung selber feststellen dürfen: Die funktioniert einfach nicht, wie sie soll. Nicht, dass sie Sprachqualität nicht ausreichend ist, nein, die hat ganz andere Probleme. Trotz aufgebautem Tunnel meldete sich die App mal an, mal nicht. Mal schnell, mal langsam. Und häufig überhaupt gar nicht. Den Tunnel neu aufbauen und das gleiche Prozedere abermals durchprobieren scheiterte auch meist. Eigentlich rein zufällig meldete sich die App an. Oder halt auch nicht. Ein bestimmtes Verhalten diesbezüglich war nicht zu erkennen. Die Buttons “FritzBox” und “Telefonie” (rechts oben in der App) blieben häufig komplett grau. Weder rot noch grün. Auch ein Klick auf diese brachte einen nicht wirklich weiter. Scheinbar hat die App (warum auch immer) keine Verbindung zur FritzBox herstellen können oder aber auch wollen.

Ich sehe nicht ein, dass ich erstmal ewig hin- und herprobieren muss bis sich die App vielleicht unter Umständen dazu bequemt, mal an der FritzBox anzumelden. Das ist für mich ein Zustand, der absolut nicht tragbar ist. Entweder meldet sich die App direkt an und es geht oder es geht halt aus anderen Gründen (weil z.B. der Tunnel nicht besteht oder Passwort falsch) nicht. Es darf meiner Meinung nach nicht so sein, dass man einen “vielleicht geht’s oder halt auch nicht” Status hat. Zumal ich die Software auch nicht täglich nutze nervt es um so mehr, wenn man diese einmal alle paar Wochen nutzen möchte und dann diesen firlefanz mit hin- und herprobieren über sich ergehen lassen muss bis sich die App vielleicht einmal bequemt, eine Anmeldung durchzuführen. Oder eben auch nicht….

Welche Anforderungen an eine Alternative habe ich? Gibt es Alternativen?

  Es musste nun eine Alternative her, die zuverlässig funktioniert. Doch welche? Was muss eine Alternative erfüllen, um meinen doch eigentlich recht geringen Anforderungen gerecht zu werden? Was für Anforderungen habe ich an solch ein Softphone?

– Zuverlässig
– schnell startend
– gute Sprachqualität
– einfach zu konfigurieren
– kein rumzicken.

Die Vorteile der FritzApp (sofern man diese denn als Vorteil ansieht):
– Man hat mehr oder weniger direkten Zugriff auf die Anruflisten (eingehend, ausgehend, verpasst) der FritzBox
– sieht eigentlich ganz nett aus
– Informationen über die FritzBox FW, IP usw.

Darauf kann ich gut verzichten, denn es gibt neben der schon erwähnten Instabilität noch weitere Nachteile: Das Adressbuch. Wie kommt AVM auf die Idee, dass man nicht das auf dem iPhone befindliche Adressbuch nutzen möchte? Ich pflege doch nicht auf meinem iPhone ein Adressbuch und versuche noch, dieses zusätzlich in der FritzBox aktuell zu halten.

Ist Adore Softphone eine Alternative?

  Adore Softphone ist aus dem App Store kostenfrei zu laden. Die Einrichtung ist schnell und ohne viel Aufwand erledigt. Das Softphone verhält sich, wie man es erwartet: Schnelle Anmeldung. Einfache Bedienung. Gute Sprachqualität. Nutzung des Adressbuches vom iPhone.
Bisherige Nutzungen zeigten keine Probleme. Programm startete jeweils innerhalb kürzester Zeit und die Anmeldung war gleich darauf vorhanden. Das Softphone glänzt nicht mit einer voll durchdesignten GUI, macht aber genau, was es soll.

    Zusammenfassung: Gute Alterantive.

Ist 3cx eine Alternative?

  3CX Phone kennt man vielleicht schon von seinem Rechner, sofern man hier mit Softphones schon gearbeitet hat.
Die Einrichtung ist auch recht übersichtlich gehalten und das Softphone ist schnell angemeldet. Aber leider funktioniert die App nicht immer, wie sie soll. Häufig wollte das Programm nicht starten bzw. brauchte mehrere Anläufe. Zwischendurch ist die App leider auch ein paar Mal einfach gecrasht. Wieso? Nicht ersichtlich, einfach aus und vorbei.

    Zusammenfassung: Leider keine Alterantive.

Fazit

  Die AVM App ist erstmal zur Seite gelegt. Vielleicht wage ich irgendwann noch einmal den Versuch. Vorläufig werde ich bei Adore bleiben. Die macht wenigstens, was sie soll….

Jeder, der sich mit der AVM Fritz!App und dem “Telefonie bleibt rot” Problem oder ähnlichen Phänomenen rumärgert sollte mal über einen Umstieg nachdenken. Es lohnt sich…

  Weil mich dieses Thema die letzten Tage beschäftigt hat. Und wie ich sehen konnte scheint es zum Einen nicht ganz trivial zu sein, zum Anderen wurde ich von jemandem angesprochen, ihm bei der Lösung (s)eines Problems zu helfen.
Gibt man sich also im allumfassenden Netz auf die Suche nach einer hoffentlich brauchbaren und verständlichen Anleitung, die es einem mehr oder weniger Schritt-für-Schritt erklärt, so wird man (zumindest ich) nicht so leicht fündig…. Und damit nun ein für alle Male eine Anleitung brauchbar im Netz verfügbar (und auch für mich nachlesbar ) steht hier die Anleitung, wie man seinen kompletten Internetverkehr über seine FritzBox über einen OpenVPN Tunnel zu einem OpenVPN Server und von dort frei und ungefiltert ins Internet bekommt.
Wozu denn dieses mag man sich fragen? Warum der Aufwand, die FritzBox macht doch Internet ohne Probleme? Was bringt es mir, wenn ich alles noch zusätzlich über den OpenVPN Server laufen lasse, verringert doch unter Umständen die Performance usw.?
Erste Antwort: Weil ich es kann. Zweite und sinnvolllere Antwort ist wohl die, dass es unter Umständen den Bedarf gibt, seine FritzBox nicht direkt mit dem Internet verbinden zu wollen oder zu können. Oder man hat bestimmte Dienste, die es erforderlich machen, über den VPN Tunnel zu gelangen.

  Zweck und Ziel dieses Projekts

  Dieser Blogpost ist dazu gedacht, seine FritzBox in der Art und Weise abzuändern, dass der gesamte Internetverkehr über einen VPN Tunnel zum OpenVPN Tunnel Endpunkt geroutet wird. Hier findet kein split-tunneling statt, alles soll durch den Tunnel geroutet werden. Alle Datenpakete, die die FritzBox verlassen sind verschlüsselt und kennen nur den einen Weg: Über den OpevnVPN Tunnel zum Server. Keine unverschlüsselten Datenpakete sollen außerhalb des Tunnels vorbei gehen (können).

  Ein Beispiel für einen möglichen Einsatzzweck

  Ein Beispiel wäre, wenn man seinen Internetanschluss in der FritzBox mit Lan1 (also das DSL Modem abschaltet und nicht nutzt) konfiguriert hat und dieser LAN1 Anschluss in einem von anderen Personen administrierten Netzwerk hängt. Dieses Netzwerk vergibt statisch oder dynamisch IP Adressen über Ethernet, die FritzBox routet alles aus dem internen Netzwerk der FritzBox an diesen LAN Port. Über diesen Netzwerkanschluss wird also der komplette Internetzugang realisiert. ohne viel Einfluss auf den Verlauf des Datenverkehrs haben zu können. Die Kontrolle, was unter Umständen in diesem Netzwerk geblockt, mitgelesen oder sonstwie verhindert wird obliegt also nicht dem eigenen Einfluss. Man muss sich also immer überlegen, wie viel Vertrauen man seinem Netzwerkadministrator entgegen bringt.
Es kann ebenfalls sein, dass in diesem fremdadministrierten Netzwerk verschiedene Dienste blockiert werden: Telefonie über VoIP, Webseiten müssen über einen Zwangs-Proxy aufgerufen werden, Mail geht nicht, SSH in die weite Welt ist unterbunden. Vielleicht der Einzige (und nicht gefilterte Dienst) ist VPN und kann für den Zugriff in die weite Welt genutzt werden. Ist auch dieses etwas erschwert (da die Netzadministratoren ja mitunter nicht ganz doof sind) und verschiedene bekannte und üblicherweise genutzte Ports sind blockiert, so muss man sich noch einen weiteren Trick zur Umgehung dieser Hürde einfallen lassen.

Eine andere Idee: Man möchte auf der FritzBox (s)einen VoIP Provider für die Telefonie nutzen. Angeschlossen ist die FritzBox ebenfalls über ein nicht vertrauenswürdiges Netz. Alle Sprachdaten würden/ könnten mitgelesen bzw. abgehört werden. Traut man nun seinem Netzanbieter, über den der VPN Server angeschlossen ist mehr als seinem Netzlieferant der FritzBox-Internetanbindung, so macht auch hier wieder ein Tunnel Sinn.
Möglichkeiten und Einsatzzwecke gibt es also zur Genüge. HomeOffice, Standortvernetzung usw. sind ebenfalls denkbar.

Selbstverständlich kann die FritzBox bei dem nachfolgenden Aufbau auch ganz normal über das eingebaute ADSL Modem über einen ADSL Anschluss mit seinem Internetserviceprovider verbunden sein. Das bleibt sich schlussendlich gleich und ändert in der Anleitung nichts.

  Voraussetzungen

  Wie schon bei meinen anderen Blogposts mit OpenVPN setze ich hier eine funktionsfähige Installation und (Grund)Kenntnisse bei der Konfiguration und Einrichtung von OpenVPN voraus. Ein funktionsfähiger OpenVPN Server ist für die Einrichtung Grundvoraussetzung. Sollte der nicht eingerichtet sein bzw. die FritzBox noch nicht als OpenVPN Client konfiguriert sein, so sollte dieses in meinem Blogpost http://www.rotzoll.net/2010/04/fritzbox-7270-als-openvpn-client/ nachgelesen und entsprechend eingerichtet werden. Ein Zugriff auf die Konfigurationsdatei des OpenVPN Servers (um beispielsweise das LogLevel zum Debuggen zu erhöhen) ist ebenfalls erforderlich.
Ebenfalls sind Linux und im späteren Verlauf IPtables Kenntnisse erforderlich.

Die angesprochenen Konfigurationsschritte beziehen sich auf AVM FritzBox 7390′er und 7270′er, die als OpenVPN Client erweitert wurden. Sicherlich sind die angegebenen Konfigurationsschritte und Beispiele auch auf andere FritzBoxen übertragbar und lassen sich dort ebenfalls abbilden.

Da es bei der Einrichtung auch an das Routing zwischen der FritzBox und der OpenVPN Server geht, ist es sinnvoll, noch einen zweiten Internetzugang für “den Fall der Fälle” zu haben. Also über UMTS oder ähnlich noch ein zweiter Weg im Notfall, sollte man das Routing fehlerhaft verstellt haben oder aus sonstwelchen Gründen nicht mehr an den OpenVPN Server kommen. Es hilft, sich vorher Gedanken über Plan B zu machen.
Und nicht erst, wenn man sein Routing zerstört und keinen Zugriff mehr auf den OpenVPN Server hat

  Begrifflichkeiten und Netzwerke

  In der nachfolgenden Beschreibung gehe ich von folgenden Begrifflichkeiten aus:

• Der OpenVPN Server ist über eine offizielle IP Adresse 20.30.40.50 erreichbar
• Das Netzwerkinterface am Server Richtung Internet heißt eth0
• Das VPN Netzwerkinterface heißt tun0
• IP Netz für die VPN Client: 10.1.2.0/24
• IP Netz für die Clients hinter der FritzBox: 192.168.178.0/24

Alles sind natürlich nur Beispieldaten und müssen, je nach eigener Konstellation angepasst, werden.
Ebenfalls werden die Aufrufe auf dem OpenVPN Server als root ausgeführt. Natürlich kann auch mit sudo gearbeitet werden. Der Einfachheit halber habe ich aber in der Beschreibung darauf verzichtet. Wenn mit sudo gearbeitet wird, so ist vor die Aufrufe sudo vorzusetzen. Das erklärt sich aber sicher von selbst….

Telnet zur FritzBox

  Voraussetzung für die Konfiguration der FritzBox ist, dass der Zugriff per Telnet auf diese aktiviert ist. Auf dem konfigurierenden Rechner ist ein Programm zur Nutzung von Telnet installiert und kann ausgeführt werden (Linux/ Mac Nutzer: Terminal öffnen und telnet IP_der_FritzBox eingeben; Windows Nutzer: Putty starten, als Verbindungstyp telnet auswählen, IP_der_FritzBox eingeben; Loginpasswort ist das normale Webpasswort).
Eine Verbindung von seinem Rechner zur FritzBox per Telnet ist nachfolgend immer dann nötig, wenn Änderungen/ Anpassungen auf dieser beschrieben werden. In meinen Beispielen ist dieses ebenfalls zu erkennen an der Bezeichnung der Konsolenausgabe.

Ganz wichtig: Man sollte die komplette Einrichtung natürlich nur aus dem lokalen Netzwerk vornehmen. Meint man, dass man dieses auch von remote einrichten kann, so könnte wird man sich ganz schnell den Ast absägen, auf dem man sitzt. Es geht natürlich auch, dann darf man sich allerdings beim Löschen der Default-Route nicht an die von mir angegebene Reihenfolge halten und muss erst die Host-Route zum OpenVPN Host setzen eh man die Default-Route löscht.
Ebenfalls kann es sein, dass man die FritzBox neu starten möchte. Dann hilft es, wenn man diese in Zugriff hat

  Routing des kompletten Datenverkehrs in den Tunnel hinein

Der VPN Tunnel kann aufgebaut werden und der Tunnel steht. Von der FritzBox kann ein Ping auf die IP des VPN Tunnelendpunktes (die interne VPN IP Adresse des OpenVPN Servers) gemacht werden, Pakete werden beantwortet. Wenn dieses erfüllt ist, beenden wir erstmal den OpenVPN Client auf der FritzBox durch ein kill der Prozess-ID:

telnet:~ fritzBox$ # ps | grep openvpn
1234 root 2072 S /var/media/ftp/DEVICENAME/vpn/openvpn –config openvpnclient.conf –daemon
(Man erhält die Ausgabe zu dem openvpn Dienst. Die Prozess ID ist die este Spalte, in diesem Beispiel also 1234.)

Durch einen Aufruf auf der Konsole der FritzBox von

telnet:~ fritzBox$ # kill 1234

wird der Prozess auf der FritzBox beendet. Der Prozess wird beendet und das Tunneldevice tun0 sollte nicht mehr vorhanden sein (Test mit: ifconfig tun0).

Nun soll das Routing des Datenverkehrs soweit abgeändert werden, dass der gesamte Datenverkehr nicht mehr seinen “normalen” Weg ins Internet geht sondern über den VPN Tunnel geroutet wird.
Auf der Fritzbox muss hierzu das Default-Gateway (normalerweise also die Anbindung ans Internet und namentlich als Device dsl in der Routingtabelle) gelöscht werden. Danach wird eine einzelne Host-Route angelegt, die die IP Adresse des OpenVPN Servers auf das “Internetdevice” routet. Nachdem der OpenVPN Tunnel aufgebaut wurde wird der gesamte Internetverkehr über das Tunnel-Device tun0 als Default-Gateway geroutet:

Wir löschen auf der FritzBox das default Gateway, welches uns mit netstat angezeigt wird und als Route für das Ziel 0.0.0.0 definiert ist:

telnet:~ fritzBox$ # netstat -nr
Destination     Gateway     Genmask     Flags MSS Window irtt Iface
0.0.0.0     0.0.0.0     0.0.0.0     U     0 0     0 dsl
telnet:~ fritzBox$ # route del default dev dsl
(Das Default-GW wird gelöscht.)

Nun wurde das Default-GW aus der Routingtabelle der FritzBox gelöscht. Würden wir nun versuchen, den OpenVPN Client zu starten hätte dieser keine Möglichkeit, den OpenVPN Host zu erreichen. Also setzen wir eine Host-Route für die IP des OpenVPN Servers auf das Device dsl:

telnet:~ fritzBox$ # route add -host 20.30.40.50 dev dsl
(Routing auf die IP Adresse des VPN Servers über das Device dsl.)

Hiernach kann der OpenVPN Client auf der FritzBox wieder gestartet werden, das Ziel ist über die Hostroute erreichbar und der Client kann sich gegen den Host connecten. Ist der Tunnel erfolgreich initialisiert (Prüfung im Log des VPN Servers und des Clients hilft hier bei etwaigen Problemen sehr…), so erscheint das Netzwerkdevice tun0 auf der FritzBox:

telnet:~ fritzBox$ # ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.2.22 P-t-P:10.1.2.21 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:379 errors:0 dropped:0 overruns:0 frame:0
TX packets:218 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3690 (3.7 MiB) TX bytes:1744 (1.7 MiB)

Nun ist der OpenVPN Server über den VPN Tunnel erreichbar. Allerdings soll ja der gesamte Internetdatenverkehr über diesen Tunnel geroutet werden. Also setzen wir einen Default-Gateway Eintrag auf dieses Device:

telnet:~ fritzBox$ # route add -net 0.0.0.0/0 dev tun0
(Das Default-GW wird auf das VPN Device tun0 gelegt.)

Die Routingtabelle über netstat -nr zeigt nun auf, dass wir eine Hostroute haben, ein default-GW und natürlich die normalen Netzrouten-Einträge für das OpenVPN Netz.

  Aktivierung als Gateway

  Vermutlich wird der OpenVPN Server noch nicht als Gateway dienen. Vielleicht hat dieser ein “externes” Interface für das Internet, auf ihm laufen vll. noch ein paar Internetdienste (HTTPd usw.) und noch der OpenVPN Serverdienst. Bisher wurde der Server noch nicht als Router (Gateway für verschiedene Netze) genutzt.
Es fehlt somit die Einrichtung, dass zwischen den Netzen geroutet werden soll. Hierzu muss eine Option im Kernel gesetzt sein, die das Routing zwischen den Netzen steuert. Als Werte gibt es 0 (keine Gatewayfunktion) oder 1 (es wird geroutet). Wir prüfen ersteinmal, ob der Kernelwert schon gesetzt ist:

OpenVPNserver$ # cat /proc/sys/net/ipv4/ip_forward
0
(Hier wäre das Routing zwischen den Netzen deaktiviert.)

Ist der Wert auf 1, so kann der nachfolgende Aufruf gespart werden. Andernfalls muss der Wert von 0 auf 1 geändert werden:

OpenVPNserver$ # echo 1 > /proc/sys/net/ipv4/ip_forward
(Aktiviert das Routing zwischen den Netzen.)

Nun wird zwischen den unterschiedlichen Netzen (z.B. eth0 für das externe Interface und tun0 für das VPN Netz) geroutet. Dieses sollte ebenfalls reboot-save gemacht und bei Ubuntu in die Datei /etc/sysctl.conf eingetragen werden bzw. der Wert muss auf 1 gesetzt werden. Die Zeile wird schon in der Datei vorhanden, aber unter Umständen mit einem ‘#’ Zeichen “deaktiviert” sein. Das Raute-Zeichen muss entfernt werden und die Zeile wie folgt in drinstehen:

net.ipv4.ip_forward = 1
(Aktiviert das Routing zwischen den Netzen.)

Nun sollte das Routing prinzipiell erlaubt sein und funktionieren. Man kann durch den obigen Aufruf abermals prüfen, ob der Kernel nun mit dem Wert versehen ist und erhält statt ’0′ nun eine ’1′.

  Anpassung der IPtables Regeln auf dem OpenVPN Server

  Auf dem OpenVPN Server müssen, wenn hierzu IPtables genutzt wird, Regeln erstellt werden, die das Masquerading und “Weiterleiten” der Pakete erlaubt. Wird statt IPtables IPchains genutzt, so muss dieses eigenständig nachgeschlagen werden. Es wird aber ähnlich ablaufen…

Die nachfolgenden Regeln richten NAT (Network-Adress-Translation) zwischen dem OpenVPN Interface tun0 und dem externen Netzwerkinterface eth0 ein. Wer die genaueren Aktionen verstehen will, der sollte sich einmal die Grundlagen von IPtables ansehen. Hier werde ich nicht näher auf die einzelnen Optionen eingehen und die Aufrufe erläutern sondern gebe diese als gegeben an. Auf der Konsole werden die Zeilen nacheinander eingegeben (oder, sofern man ein IPtables Regelwerk schon hat, in dieses eingebaut):

OpenVPNserver$ # iptables -I FORWARD -i tun0 -j ACCEPT
OpenVPNserver$ # iptables -I FORWARD -o tun0 -j ACCEPT
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o eth0 -s 10.1.2.0/24 -j MASQUERADE
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o eth0 -s 192.168.178.0/24 -j MASQUERADE
OpenVPNserver$ # iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
(In Kurzform: Pakete auf dem tun0 Interface werden erlaubt und das OpenVPN/ FritzBox Netz ge’nat’net.)

Natürlich kann man obige Aufrufe noch seinen eigenen Bedürfnissen anpassen oder erweitern. NAT sollte vollkommen ausreichend sein, da zusätzlich noch auf der FritzBox ge’nat’net wird. Also ein DoppelNAT
Reicht einem dieses aus eigenem Sicherheitsempfinden nicht, so kann auch über einzelne Portregeln (z.B. nur HTTP Port 80, 443 und DNS auf vorgegebene DNS Server) der ausgehende Verkehr ins Internet eingeschränkt werden. Das wäre aber nicht sinnvoll, da wir ja auf der FritzBox noch ein paar andere Dienste (VoIP usw.) nutzen wollen und uns das Leben somit unnötig kompliziert machen würden.

  Sind obige Regeln aktiviert, so sollte von der FritzBox ein Ping in die Weite Welt erfolgreich durchgeführt werden können. Dieses kann auf dem OpenVPN Server durch einen TCPdump geprüft werden. Hier werden nun Pakete ein- und ausgehend auf dem Interface tun0 laufen. Aber nicht nur von der FritzBox direkt, auch von einem angeschlossenen Rechner sollte das nun möglich sein, sofern dieser die FritzBox als Default-GW hat.
  IP Pakete laufen nun vom PC zur FB, dort in den VPN Tunnel, gehen verschlüsselt durch den Tunnel über die “Internet”anbindung (ob nun DSL oder LAN->Internet) zum OpenVPN Server, werden entschlüsselt und gehen von dort ins Internet. Ruft man eine Seite zur Ausgabe seiner derzeitigen IP Adresse auf (z.B. http://checkip.dyndns.org oder http://www.wieistmeineip.de), so wird einem die öffentliche IP des OpenVPN Servers angezeigt.
Bingo. Ziel quasi erreicht

  Prüfung, ob der Datenverkehr auf dem OpenVPN Host aus dem Tunnel ankommt

Der Datenverkehr wird nun durch die FritzBox in den Tunnel geschickt und kommt auf dem OpenVPN Server an. Kommt der das wirklich über den Tunnel?
Wenn man beim Routing einfach mal sehen möchte, was die obigen Regeln erlauben, so kann man mit TCPdump vor und während des Aufrufs die Pakete mitlesen.

Wir überprüfen dieses durch einen tcpdump auf dem OpenVPN Host:

OpenVPNserver$ # tcpdump -i tun0 -vvv

Auf dem Rechner im FritzBox-Netz rufen wir nun beispielsweise die Seite http://www.google.com auf. Wie im tcpdump nun einfach zu sehen sein sollte kommuniziert der über den VPN Tunnel angeschlossene Host mit der IP 192.168.178.X mit dem externen Server www.google.com. Wir sehen Pakete, die aus dem Tunnel ins Internet und umgekehrt beantwortet wieder in den Tunnel gehen.

  Konfiguration reboot-save machen

  Wenn obige Schritte erfolgreich durchgeführt wurden und alles funktioniert, so kann bzw. sollte man dieses alles reboot save machen. Schließlich sollen die Änderungen sowohl nach einem restart der FritzBox als auch des OpenVPN Servers wieder funktionieren.
Auf dem OpenVPN Server
Die Einstellungen für IPtables sollte man in einem Skript (wo sicherlich schon ein paar andere Einträge für IPtables stehen) einfügen. Dieses wird beim Booten ausfgeführt. Alternativ sollte man ein Startskript erstellen oder den Aufruf von IPtables in ein anderes mit einfügen.
Eine andere sehr schöne Variante ist die Nutzung der up und down Befehle in der server.conf des OpenVPN Servers. Hiermit können Skripte angegeben werden, die beim Start eines Tunneldevices (tun0) bzw. Stop ausgeführt werden. Damit kann man die IPtables Regeln automatisch setzen wenn der OpenVPN Server startet und ebenfalls diese Regeln wieder löschen (wenn man das möchte).
Hierzu müssen folgende Zeilen in die server.conf eingefügt werden:

script-security 2
up "./tun_up.sh"
down "./tun_down.sh"


Das Setzen von script-security auf ’2′ erlaubt es, alle Arten von (User)Skripten auszuführen. Die Angabe bei up und down verweist auf die Skripte, die beim Hochnehmen oder Herunternehmen des Interfaces ausgeführt werden. Das UP Skript beinhaltet eigentlich nur die IPtables Regeln, die wir vorhin schon händisch aufgerufen haben:


#!/bin/sh
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.2.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.178.0/24 -j MASQUERADE


Wenn das Skript erstellt wurde muss dieses ausführbar gemacht werden:


OpenVPNserver$ # chmod 755 tun_up.sh


Ein Neustart des OpenVPNd liest die Konfiguration komplett neu ein, das Skript wird nun passend gestartet.

Auf der FritzBox
Das Startskript zur Ausführung des OpenVPN Clients funktioniert und existiert schon aus meinem früheren Blogpost.
In dieses Skript könnte man nun die für die FritzBox nötigen Änderungen einfließen lassen und dieses anpassen. Nach dem Aufbau des Tunnels durch den Start des OpenVPN Clients auf der FritzBox bauen wir eine kurze Pause ein, bis der Tunnelendpunkt angepingt werden kann. Danach ändern wir die Routingeinträge ab und fertig. An das bisherige Skript startup.sh zum Start des VPN Clients hängen wir noch folgende Zeilen an:


# Ans Ende der startup.sh anfuegen.....
# Warten, bis der Tunnel steht
echo Waiting for VPN Tunnel connection
while !(ping -c 1 10.1.2.1); do
echo Tunnel noch nicht gestartet
echo
sleep 5
done

#Aendern der Route zum OpenVPN Server
route add -host 20.30.40.50 dev dsl
sleep 2
# Aenderung des Default-Gateway
route del default dev dsl
sleep 3
route add -net 0.0.0.0/0 dev tun0

echo Routing zum VPN Server aktiviert
# # # # ENDE # # # #


Wird dieses mit in die startup.sh eingefügt, so wird nach dem Start des OpenVPN Tunnels automatisch das Default-Gateway auf den VPN Tunnel gesetzt. Aller Traffic aus dem internen “FritzBox Netz” geht über die FritzBox in den VPN Tunnel und über diesen zum OpenVPN Server. Auf diesem

  auftretende Probleme

Die wohl häufigsten auftretenden Probleme sind, dass vom OpenVPN Server die aus dem OpenVPN Tunnel kommenden Datenpakete nicht richtig geroutet und auf das dortige Default-Gateway (Anbindung ans Internet) gelangen. IPtables ist hierfür verantwortlich und muss richtig konfiguriert werden. Sehr hilfreich ist es, wenn man sich auf dem OpenVPN Server mit TCPdump die Datenpakete ansieht, die dort ankommen. Anhand dessen erkennt man schon recht schnell, in welche Richtung die Pakete gehen bzw. dass die Antwortpakete ausbleiben. Sieht man auf dem Server schon gar keine Pakete mit IP Adressen aus dem privaten IP Adressbereich der FritzBox bzw. die VPN IP Adresse der FritzBox selbst, so funktioniert das Routing von der FritzBox in den Tunnel nicht richtig. Mindestens sollte man diese unterschiedlichen Pakete sehen, die dann vom OpenVPN Server geroutet werden müssen.

Ein weiteres Manko fällt bei IPtables auf: Man kann die Regeln nicht auf virtuelle Interface (z.B. eth0:1) beziehen. Hat man also virtuell eine zweite IP Adresse auf dem VPN Server, die für die ausgehende Kommunikation aus dem FritzBox-Netz genutzt werden soll, so kann IPtables mit den Regeln ... -o eth0:1 nichts anfangen und verweigert die Aufnahme dieser Regel. Schade eigentlich.

  Disclaimer/ Haftungsausschluss

Wie immer gilt auch hier: ALLES geschieht auf eigene Verantwortung! Ich übernehme für keine Probleme oder Folgen irgendeine Gewähr, keine Garantie oder sonstige Verantwortung. Jede Änderungen und Anpassungen, Ausführung oder/ und Aufruf irgendwelcher Befehle/ Skripte sollte wohl überlegt und verstanden sein.
Das Umgehen von Sicherheitsmaßnahmen (Sperrung von Ports/ bestimmten Diensten; Umgehung von Zwangsproxys usw.) sollte wohl überlegt sein. Schließlich gibt es durch die Netzbetreuer gute Gründe, warum das so ist. Oder die Anbieter haben im Kleingedruckten die Nutzung bestimmter Dienste untersagt und filtern auf den Core Routern diese Dienste heraus, verlangsamen oder behindern diese.

Jeder ist für sein Handeln selbst verantwortlich. Da mit IPtables & Co. schnell Fehler in der Konfiguration gemacht werden können sollte man sich schon etwas damit auskennen. Unbedachtes Handeln kann ungewünschte Ergebnisse/ Folgen nach sich ziehen.

• direkter Anschluss an analoge oder ISDN Anschlüsse durch eingebauten DSL Splitter
• Anschluss von analogen Telefonen über TAE
• interner ISDN S0 Mehrgeräteanschluss über RJ45 oder Klemmleiste
• WLAN nach 802.11b/g/n mit WPS, WPA2 und dem unsicheren WEP
• Anschluss von USB Speicher, Drucker oder UMTS Stickt
• WLAN über einen Schalter ausschaltbar
• 4 LAN Ports für den Anschluss ans lokale Netzwerk
• SIP Telefonie für verschiedene VoIP Provider
• Telefonanlagenfunktion

In den Grundzügen sind die FritzBox 7270 und EasyBox 802 vergleichbar. Keine der beiden watet mit speziellen Hardware-Merkmalen (ausgenommen die DECT Funktion in der FritzBox) auf. Ich glaube daher, dass man den Vergleich wagen kann. AVM ist sicherlich der bekanntere Hersteller als Astoria Networks (Hardwarelieferant der EasyBox 802).

Was fällt bei der EasyBox 802 positiv auf?

Die EasyBox (EB) bietet einige Funktionen an, die die FritzBox nicht hat. Ob man diese nun braucht oder nicht, sei dahingestellt. Ich betrachte es erstmal als interessant, was man anders/ mehr mit der EB als der FB machen kann.

• Remote-Management auf eine feste IP Adresse einstellbar: Ideal, wenn man von einer festen, externen IP Adresse auf die Box zugreifen und Konfigurationsänderungen machen möchte.
• Filterregeln: Bestimmte Dienste (HTTP, Mail, FTP, NetMeeting usw. oder auch eigene Definition) können explizit erlaubt oder verboten werden. Hierzu können Zeitpläne erstellt und bestimmten Clients zugeordnet werden. Damit kann z.B. allen Clients das Surfen zu bestimmten Uhrzeiten erlaubt oder verboten werden.
• URL Blacklisting: Interessant, um z.B. den Zugang für seine Kinder ein wenig zu filtern. Bestimmten Rechnern kann eine Filterregel zugeordnet werden. Innerhalb dieser Filterregel lässt sich beispielsweise der Zugriff auf Domains mit dem enthaltenen Begriff ‘ebay’ blockieren. Ein Aufruf von www.debayernserverbeispiel.de und ebenfalls www.ebay.de würden mit einem Hinweis abgewiesen werden.
• 3 USB Anschlüsse: 2 USB Ports für Drucker, USB Speicher (Sticks, HDDs) und ein USB Port für einen UMTS Stick
• Klemmleiste für ISDN Verkabelung: Über die Klemmleiste kann die Hausverkabelung (ISDN Bus) direkt hart verdrahtet angeschlossen werdne.
• Durchdachteres Gehäusedesign: Die Box ist so konzipiert, dass Sie hochkant flach zur Wand oder auf einer Fläche positioniert werden kann. Hierzu werden sowohl Fuß als auch Wandhalterung mitgeliefert. Auf der Rückseite sind alle Anschlüsse gut angebracht und können gut erreicht werden. Ein USB Anschluss ist auch bei Wandmontage von der Seite zu erreichen, der UMTS-USB Anschlussport (oben) kann bei geöffneter Klappe mit dem Stick versehen werden.
• Eingebaute Antenne: Ob nun ein Vor- oder Nachteil (im Empfang sicherlich messbar) ist die integrierte Antenne. Keine störenden Stummel-Antennen stehen wie bei der FB von der Rückseite hoch.
• SNMP Management: Die EB kann per SNMP überwacht werden. Interessant, wenn man seinen Anschluss und die Box monitoren möchte.
• Firewall/ IDS: Die EB bietet ein Intrusion-Detection-System. Gut, wohl eher einfachster Natur. Trotzdem kann man sich über eMail informieren lassen, wenn die Box meint etwas erkannt zu haben.
• Einstellbarkeit: Die EB bietet einige Einstellungen für Priorisierung über QoS, TCP Verbindungen, Filterregeln, Port-Forwarding, SNMP, Zeitpläne für WLAN usw. an.
• Schnelle Einstellung einer Nur-UMTS-Verbindung: Die Box kann in wenigen Schritten als UMTS-Router konfiguriert werden. Das eigene Netz erhält dann statt über DSL die Internetverbindung über UMTS.

Die Einstellungen sind meist mit kleinen Beschreibungen erklärt und lassen sich seinen eigenen Wünschen anpassen. Auf das Handbuch kann man bei den meisten Punkten komplett verzichten. Hauptsache, man macht erstmal den Expertenmodus an, dann macht es auch mehr Laune

Was fällt bei der EasyBox 802 negativ auf? Welche Probleme stellt man direkt fest?

• Firmware-Update: Die Vodafone Easybox kann mit einer Firmwaredatei aktualisiert werden. Über die Konfigurationsoberfläche kann eine bei http://www.dsl-easybox.de herunterladbare und lokal auf dem Rechner gespeicherte Firmware-Datei ausgewählt oder über eine bestehende Internetverbindung in die Box geladen werden. Der sichere Weg ist natürlich die Auswahl einer schon heruntergeladenen Datei.
  Leider gibt es Probleme mit dem Google Chrome Browser. Trotz korrekter Datei behauptet das Konfigurationsmenü immer, dass ein “falsches Dateiformat” ausgewählt wurde. Nimmt man schnell den Firefox zur Hand lädt die gleiche Datei korrekt in die Box.
• DLNA Unterstützung: Vodafone schreibt, dass nach Aktualisierung der Bootloaderversion von 1.00.01 auf 1.00.02 die Einspielung einer Firmware möglich ist, die DLNA (Digital Living Network Alliance) unterstützt. Eigentlich gut beschrieben soll man die reset Taste gedrückt halten während man das Netzteil einsteckt. Danach noch rund 5 Sekunden gedrückt halten startet die recovery-Firmware auf der EB. Über diese lässt sich dann der Bootloader aktualisieren.
  Leider aber wohl nicht überall. Bei mir ist es nicht möglich. Google wirft hier auch Ergebnisse anderer heraus, die das gleiche Problem haben. Kaufe ich mir nämlich genau aus diesem Grunde diese Box, um z.B. meinen Fernseher mit DLNA Inhalten zu versorgen, so wäre dieses ein Manko. Da müssen die wohl auch noch mal ran. Scheint also noch ein verstecktes “Feature” zu sein, welches in einer der kommenden Versionen hoffentlich gefixt wird…
• Firmware-Pflege: Die Firmware der EB wird augenscheinlich nicht wirklich aktiv (aktuelle Nicht-DLNA Firmware Version: 20.02.223 (26.03.2010-15:31:20)) entwickelt. Nur selten kommen neue Funktionen hinzu. Man kann darauf hoffen, dass demnächst mal wieder ein Update erscheint und neue Funktionen einfließen.

Wahrscheinlich werden nun nach und nach noch weitere Dinge auffallen, die sich in nähergehender Betrachtung und weiterer Nutzung ergeben.

Was fehlt der EasyBox 802 an Funktionen?

Sicherlich gibt es immer Dinge, die einem fehlen. Ob man die nun braucht oder nicht sie dahingestellt. Hier aber mal ein paar Funktionen, die mir persönlich fehlen:

• Anrufbeantworter: Wie ich finde eine echt super Geschichte bei der FB ist der eingebaute Anrufbeantworter. Nachrichten können auf einem angeschlossenen USB Speicher gespeichert und per eMail direkt an eine voreingestellte Adresse geschickt werden. Das fehlt hier leider gänzlich. Man kann zwar einen AB anschließen, aber wozu bitte dieses extra Gerät?
• Faxempfang: Auch hier hat die FB die Nase vorn. Der eingebaute Faxempfang ist auch ein Pluspunkt. Faxe können auf einem angeschlossenen USB Speicher gespeichert und per eMail verschickt werden.
• DECT: Wieder eine Funktion der FB, die hier fehlt. Man kann keine DECT Geräte an der Box anmelden.
• OpenVPN/ IPSecVPN Server: Nicht mal über “Hacks” ist es derzeit möglich, die Box mit einer VPN Funktion zu erweitern. Weder kann die Box selber als VPN Server für IPSec (z.B. zur Anbindung von Laptop, iPhone & Co. von unterwegs) noch OpenVPN dienen. Das wäre schon sehr wünschenswert, um von unterwegs eine gesicherte Verbindung zu seinem Heimnetz aufbauen zu können.
• OpenVPN Client: Ebenfalls fehlt der Box die Möglichkeit, diese als Client an einen VPN Server anzumelden und Routen “komplettes Netzwerk”/ “bestimmte Routen” auf den VPN-Tunnelendpunkt zu setzen.
• LAN-LAN-Kopplung: Da auch schon die zwei oberen Punkte nicht möglich sind, ist auch dieses fehlend.
• SIP Registrar: Die EB kann zwar selber als SIP Client bei verschiedenen SIP Providern (Sipgate & Co.) angemeldet werden, kann selber aber leider nicht als SIP Registrar fungieren. Somit können beispielsweise keine SIP Telefone/ Softphones im Netzwerk an der Box angemeldet und wie normale analoge oder ISDN Telefone genutzt werden.
• Vielleicht habe ich es bisher einfach übersehen oder die Box bietet nicht die Möglichkeit, die Verbindung über ein externes DSL Modem herzustellen? Ebenfalls scheint zu fehlen, dass die Box eine feste IP Adresse auf einem LAN Port erhält und hierdrüber die Internetverbindung bereit stellt. Vll. auch bei Leuten interessant, die in WGs wohnen und den eigenen Rechner noch einmal mit einem Router davor etwas “absichern” wollen.
• Statusmails: Ich kann leider keine täglichen Statusberichte über Anrufe, DSL Verbindung usw. automatisiert verschicken lassen.
• Anruffilter: Gaaanz großes Manko ;-( Wieso kann ich nicht bestimmte Rufnummern (nervende Callcenter) direkt ins Nirvana schicken? Oder Anrufsperren zu bestimmten Uhrzeiten einrichten? Anrufe unbekannter Anrufe auflegen? Da muss nachgearbeitet werden.

Einige Funktionen (Faxempfang, Anrufbeantworter, VPN, Anruffilter) könnten vll. doch noch mal in einer der kommenden Softwareversionen kommen. Andere Dinge (z.B. DECT) werden nicht über Updates kommen können. Auch das “Nachfolgemodell” EasyBox 803 bietet noch kein integriertes DECT an. Wünschenswert wäre dieses ja. Hardwaretechnisch ließe sich dort sicherlich noch einiges verbessern. Ebenfalls wäre der Umstieg auf GigaBit sicher nicht die schlechteste Idee.

Fazit

Ich bin positiv überrascht! Der Funktionsumfang ist für das Geld sehr gut und für den Großteil der Nutzer sicherlich vollkommen ausreichend. Die Konfigurationsoberfläche mag an einigen Stellen verbesserungsfähig (mein esthätisches Empfinden ist da nicht sooo anspruchsvoll) sein, ist aber nach etwas Einarbeitung gut zu bedienen. Einige Einstellungen könnten in der Oberfläche AJAX-dynamischer (z.B. bei den statischen Listen für Filterregeln und so weiter) sein.

Wirklich super wäre es, wenn man noch Funktionen wie OpenVPN/ IPSec, Anrufbeantworter, Anruffilter (“Blackliste”) und Faxempfang in der Box integriert hätte. Dann wäre diese Hardware derzeit eine wirklich gute und vor allem günstigere Alternative zu (m)einer FritzBox. Auf DECT kann ich persönlich derzeit verzichten, da mein ISDN Telefon gleichzeitig DECT Basis ist. Aber für die Überbrückungszeit (z.B. bei einem Defekt der FritzBox) wäre die Box eine gute Zwischenlösung.

Wie die VPN Verbindung inklusive des Routings vom VPN Client in die weite Welt (das Beispiel von AVM verbietet leider dem Client den Zugriff in die weite Welt) einzurichten ist, habe ich ja schon ausführlich beschrieben.

Ebenfalls klärt sich damit, wer das DNS Problem verursacht hatte. Wie ja die ganze Zeit quasi fest stand, war die Ursache bei der IPsec VPN Implementierung bei AVM. AVM hat hier zwar auf Apple verwiesen und sich aus der Affäre ziehen wollen, aber richtig war die Aussage natürlich nicht.

Nach Monaten bleiben nun noch ein paar Fragen offen:

• Warum verweist AVM auf Apple, ohne sich der Sache weiter annehmen zu wollen (und sich vll. in Kombination mit einem Nutzer eine Lösung zu erarbeiten)?
• Warum verweist AVM auch bei den Routingproblemen (von AVM vorgegebene Datei verbietet Verbindungen in die weite Welt) auf Apple?
• Warum sagt AVM, dass ein Routing vom VPN Client in die weite Welt gar nicht vorgesehen ist und gar nicht funktionieren kann?

Immerhin kann ich es mir nun ersparen, einen weiteren IPsec Endpunkt aufzusetzen, mich mit meinem iPhone gegen diesen zu verbinden und das ganze weiter zu analysieren. Spart mir dann doch noch etwas Zeit und Nerven

// UPDATE 17.11.2010 //
Auf Grund vieler Nachfragen:
Wenn Apple-iPhone Nutzer versuchen sollten, per SIP/ AVM Fritz-Software telefonieren zu wollen und das klappt nicht (Telefonie-Symbol bleibt rot…), stellt bitte nicht fritz.box als Registrar ein!
Hier muss immer die IP Adresse der FritzBox (Standard-IP ist 192.168.178.1) stehen. Dann klappt es auch mit der Telefonie.
// Update //

Schade AVM! Das wirft auch kein gutes Bild auf euch. Und als Kunde überlegt man sich ja immer, was man in Zukunft selber kaufen oder empfehlen kann……

Danke auch an Thomas, der ebenfalls den Tipp mit der neuen Laborversion gebracht hat. Die Golden Master von iOS 4.1 ist nicht die Lösung gewesen

Sollte man also einen Proxy Server im LAN erreichen oder vll. einfach noch auf seinem Heimrechner installieren können, so wäre das zumindest zum Surfen eine Lösung:

• Einstellungen auswählen
• Menüpunkt Allgemein
• Menüpunkt Netzwerk
• Menüpunkt VPN
• die VPN Einstellungen der FritzBox Verbindung bearbeiten
• Im Bereich Proxy den Punkt Manuell auswählen
• bei Server die IP des Proxyservers eintragen
• bei Port den Port (normalerweise 3128) eintragen
• speichern.

Nun kann nach Aufbau der VPN Verbindung mit Safari über den eingegebenen Proxy gesurft werden. Die HTTP Verbindung wird über den Proxyserver aufgebaut und umgeht damit (erstmal) das DNS Problem.
Im Log des Proxys lassen sich die Verbindungen und etwaige Fehlkonfigurationen (erlaubter Host in den ACL Regeln usw.) gut erkennen und u.U. abändern.

Schöner wäre es natürlich, wenn man im iPhone den DNS Server im VPN Tunnel manuell setzen könnte oder dieser mit der FritzBox übergeben werden könnte. Das ist aber laut AVM derzeit nicht möglich.

@Apple: Baut doch noch einen Menüpunkt in den VPN Einstellungen ein. Einfach in den VPN Einstellungen einen DNS Server eintragen, der bei aufgebauter/ bestehender VPN Verbindung genutzt werden kann.
Damit wäre das Problem mit der FritzBox auch gelöst und alle Programme haben Zugriff auf DNS und können über den VPN Tunnel genutzt werden.

Fazit: Zum Surfen reicht es. Mehr geht leider nicht. Alle anderen Programme (Mail, IM usw.) können weiterhin nicht genutzt werden…
Und ich sehe ein, dass es vll. nicht für jeden die Lösung ist

// UPDATE 05.09.2010 //
AVM hat es endlich geschafft! DNS funktioniert nun auch bei aktivierter VPN Verbindung. Neue Laborversion löst das Problem, einfach mal nachlesen:
http://www.rotzoll.net/2010/09/avm-lost-dns-probleme-bei-vpn-nutzung-vom-iphone-neue-laborversion-sei-dank/
UPDATE //