FritzBox Labor. Linux VPN Client

Dir rp.filter=0 bringen mich weiter.
Connected aber nicht established.
Kann man hier den Fehler sehen?

Code:
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0

Ich verstehe den Aufbau nicht ganz, aber es fehlt m.E. die meine IP im Remote-Netz (192.168.3.201)

Ich habe übrigens das Fritzbox Setting entsprechen c't so modifiziert, dass jeglicher Verkehr über den Tunnel gehen soll. Unter Windows geht das auch. Die Anpassung für den Client dort weiß ich aber nicht, wie auf Shrew zu übertragen.

(solche adresslist ... reject ... permit ..)
 
Hier die Ausgabe von ifconfig & route -n:

7270 (Netz: 192.168.50.0)
route -n
Code:
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.50.0    192.168.50.40   255.255.255.0   UG    0      0        0 tap0
192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.99.0    0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         192.168.99.1    0.0.0.0         UG    0      0        0 eth0
ifconfig
Code:
tap0      Link encap:Ethernet  Hardware Adresse 1a:73:27:14:f5:db  
          inet Adresse:192.168.50.40  Bcast:192.168.50.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


Ich hab mal zu meinem System (eigentlich nach Wiki-Anleitung) folgende Zeile eingegeben

route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.3.201 dev tap0

und bekomme nun etwas, was deiner funktionierenden Ausgabe recht ähnlich sieht.

Code:
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     192.168.3.201   255.255.255.0   UG    0      0        0 tap0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0

locales Netzt 178, remote daheim 3.

tap0      Link encap:Ethernet  Hardware Adresse >geändert> 
          inet Adresse:192.168.3.201  Bcast:192.168.3.255  Maske:255.255.255.0
Ist die Reihenfolge entscheidend? Oder was fehlt nun noch?
 
sag mal,
1. was die Web-Oberfläche der FritzBox über den VPN-Verbindungsstatus anzeigt.
2. ob in shrew im Network-Reiter nach dem die Verbindung aufgebaut wurde, hinter established eine 1 steht.

Außerdem wollte ich über meine Erfahrungen mit Shrew und Linux berichten.
Vorab: Bei mir funktioniert's.
Ich habe die Knoppix LiveCD verwendet und mittels
Code:
apt-get update
apt-get install ike ike-qtgui
shrew aus der root-shell installiert.
Dann habe ich mittels ikea versucht, shrew zu konfigurieren und die VPN-Verbindung aufzubauen. Dabei habe ich die Fehlermeldung "fail to load <profilename>" erhalten. Grund dafür war, dass ich ikea als root gestartet hatte. ikea aus einer shell als knoppix-user gestartet und es ging. Allerdings kann ich so nicht mehr mit ikea das Profil verändern, weil das ja als root-user angelegt wurde. Deswegen musste ich Fehler in dem Profil mit nem Texteditor als root durchführen. Dummerweise meldet ikea nicht, dass er das profil nicht speichern konnte, wenn man auf "save" drückt.

Edit: Noch eine Anmerkung zum Shrew-Linux-Client: Mehrere Konfigurationen auszuprobieren macht in Linux wenig Spaß, denn: Wenn der Tunnel zwar aufgebaut wurde, bei der Konfiguration die Security Associations aber nicht aufgebaut werden konnten, dann geht der entsprechende Datenverkehr nicht durch den Tunnel. Weil Shrew versucht den Tunnel aufzubauen kommt lobenswerterweise beim Ping ein "Resource temporarly unavailable". Das kann beim ersten Ping normal sein, der 2. geht dann durch. Aber wenn die Konfig falsch ist, dann gehen alle Pings nicht durch und scheinen in einer Warteschlange zu landen, die leider auch nach dem Abbau der VPN-Verbindung nicht geleert wird. Dadurch wird die Warteschlange recht schnell zu lang und es kommen gar keine Pakete mehr durch, auch nicht, wenn der Tunnel mit korrekter Konfiguration neu aufgebaut wird. Man erhält in diesem Fall immer ein "Resource temporarly unavailable". Ein Reboot behebt das Problem. Ich weiß nicht, ob man es auch anders beheben kann.

Ich habe das ganze eigentlich nur gemacht, weil ich wissen wollte, ob es bei mir mit dem Linux-Client klappt, dass ich ein paar Routen setze und dann läuft der gesamte Internetverkehr durch den Tunnel. Leider hat das nicht geklappt. Verbindungen in das lokale Netz der FritzBox sind kein Problem, aber weiter lässt mich die FritzBox leider nicht durch. Ich erhalte immer "Destination Host Unreachable" :-(

Meine Konfig und Debug-Ausgaben habe ich angehängt. Alle Befehle wurden auf dem PC ausgeführt, nachdem die VPN-Verbindung aufgebaut wurde und die Routen so gesetzt wurden, dass der gesamte Internetverkehr dadurch geleitet wird.
Hat jemand eine Idee, was ich da ändern muss, damit es geht?

Gruß,
Pfeffer.
 

Anhänge

  • config.txt
    3.7 KB · Aufrufe: 14
Zuletzt bearbeitet:
Shrew 2.1.4 unter Kubuntu 9.04 ( 2.6.28-15 )

Es ging schon mal, dann hab ich es lange nicht benutzt,
mein System (9.04) aber regelmaessig aktualisiert.
Dazugekommen ist 9.10 auf einer anderen Partition
mit dem neuen grub2 (1.9).
Gestern stand ich dann ganz schön auf dem Schlauch.

Shrew 2.1.4 unter Kubuntu 9.04 ( 2.6.28-15 ) läuft jetzt wieder:

sudo /etc/init.d/ike stop
sudo sysctl net.ipv4.conf.all.rp_filter=0
sudo /etc/init.d/ike start

Auf der anderen Seite vom Tunnel:
Fritz!Box Fon WLAN 7270 mit Firmware 54.04.76

a.
 
Die AVM-Anleitung unter Linux ging bei mir nicht. Ich hab Shrew unter Windows konfiguriert und dann die Datei unter Linux verwendet. Dann hatte ich VPN :) - leider nur für den Traffic ins entfernte eigene Netz - nicht für alles.

Kann bestätigen, dass nach falscher konfig reboot fällig wird :(

aligner's tip hat bei mir nicht gefruchtet. Nach erfolgtem VPN-Aufbau war danach auch meine FB nicht mehr erreichbar.

Kann mir jemand erklären, wie man diese Tabelle liest?
Was bedeutet U/UG und Metrik und von wo nach wo liest man das:
Code:
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     192.168.3.201   255.255.255.0   UG    0      0        0 tap0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0
 
Zuletzt bearbeitet:
Wie liest man eine Routingtabelle?
Zweck der Routingtabelle ist, Informationen bereitzustellen, wie unterschiedliche Ziel-IP erreicht werdn können. Zu wird bei einem IP-Paket wird geguckt, wo es hin soll (Ziel-IP). In der Routingtabelle wird nun nachgeschlagen, an welchen Rechner im Netz ("Gateway" oder "Router" genannt) das Paket geschickt werden soll, der es an die Ziel-IP weiterschicken kann.

Beispiel:
IP-Paket hat als Ziel 1.1.1.1
Der Computer, der das Paket verschicken will, hat die IPs 2.2.2.2 (z.B. LAN) und außerdem 3.3.3.3 (z.B. VPN).
Jetzt guckt der Computer in der Routingtabelle nach, über welche IP/Netzwerkkarte er das Paket an 1.1.1.1 verschicken soll.
Die Routingtabelle sieht z.B. so aus:
Code:
Ziel     Router     Genmask        Metrik 
1.1.0.0  3.3.3.1    255.255.0.0    5
0.0.0.0  2.2.2.1    0.0.0.0        10

Das bedeutet:
alle Pakete, die mit 1.1.x.x anfangen, sind über den Router 3.3.3.1 im Netzwerk zu erreichen. Die Genmask gibt dabei (etwas vereinfacht) an, wo das x beginnt. Das x beginnt dort, wo in der Genmask das erste Bit von links 0 ist. Wenn alle Zahlen in der Genmask 255 oder null sind, dann bezeichnet die erste 0 die Stelle, an der das x steht. 1.1.0.0 Genmask 255.255.255.0 würde also alle Rechner 1.1.0.x meinen. 1.1.0.1 Genmask 255.255.255.255 würde nur Rechner 1.1.0.1 meinen. Wenn eine IP über unterschiedliche Routen erreichbar ist, dann entscheidet die Metrik darüber welche Route genommen wird: immer die mit der kleineren Zahl.
In diesem Fall würde also das Paket mit dem Ziel 1.1.1.1 an den Router 3.3.3.1 gesendet, der dann wiederum in seiner Routingtabelle nachschaut, an welchen weiteren Router er das Paket schicken muss, damit es "näher" an Rechner 1.1.1.1 kommt.
Das Ziel 0.0.0.0 mit der Genmask 0.0.0.0 spielt eine besondere Role. Über diese Route / an diesen Router werden alle Pakete geschickt, für die keine Route angegeben ist. Sie wird daher auch "Standardgateway" oder "default route" genannt.

War das verständlich?

Gruß,
Pfeffer.

PS: mit [/code] am Ende und
Code:
 am Anfang kann man die Ausgabe im Forum so zitieren, dass nicht einfach alle Leerzeichen zusammengepappt werden. Das wäre für das Zitat der routingtabelle sehr sinnvoll.
 
Zuletzt bearbeitet:
Danke. Also bezogen auf mein Beispiel
Code:
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     192.168.3.201   255.255.255.0   UG    0      0        0 tap0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0
oben ist 192.168.178.1 das Default-GW, in diesem Falle das Fremdnetz in dem ich mich befinde (letzte Zeile).
Die vorletze hat mal keine weitere Bedeutung (standard).
Die zweite Zeile ist wohl so zu vestehen, dass alles was in mein mein entferntes eigenes Netz geht über mich im entfernten Netz als Router geht (?). Interessant in dem Zusammenhang das da die Metrik auch "0" ist. Spielt dann die Reihenfolge in der Tabelle eine Rolle?
Die erste und dritte Zeile versteh ich nicht, da da als Router 0:0:0:0 eingetragen ist.
 
ja, genau richtig interpretiert. Ich weiß es nicht genau, aber ich glaube, dass bei gleicher Metric die Route verwendet wird, dessen Netmask mehr Bits mit 1 gesetzt hat. Demnach wäre die Reihenfolge der Routen nicht relevant.

Wenn Du nun willst, dass aller Internetverkehr über Dein VPN läuft, dann musst Du also die default Route ändern.
Ich glaube, in Linux muss man dazu die route löschen und dann geändert neu setzen
Code:
route del default
route add default gw 192.168.3.201
Dadurch würde allerdings versucht, auch die verschlüsselten IPSec-Pakete über diese Route zu schicken, was logischerweise nicht geht. Deshalb muss man für den VPN-Server eine Ausnahme definieren. Nehmen wir an, der VPN-Server hat die öffentliche IP 1.1.1.1, dann lautet der Befehl:
Code:
route add 1.1.1.1 netmask 255.255.255.255 gw 192.168.178.1
wobei 192.168.178.1 die IP des default gw ist, die Du ersetzt hast.
Sinnvollerweise macht man das am besten in umgekehrter Reihenfolge: erst die Route zum VPN-Server definieren und erst danach die Default-Route ändern, denn sonst kann der VPN-Client in der Zwischenzeit den VPN-Server nicht erreichen.

Gruß,
Pfeffer.

EDIT: Befehle angepasst, wie frank_m24 gesagt hat. Danke für den Hinweise. Ich hatte sie nur aus dem Kopf hingeschrieben und komme da leicht durcheinander mit der leicht abweichenden Syntax in Windows.
 
Zuletzt bearbeitet:
Hallo,

die Vorgehensweise stimmt im Großen und Ganzen, auch wenn die Kommandos ein bisschen falsch sind. Beim "del" Kommando muss entweder das Gateway angegeben werden oder aber das "gw" darf nicht rein. Bei der Host Route auf den VPN Server darf kein "-net" rein, dafür muss ein "gw" vor das Gateway.

Nochmal Stichpunktartig:
- Default-Route löschen
- Host Route auf den VPN Server einrichten, als Gateway das alte Defaultgateway
- neue Defaultroute mit dem VPN Server als Default-Gateway.

So mache ich es seit Jahren mit vpnc auf einen Cisco IPSEC Server, schön automatisiert über ein Script.
 
Danke pfeffer und frank.
Ich bin wohl noch ein ziemlicher dummy.
Ich habs shrew nun mit 0.0.0.0<->0.0.0.0 in den Policies gestartet
Wenn ich dann die die Default route lösche ist auch hin, was durch shrew gesetzt wurde, also die routen mit tap0 device.
Also andersherum. Default route gelöscht und Route zum VPN gesetzt
Code:
route add 144.155.166.177 netmask 255.255.255.255 gw 192.168.178.1
, aber dabei kommt Netzmask 0000000000 macht keinen Sinn mit Hostroute oder so.
 
Du bekommst beim Ausführen des Route-Befehls eine Fehlermeldung? Falls ja: wie lautet sie genau?
Ich meine ich zu erinnern, dass ich -net oder -host einfügen müsste unmittelbar nach "add", also so:
route add -host 144.155.166.177 netmask 255.255....
Ich weiß nicht warum, meiner Meinung nach war das laut manpage überflüssig, aber ohne ging es bei mir (Knoppix 5.1 / Ubuntu 10) nicht. Ich weiß nicht mehr, ob es "-host" oder "-net" war.
mit
man route
bekommst Du ausführliche Informationen zum Befehl route.

Gruß,
Pfeffer.
 
Sollte man den Shrew starten bevor man die Routen umsetzt oder danach?
Das letzte mal hatte ich die route schon gelöscht, da konnte die mail mit der Meldung nicht mehr abgeschickt werden.
Es passiert mit und ohne -host:

root@ubu:/home/star# route add -host 88.66.xx.xx netmask 255.255.255.255 gw 192.168.178.1
route: Netzmaske 00000000 macht keinen Sinn mit Hostroute
Benutzung: route [-nNvee] [-FC] [<AF>] Kernelroutentabelle anzeigen
route [-v] [-FC] {add|del|flush} ... Routentabelle für AF ändern.

route {-h|--help} [<AF>] Genaue Syntax für AF anzeigen.
route {-V|--version} Version/Autor anzeigen und Ende.

-v, --verbose Ausführliche Ausgaben
-n, --numeric Rechnernamen nicht auflösen
-e, --extend Weitere/zusätzliche Informationen anzeigen
-F, --fib Forwarding Infomation Base anzeigen (Standard)
-C, --cache Routencache statt FIB anzeigen

<AF>=Use '-A <af>' or '--<af>'; default: inet
Liste möglicher Adressfamilien, die Routen unterstützen:
inet (DARPA-Internet) inet6 (IPv6) ax25 (AMPR AX.25)
netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP)
x25 (CCITT X.25)
 
seltsame Fehlermeldung. Da wird man ja gar nicht draus schlau. Ich habe grad mal Ubuntu in VirtualBox für Dich gestartet. Es kommt tatsächlich genau die Fehlermeldung, die ich vorher noch nie gesehen habe.
Also so geht's in Ubuntu v9.10:
Code:
sudo route add -net 88.66.x.x netmask 255.255.255.255 gw 192.168.178.1
Hab doch gesagt, kann sein, dass -net oder -host dahin muss.

zum löschen der default route braucht man auch root-Rechte, also auch mit sudo davor route del default eingeben.

Ich würde die Routen setzen bevor Du in Shrew auf "connect" klickst. Es funktioniert aber evtl. auch noch danach, wenn man Glück hat. Es muss nicht vor dem Start von ikea oder ikec gemacht werden, nur vor dem Connect.

Gruß,
Pfeffer.
 
Hallo,

die Shrew Verbindung muss natürlich bestehen, bevor ihr die Routen setzt. Sonst gibts kein Interface, auf dem er die Defaultroute setzen kann. IPSEC arbeitet mit verbindungslosen Protokollen, da kann nicht viel passieren, wenn für eine halbe Sekunde die Route fehlt.
 
die default route setzt shrew ja automatisch, wenn "include 0.0.0.0 / 0.0.0.0" als policy eingetragen ist. Default route löschen und Host route setzen ist daher sicherer vorher zu machen. Allerdings müssen natürlich die DNS-Server noch erreichbar sein. Wenn die nicht im lokalen Netz sind, dann müssen für die auch Host-Routen gesetzt werden.

Gruß,
Pfeffer.
 
Zuletzt bearbeitet:
Ich hab nun mal folgendes probiert: Hab die Routingtabs der Zwischenschritte mal aufgezeichnet

Code:
Am Anfang sah es so aus (Ohne VPN, ganz normales Setting)
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0

route add -net 88.66.x.x netmask 255.255.255.255 gw 192.168.178.1

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
88.66.x.x     192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0

route del default

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
88.66.x.x     192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0

jetzt shrew starten

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
88.66.x.x     192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 tap0

route add default gw 192.168.3.201

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
88.66.x.x     192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 tap0
0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 tap0
Danach kam ich allerdings nicht mehr auf 192.168.3.1 - meine entfernte Fritzbox, was nicht am mangelnden DNS Server liegen kann. Das wäre wahrscheinlich das nächste Problem gewesen ;)
Am besten wäre natürlich den DNS-Server anzusteuern, der von meiner Fritzbox daheim (192.168.3.1) adressiert wird.
Wie man sieht, ist der letzte Befehl, die default route neu zu setzen überflüssig - wird schon vom Shrew gesetzt. Alles nicht so einfach wie ich mir das dachte, als VPN erst mal prinzipiell lief ...
 
hast Du die fritzbox.cfg so geändert, wie ich es hier ( http://www.ip-phone-forum.de/showthread.php?t=202906 in Post #12 ) beschrieben habe?

Gruß,
Pfeffer.

PS: so ein bißchen frage ich mich schon, warum ich das hier so ausführlich erkläre, wenn Du doch immer nur die Hälfte liest (z.B. "-host" oder "-net", das Hinzufügen der default route überflüssig).
 
Hallo,

Allerdings müssen natürlich die DNS-Server noch erreichbar sein. Wenn die nicht im lokalen Netz sind, dann müssen für die auch Host-Routen gesetzt werden.
Nein, das muss nicht sein. DNS Abfragen können durch den VPN Tunnel erfolgen. Es muss lediglich sichergestellt sein, dass die DNS Server vom VPN Server benutzt werden dürfen. Einige Provider lassen nur ihren eigenen IP-Adressraum auf die DNS Server zugreifen. Kommen Anfragen anderer IPs, so werden sie geblockt. Hat man seine alten DNS Server noch drin und tunnelt sich per VPN zu einem anderen Provider, so kann das schief gehen.
 
[Edit frank_m24: Sinnfreies Vollzitat gelöscht, siehe Forumregeln.]

So heute ein neuer Versuch:
Tut mir leid, ich hab mich schon bemüht das auch zu verstehen.
Was die default-route anbelangt, so kann man aber an meinem langen Code-Post ganz unten sehen, dass durch den Befehl die untere Zeile (sieht man erst nach scrollen) nur verdoppelt wird - das kann nicht sinnvoll sein. Offensichtlich setzt Shrew dieses schon. Und hab doch -net drin, oder muß das in alle Zeilen?

Aber nochmal zur Fritzbox konfig. Ich hab das tatsächlich ein bisschen anders, nach einer Anleitung in der c't, die eine Anpassung an die Fritzbox-Windows-Fernzugang beinhaltet. In dieser wird der accesslist lediglich der der accesslist der Eintrag "permit ip 192.168.3.201 255.255.255.255" hinzugefügt.

Und nun noch mal die gleiche Prozedur gemacht und voila, es scheint zu gehen. Ich komme auf meine Fritzbox daheim und wenn ich einen Download von Ubuntu startet gehts nur mit 56..64kByte/s. Das scheint mir richtig, da ja meine Fritzbox daheim nicht nur download sondern auch wieder upload macht, und der ist nunmal langsamer.

Vielen Dank für die Geduld! Probier das jetzt noch als script - da ist nur das Problem, dass ich die IP meiner Fritzbox mit ping myfritzbox.getmyip.com (dyndns) erst noch ermitteln muß. Oder kann ich das beim Eintragen der route benutzen?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,149
Beiträge
2,246,980
Mitglieder
373,668
Neuestes Mitglied
Stripi
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.