Neues Tutorial - SSH statt VPN
Veröffentlicht am Dec 13 2007 um 8:26 pm.
Keine Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
Ein alter Bekannter aus dem IPCop Forum (Ralf Petry) hat mir gerade eine neue Anleitung zukommen lassen, die ich der Community nicht vorenthalten möchte. Er hat sich mit seinem Tutorial “VPN auf RED” schon viele Freunde gemacht und bietet jetzt mit seinem neuen Tutorial eine Schritt für Schritt Anleitung an, wie ohne VPN, einzig mit SSH, auf entfernte Rechner, z. B. zu Fernwartungszwecken, zugegriffen werden kann.
Mein Fernwartungs Tutorial behandelt diese Anwendungsmöglichkeit zwar bereits, Ralf geht aber noch einen Schritt weiter und lässt auch Linux Clients nicht aus.
Hier gehts zum Tutorial “SSH statt VPN” 
Gruss
Ecki
Update 1.4.11 - Neue VPN Features
Veröffentlicht am Aug 26 2006 um 5:18 pm.
Keine Kommentare.
Gespeichert unter Tips & Tricks, IPCop - Links.
Seit wenigen Tagen steht das Update auf die Version 1.4.11 hier zum Download bereit. Neben einigen Bugfixes im GUI, neuen Setup- und Backup-Möglichkeiten (USB-Stick) und der Aktualisierung einiger Softwaremodule gab es auch viele Neuigkeiten im Bereich VPN. Viele Dinge, die bisher eine manuelle Anpassung in der Datei /var/ipcop/vpn/ipsec.conf notwendig machten, sind nun direkt über die GUI zu erreichen.
Hier eine Liste der interessantesten Änderungen:
Ich werde einige der neuen Features in der nächsten Zeit kommentieren und falls nötig erklären. Wünsche für Erklärungen und Anleitungen bitte als Kommentar zu diesem Thread posten. Diese Fragen werden zuerst bearbeitet…
Gruss
Ecki
Neues Addon - Watch my Tunnels
Veröffentlicht am Aug 13 2006 um 12:55 pm.
Keine Kommentare.
Gespeichert unter Tips & Tricks, IPCop-Addons.
Ein neues Addon, das viele Probleme bei Net2Net VPN’s mit dynamischen IP’s beheben kann, wurde kürzlich von Rüdiger Sobeck, Alias “Scripterix” fertiggestellt. Ziel dieses Addons ist es, den IP-Adress Wechsel nach einer 24h Zwangstrennungen zeitnah zu erkennen und anschliessend den betroffenen Tunnel neu zu starten. Weitere aktive Tunnel werden bei dieser Lösung nicht getrennt und laufen unbehindert weiter.
Das Addon ist eine Weiterentwicklung des Sripts aus dem Tutorial “VPN, DPD und DynDNS” von Rüdiger, welches ich hiermit gerne auf meiner Homepage zum Download zur Verfügung stelle.
Hier geht es zum Download des Addons und der Dokumentation.
14.08.2004, Update auf Version 0.1.2
17.08.2004, Update auf Version 0.1.3
09.07.2007, Update auf Version 0.1.6
Gruss
Ecki
Neues Tutorial - VPN, DPD und DynDNS
Veröffentlicht am Mar 30 2006 um 8:52 pm.
Keine Kommentare.
Gespeichert unter Tutorials.
Ein neues Mitglied des IPCop-Forums, Rüdiger Sobeck, mit dem Nick “Scripterix”, hat sich die Mühe gemacht, das Thema VPN, DPD und DynDNS ausführlich zu beleuchten. Seine Arbeit hat er mir dankenswerterweise zur Veröffentlichung zur Verfügung gestellt, was ich hiermit auch mit Freude tue.
Ebenfalls mitgeliefert wird ein Script zum Überprüfen und Neustarten von bestehenden VPN-Tunnel.
Zu finden ist der Beitrag hier.
Hinweise oder Ergänzungen zu diesem Thema könnt ihr, nach einer Anmeldung, selbst an diesen Beitrag anhängen. Ein Klick auf den Titel bringt euch direkt zur Eingabemaske.
Gruss
Ecki
Tunnels are cheap
Veröffentlicht am Feb 18 2006 um 4:10 pm.
4 Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
Was will uns diese Überschrift sagen?
Immer wieder wird im IPCop-Forum die Frage gestellt, wie denn das Routing über ein VPN funktioniert. Alle Versuche, mit “route add…” Pakete auf den Tunnel zu schicken, scheitern kläglich. Warum ist das so, und was kann man stattdessen tun? Diese Frage will ich hier kurz beleuchten.
Wenn ein IPSec-Tunnel gestartet wird, werden in der “Datei” /proc/net/ipsec_eroute alle neuen Routen, die durch die Tunneldefinitionen dazugekommen sind, eingetragen. Wenn kein VPN läuft, existiert die “Datei” übrigens nicht. Mit /usr/lib/ipsec/eroute auf der Konsole kann ein Blick auf diese VPN-Routen (eroute) geworfen werden. Mit route lässt sich dagegen auf der Konsole die normale Routingtabelle anschauen.
Wenn nun ein Paket auf dem IPCop eintrifft, wird es zuerst mit der eroute-Routingtabelle aus /proc/net/ipsec_eroute abgeglichen. Nur wenn hier keine passende Route gefunden wird, wird das Paket an die normale Routingtabelle (route) weitergeleitet und dann normalerweise über das Defaultgateway weitergeschickt. Die normale Route wird natürlich nur dann zum gewünschten Ziel führen, wenn kein VPN benötigt wird, um die Ziel-IP zu erreichen.
Mit diesen Informationen sollte es nun kein Problem mehr sein, auch Subnetze zu erreichen, die z. B. “hinter” dem Subnetz-GREEN liegen.
Angenommen wir haben dieses Setup:
SubnetzA/IPCopA — Internet — IPCopB/SubnetzB — Router/SubnetzC
Ein Client in SubnetzA muss Server in SubnetzB und SubnetzC ereichen. Hier genügt es nicht, nur zwischen SubnetzA und SubnetzB ein VPN zu bauen und dann von SubnetzB zum SubnetzC zu routen. Alle Pakete für das SubnetzC würden vom IPCopA auf das Defaultgateway (Internet) geschickt und nicht durch den Tunnel zum IPCopB, da keine eroute für SubnetzC vorhanden ist. Um dieses Verhalten zu ändern, muss ein zweiter Tunnel definiert werden mit SubnetzA als “Lokales Subnetz” und SubnetzC als “Remote Subnetz”, die “Remote Host/IP” wäre dann RED-IPCopB. Dadurch wird automatisch eine neue eroute eingerichtet und das Paket für SubnetzC korrekt über den Tunnel zu IPCopB geschickt, der dann wiederum ganz normal ins SubnetzC weiterrouten kann.
Subnetting
Eine andere Möglichkeit, das vorangegangene Szenario zu lösen, wäre über die Definition von Subnetzen. Dies geht aber nur, wenn sich SubnetzeB und SubnetzC in der gleichen Klasse bewegen (192.168.x.x, 172.16.x.x, oder 10.x.x.x). Hier besteht dann z. B. die Möglichkeit mehrere Subnetze zusammenzufassen und dadurch über einen einzigen Tunnel zu adressieren. Ein Beispiel:
SubnetzA = 192.168.1.0/24
SubnetzB = 192.168.2.0/24
SubnetzC = 192.168.3.0/24
SubnetzA/IPCopA — Internet — IPCopB/SubnetzB — Router/SubnetzC
Um SubnertB und SubnetzC zusammenzufassen, müsste man als “Remote Subnetz” 192.168.2.0/23 oder 192.168.2.0/255.255.254.0 verwenden. Dadurch wären alle Adressen zwischen 192.168.2.1 und 192.168.3.254 abgedeckt und würden damit über den Tunnel geschickt.
Da mehrere Tunnel aber keinen negativen Einfluss auf die Performance haben und transparenter implementiert werden können, empfehle ich persönlich die Verwendung von mehreren Tunneldefinitionen. Dazu kommt, dass diese Lösung universell einsetzbar ist und auf keinen Fall eine Umadressierung notwendig macht.
Wer nicht so fit im Subnetting ist, kann Subnet Kalkulatoren wie z. B. diesen hier verwenden:
http://jodies.de/ipcalc
Nähere Informationen zum Subnetting:
http://www.netplanet.org/adressierung/subnetting.shtml
Der Originalartikel “Tunnels are cheap” findet sich hier und adressiert noch wesentlich mehr Szenarien:
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/adv_config.html
Gruss
Ecki
DPD - wie geht das ?
Veröffentlicht am Feb 4 2006 um 3:28 pm.
2 Kommentare.
Gespeichert unter Tips & Tricks.
DPD (Dead Peer Detection) ist ein optionaler Mechanismus in vielen IPsec-Implementationen, der es IPsec ermöglicht, festzustellen, ob die Gegenseite noch verbunden ist, oder ob die Verbindung abgebrochen ist. Von Haus aus kann IPsec dies nur feststellen, wenn ein Rekeying stattfindet, was beim IPCop normalerweise nur alle 60 Minuten passiert.
Auch der IPCop unterstützt mit der Version 1.4.10 DPD, was vor allem den Usern mit Roadwarrior-Konfigurationen und den Usern ohne fixe IP zugute kommen kann.
Achtung, beide Seiten des Tunnels müssen DPD beherrschen und dafür konfiguriert sein (dpddelay oder dpdtimeout), damit DPD funktionieren kann. Wenn nur ein Parameter (dpddelay oder dpdtimeout) konfiguriert ist, wird für den anderen Parameter mit Defaultwerten (dpddelay=30, dpdtimeout=120) gearbeitet.
DPD benutzt “Keep-Alive” Nachrichten, die dann über den Tunnel geschickt werden, wenn für eine bestimmte Zeit kein sonstiger Verkehr stattgefunden hat (dpddelay=”Sekunden”). Dann werden von den Partnern “Keep-Alive” Pakete (R_U_THERE) verschickt und der VPN-Partner antwortet darauf mit einem “Ja” (R_U_THERE_ACK). Kommt keine Antwort vom VPN-Partner zurück, werden so lange “Keep-Alive” Pakete verschickt, bis der Timeoutwert erreicht ist (dpdtimeout=”Sekunden”>). Wenn auch dann noch keine Rückantwort (R_U_THERE_ACK) gekommen ist, wird der VPN-Partner für “tot” erklärt und eine von 3 möglichen Aktionen (dpdaction=”Aktion”) ausgeführt.
DPD ist keine globale Einstellung, sondern kann für jede Verbindung getrennt konfiguriert werden, ein Beispiel:
conn dpdbeispiel
- left=%defaultroute
leftnexthop=%defaultroute
right=192.168.0.1
dpddelay=30
dpdtimeout=120
dpdaction=clear
Im obigen Beispiel wird nach 30 Sekunden Inaktivität auf der Leitung ein “R_U_THERE” Paket verschickt um die Verfügbarkeit des Partners zu überprüfen. Kommt innerhalb von 120 Sekunden kein “R_U_THERE_ACK” zurück, wird die Verbindung zurückgesetzt ,in diesem Beispiel mit “clear”, wodurch der gesamte Tunnel inclusive sowohl der SA (Security Association), als auch alle verbundenen eroute Einträge gelöscht wird.
Der Parameter dpdaction bestimmt, was mit einem Tunnel geschieht, wenn der Partner nicht mehr antwortet:
dpdaction=hold (Default) setzt die eroute Einträge auf %hold und wartet darauf, dass der Partner wieder online kommt.
dpdaction=clear löscht die gesamte Verbindung inclusive SA und eroute Tabelle.
dpdaction=restart führt einen Neustart der Verbindungsbeschreibung durch.
Bei Verbindungen mit fixer IP-Adresse (Net2Net) wird die Einstellung “hold” empfohlen. Für Roadwarrior dagegen ist “clear” die beste Wahl. “restart” kann bei Net2Net-Verbindungen mit dynamischen IP-Adressen helfen.
Gruss
Ecki
IPsec-Fehlermeldungen erklärt - Teil 3
Veröffentlicht am Jan 7 2006 um 10:47 pm.
12 Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
23:58:40 pluto[14958] packet from X.X.X.X:500: initial Main Mode message received on X.X.X.X:500 but no connection has been authorized with policy=PSK
Statt policy=PSK kann bei dieser Fehlermeldung alternativ auch policy=RSASIG stehen, wenn Zertifikate verwendet werden. Die Lösung ist unabhängig von der Verbindungsmethode.
Dies ist ein sehr häufiger Fehler der immer zu einem gescheiterten Verbindungsaufbau führt. Diese Meldung bedeutet, dass dieses Ende der Verbindung (wo dieser Eintrag im Log steht) eine IPsec-Verbindungsanfrage bekommen hat, die er nicht von der Source-IP X.X.X.X erwartet hat. In der Folge wird die Anfrage ignoriert und die Verbindung kommt nicht zustande.
Lösung 1:
Wenn die IP-Adresse X.X.X.X der erwarteten IP entspricht, solltest du als Erstes die lokale ipsec.conf und ipsec.secrets überprüfen, zu finden unter /var/ipcop/vpn/.
/var/ipcop/vpn/ipsec.conf (Ausschnitt mit der Verbindungskonfiguration)
conn abc
left=1.2.3.4
leftnexthop=%defaultroute
leftsubnet=192.168.2.0/255.255.255.0
right=5.6.7.8
rightsubnet=192.168.3.0/255.255.255.0
rightnexthop=%defaultroute
dpddelay=30
dpdtimeout=120
dpdaction=hold
authby=secret
auto=start
/var/ipcop/vpn/ipsec.secrets
: RSA /var/ipcop/certs/hostkey.pem
1.2.3.4 5.6.7.8 : PSK “GeheimesPasswort”
Stelle sicher, dass die verwendeten IP-Adressen für left und right mit den tatsächlichen IP-Adressen übereinstimmen und in beiden Dateien (ipsec.conf und ipsec.secrets) korrekt eingetragen sind, dann sollte dieser Fehler verschwinden.
Wenn FQDN’s im Spiel sind, vor allem in Verbindung mit DynDNS und 24h Zwangstrennung, solltest du natürlich zuerst die Namensauflösung überprüfen. Ein einfacher Ping vom IPCop auf den FQDN sollte Klarheit bringen. Wenn die Namensauflösung klappt, der Fehler aber nicht verschwindet, solltest du es zuerst einmal mit IP-Adressen versuchen. Diese müssen dann natürlich in allen oben genannten Dateien, oder über das Web-GUI angepasst werden.
Lösung 2:
Eine alternative Fehlerursache kann auch ein NAT-Device (Router) vor dem Remote-Client sein. In diesem Fall ist die WAN-IP (RED) des Remote-IPCop’s eine private Adresse. In der Verbindungskonfiguration des lokalen IPCops ist aber vermutlich die externe IP des NAT-Devices (Routers) hinterlegt.
Um dieses Problem zu lösen, muss die private IP-Adresse von RED sowohl in der ipsec.conf, als auch in der ipsec.secrets hinzugefügt werden. Dies geschieht für die Datei ipsec.conf mit Hilfe von rightid=192.168.0.2, wobei 192.168.0.2 als IP-RED angenommen wird. In der Datei ipsec.secrets muss nur die IP-Adresse hinterlegt werden.
/var/ipcop/vpn/ipsec.conf (Ausschnitt mit der Verbindungskonfiguration)
conn abc
left=1.2.3.4
leftnexthop=%defaultroute
leftsubnet=192.168.2.0/255.255.255.0
right=5.6.7.8
rightid=192.168.0.2 ####An die private IP-Adresse von IPCop-RED anpassen !!
rightsubnet=192.168.3.0/255.255.255.0
rightnexthop=%defaultroute
dpddelay=30
dpdtimeout=120
dpdaction=hold
authby=secret
auto=start
/var/ipcop/vpn/ipsec.secrets
: RSA /var/ipcop/certs/hostkey.pem
1.2.3.4 5.6.7.8 192.168.0.2 : PSK “GeheimesPasswort”
Viel Spass bei der Fehlersuchen 
Gruss
Ecki
IPsec-Fehlermeldungen erklärt - Teil 2
Veröffentlicht am Dec 18 2005 um 10:45 pm.
Keine Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
23:58:40 "abc" #1: initiating Main Mode
23:58:40 "abc" #1: STATE_MAIN_I1: initiate
23:58:40 "abc" #1: STATE_MAIN_I1: retransmission; will wait 20s for response
23:59:00 "abc" #1: STATE_MAIN_I1: retransmission; will wait 40s for response
23:59:20 "abc" #1: max number of retransmissions (2) reached STATE_MAIN_I1.
23:59:20 No acceptable response to our first IKE message
Was hier passiert, ist ein Verbindungsversuch, bei dem die andere Seite den Versuch abblockt, oder gar nicht erst zu sehen bekommt. Das kann verschiedene Ursachen haben.
Das Naheliegendste ist es, zuerst mit Ping die Erreichbarkeit des Partners zu testen, um Routingprobleme auszuschliessen. Am Besten verbindet man mit SSH auf den ersten IPCop und macht dann ein Ping auf RED des anderen IPCop. Der Test sollte unbedingt auch vom anderen IPCop aus durchgeführt werden, um sicherzustellen, dass das Routing auch von der Gegenseite aus funktioniert. Mittels Ping auf den DNS-Namen kann dann ebenfalls auf beiden IPCop’s die Namensauflösung getestet werden.
Der nächste Test hat zum Ziel, festzustellen, ob der zweite IPCop die Verbindungsanfrage überhaupt zu sehen bekommt. Mit tcpdump –i ppp0 kann der gesamte Datenverkehr (In und Out) beobachtet werden, wobei angenommen wird, dass RED ppp0 ist. Dies sollte vorgängig in der Web-GUI unter “Status” -> “Netzwerk-Status” überprüft werden und das Kommando falls nötig auf das richtige Interface angepasst werden.
Für den Fall, dass zu viel Verkehr mitgeloggt wird, kann die Anzeige auch gefiltert werden. Die Eingabe folgenden Kommandos tcpdump host w.x.y.z zeigt nur Pakete vom und zum Host w.x.y.z an. Da IKE UDP-Port 500 verwendet, kann der Filter mit tcpdump host w.x.y.z and udp port 500 noch weiter verfeinert werden.
Wärend das SSH-Fenster des Remote-IPCop geöffnet ist, sollte nun das VPN mit Hilfe dieses Buttons 
neu gestartet werden. Es müssten dann sofort Pakete auf der anderen Firewall im Log (tcpdump Konsole) erscheinen. Tut sich nichts, werden die IKE-Anfragen offensichtlich geblockt.
Nun heisst es herauszufinden, wo die Pakete hängenbleiben.
Ein iptables -L -n -v auf dem Remote-IPCop (nicht dem, auf dem der Fehler geloggt wird) zeigt, ob die UDP-Ports 500 und 4500 geöffnet sind. Wenn diese Ports nicht geöffnet sind, ist vermutlich das Häkchen bei “Aktivieren” auf der VPN Konfigurationsseite für das entsprechende Interface (RED, oder BLUE) nicht gesetzt. Das sollte dann unverzüglich nachgeholt werden. Wenn die Ports 500 und 4500 erlaubt sind, kann in seltenen Fällen (unbewusste Fehlkonfiguration, etc.) auch Port 500 UDP explizit gedroppt werden. In so einem Fall müsste sich eine Regel nach dem Schema
DROP upd — anywhere w.x.y.z upd dpt:500 finden. Diese Regel müsste dann in der /etc/rc.d/rc.firewall.local, oder der /etc/rc.d/rc.local wieder entfernt, oder zumindest auskommentiert werden.
Wenn diese Option richtig konfiguriert ist und der Fehler nicht verschwindet, sollte der Status der Netzwerkkarte überprüft werden, entweder über die GUI unter “Status” -> “Netzwerk-Status” oder auf der Konsole mit
ifconfig ethx.
Hier dürfen keine, oder kaum Errors, Drops, Overruns oder Frames zu finden sein. Bei höheren Werten (>1% der RX/TX packets) sollte die Karte ausgetauscht werden.
Viel Spass bei der Fehlersuche
To be continued…
Gruss
Ecki
IPsec-Fehlermeldungen erklärt - Teil 1
Veröffentlicht am Nov 27 2005 um 6:30 pm.
Keine Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
Ich werde in Beiträgen mit diesem Titel, in loser Folge, einzelne, häufig auftretende Fehlermeldungen aus dem IPsec-Log erklären und Lösungsvorschläge geben.
Erste Anlaufstelle, wenn mit einem IPsec-VPN etwas nicht funktioniert, sollte immer das VPN-Log sein, zu finden unter:
“Logs” -> “System-Logdateien” -> “Abschnitt: IPSec”
Mit Hilfe der dort zu findenden Angaben sollte sich der Fehler rasch aufspüren und eliminieren lassen.
Ein erfolgreicher Verbindungsaufbau sieht ungefähr so aus (zu lesen von Unten nach Oben):
22:49:47 pluto[585] "abc" #4: STATE_QUICK_I2 sent QI2, IPsec SA established
22:49:47 pluto[585] “abc” #624: STATE_QUICK_I1 initiate
22:49:46 pluto[585] “abc” #624: sent MR3, ISAKMP SA established
22:49:46 pluto[585] “abc” #624: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
22:49:46 pluto[585] “abc” #624: Main mode peer ID is ID_IPV4_ADDR: www.xxx.yyy.zzz
22:49:46 pluto[585] “abc” #624: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
22:49:46 pluto[585] “abc” #624: NAT-Traversal: Result using draft-ietfipsec-nat-t-ike-02/03: no NAT detected
22:49:46 pluto[585] “abc” #624: transition from state (null) to state STATE_MAIN_R1
22:49:46 pluto[585] “abc” #624: responding to Main Mode
So ein Abschnitt wiederholt sich bei jedem neuen Key-Exchange, welcher sich normalerweise alle ~60 Minuten ereignet. Ausserdem sollte im VPN-Menü bei der entsprechenden Verbindung ein grünes “OPEN” Feld erscheinen. Wenn das soeben genannte nicht der Fall ist, wird es Zeit für ein Troubleshooting.
Welche Tools stehen uns nun zur Verfügung ?
Ich nenne hier die wichtigsten Tools, in der Reihenfolge, in der ich sie auch verwenden würde.
erlaubt es, die Erreichbarkeit eines VPN-Partners zu testen (WAN-Interface)
erlaubt eine Routenverfolgung vom eigenen Rechner zum Zielrechener, wobei hierbei alle Hop’s mit den entsprechenden Antwortzeiten ersichtlich sind
erlaubt es, die letzten x Einträge des Systemlogs anzusehen. Mit tail /var/log/messages -f sieht man alle neuen Einträge im Systemlog, sobald sie geschrieben werden, die Zeilen scrollen dann über den Schirm. Abbrechen kann man diesen Modus mit Ctrl. + C
zeigt den gesamte Regelsatz der Firewall an. Der Output kann durch Angabe des CHAIN-Namens hinter -L eingegrenzt werden, z. B. mit /sbin/iptables -L CUTSTOMINPUT-n -v
zeigt den aktuellen Status an, einschliesslich der aktuellen Verbindungen und deren Status bezüglich ISAKMP und IPsecSA
zeigt ausführliche IPsec-Statusinformationen
zeigt Unmengen an Debugginginformationen zu IPsec
zeigen die aktuelle Routingtabelle aus dem Memory an
zeigt alle aktiven Ports und deren Status an, interessant, um zu sehen, ob der IPcop auf einem bestimmten Port lauscht oder nicht, bzw. ob auf einem bestimmten Port schon eine Verbindung besteht
erlaubt es, alle Pakete auf dem definierten Interface mitzulesen, auch auf den IPsec-Interfaces. tcpdump kennt sehr viele Optionen, die sich mit tcpdump –help erforschen lassen
Viel Spass bei der Fehlersuche
To be continued…
Gruss
Ecki
Update - VPN auf RED
Veröffentlicht am Nov 15 2005 um 9:10 pm.
1 Kommentar.
Gespeichert unter Tutorials.
Ralf Petry hat sein Tutorial VPN auf RED aktualisiert und einige neue Aspekte hinzugefügt.
Als Erstes wäre eine Anleitung zum Setzen der MTU bei einem IPsec-Tunnel zu nennen. Ein häufiges Problem bei VPNs, das leider nicht so leicht zu erkennen ist. Anzeichen für MTU-Probleme sind:
, Upload 
, oder umgekehrt)Als zweite Neuerung findet sich eine Anleitung, wie mit der 24h Zwangstrennung vieler ADSL-Provider umzugehen ist, incl. einem Script zum zeitgesteuerten Neuaufbau der Verbindung.
Gruss
Ecki