FBF WLAN 7050: IPSec-VPN (UDP 500) wird nicht richtig durchgeleitet?

[KuniGunther]

Hallo Harald,

vielleicht sollte man es in diesem Thread auch nochmal explizit sagen (Dein Zitat von mir aus Posting #19 bzgl. Portweiterleitung ist nämlich veraltet - sorry -, da lief irgendwas beim Capturen schief):

Wenn der VPN-Server IKE-Anfragen ausschließlich von einem Source-Port 500 akzeptiert, dann muß man ausnahmsweise auch für den Client-Betrieb in der FritzBox eine Portweiterleitung eintragen (UDP 500). Diese verhindert, dass die FritzBox den Port in den ausgehenden Paketen umschreibt, d.h. PAT betreibt.

Dieses funktioniert nachgewiesenermaßen und ist in dem von AVM bei solchen Anfragen verschicktem PDF-File auch genause mit dieser Begründung beschrieben! (Soll heißen, ich habe mittlerweile bei AVM nachgefragt.)

Die Sache mit dem Port-Handling der Server sehe ich etwas anders:

Im [eigentlich was anderes beschreibenden] RFC 3104 wird übrigens nebenbei mal ausdrücklich darauf hingewiesen, daß in den RFCs 2407-2409 [zu IKE v1] der Source-Port gar nicht zwingend vorgeschrieben ist.
[...]
IKE implementations MUST support UDP port 500 for both source and destination, but other port numbers are also allowed.

Nun ja, Du zitierst da etwas anderes als ich gefunden habe. Die Formulierung im Original RFC ist nämlich so, dass da steht "other ports MAY be supported". Wenn jetzt jemand einen Server schreibt, implementiert er natürlich erstmal nur das MUST ... Ich denke schon, dass die Server, die nur Port 500 bedienen standard-konform sind.

Allerdings bleibt zu klären, warum andere Router das trotzdem durchleiten können - und auch mit mehreren Clients aus ihrem eigenen geNATeten LAN.

Nun, um mal spitzfindig zu sein, könnte ich sagen, es liegt ja nicht am NAT, sondern am PAT . Nein, da der Port 500 nur während der Schlüsselaushandlung gebraucht wird, würde ich in einem solchen NAT-Server, den ausgehenden Port 500 dafür reservieren und ihn jeweils für den "freischalten", der ihn benutzt. So können zwar auch keine zwei Schlüsselaushandlungen gleichzeitig stattfinden (geht mit Portforwarding ja auch nicht), aber so wäre man nicht an eine IP gebunden.

Viele Grüße,
Volker

 

[gandalf94305]

Nun, um mal spitzfindig zu sein, könnte ich sagen, es liegt ja nicht am NAT, sondern am PAT . Nein, da der Port 500 nur während der Schlüsselaushandlung gebraucht wird, würde ich in einem solchen NAT-Server, den ausgehenden Port 500 dafür reservieren und ihn jeweils für den "freischalten", der ihn benutzt. So können zwar auch keine zwei Schlüsselaushandlungen gleichzeitig stattfinden (geht mit Portforwarding ja auch nicht), aber so wäre man nicht an eine IP gebunden.

Die Key Exchanges können innerhalb einer Session bei Reconnects oder Expirations der Keys laufend nachgefordert werden, d.h. ein manuelles Nachführen des Mappings für den jeweiligen "Nutzer" ist wohl nicht so recht praktikabel.

Die korrekte Alternative wäre hier, IKE etc. über den Router verhandeln zu lassen und über Routing und Berechtigungen dann klären, welcher interne Rechner auf die VPN-Tunnel zugreifen darf.

--gandalf.

 

[KuniGunther]

Ok, überzeugt

 

[gandalf94305]

Aber die gute Nachricht ist, daß die FBF für einen VPN-Tunnel korrekt arbeiten kann und mehr braucht Otto Normalnetworker zuhause ja auch nicht ;-) oder?

--gandalf.

 

[KuniGunther]

Klar, besonders da der VPN Server, den ich benutzen muss (Cisco), sich auch mit anderen Ports zufrieden gibt.

Auf jeden Fall weiß ich jetzt 100%tig, dass es geht, und für den Fall, dass nicht, woran es liegen könnte. Bisher wäre ich nie auf die Idee mit Port 500 gekommen.

Volker

 

[telchef]

Aber die gute Nachricht ist, daß die FBF für einen VPN-Tunnel korrekt arbeiten kann und mehr braucht Otto Normalnetworker zuhause ja auch nicht ;-) oder?

Jein.

Besser wäre es, wenn bei nicht aktivierter Portweiterleitung (FBF "Portfreigabe") für den ersten im geNATeten LAN stehenden IPSec-Client der Source-Port 500 benutzt werden würde (statt gleich schon einem gePATeten Highport zu nehmen), so könnte wenigstens _einer_ einen Tunnel zu einem mager befähigten IPSec-Gateway aufbauen.
Und ein einziger Benutzer dürfte im SoHo mit der Home-User-Hardware FBF der häufigste Fall sein.

Zugegeben, dann würden wieder Leute kommen, die sich wundern, warum ein zweiter IPSec-Client dann nicht geht. Gefahr für Mißverständnisse.

Schade jedenfalls, daß es nicht präzise in Bedienungsanleitung oder dem Service-Bereich von AVM steht.


Gruß, Harald

 

[telchef]

Hallo Volker!

Die Sache mit dem Port-Handling der Server sehe ich etwas anders:

Nun ja, Du zitierst da etwas anderes als ich gefunden habe. Die Formulierung im Original RFC ist nämlich so, dass da steht "other ports MAY be supported". Wenn jetzt jemand einen Server schreibt, implementiert er natürlich erstmal nur das MUST ...

Das kann ich nicht finden.
In den RFCs um IKE v1 (in dem Fall RFC 2408 ) finde ich nur das:

"2.5.1 Transport Protocol
ISAKMP can be implemented over any transport protocol or over IP
itself. Implementations MUST include send and receive capability for
ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port
500 has been assigned to ISAKMP by the Internet Assigned Numbers
Authority (IANA). Implementations MAY additionally support ISAKMP
over other transport protocols or over IP itself."

Ich denke schon, dass die Server, die nur Port 500 bedienen tandard-konform sind.

Deswegen schrieb ich auch "minderwertig" statt "nicht standardkonform".
Ich sehe es also genau wie Du.

Obwohl der Source-Port ja in meinem zitierten RFC 2408 gar nicht explizit erwähnt wird, bzw. Source- und Target-Port gar nicht separat betrachtet werden.
Warum jemand dann auf die Idee kommen muß, Source-Ports eingrenzen zu müssen, kann ich mir nur mit mangelnder Weitsicht und vorauseilendem Beschränkungswahn erklären. Naja, es wäre wohl auch minimal aufwendiger, auf verschiedene Source-Ports zu antworten...

Glücklicherweise hat man ja mit IKE v2 erkannt, daß man Entwickler zu geschickter Entwicklung zwingen muß (und es explizit vorschreiben muß), da sie alleine i.d.R. nicht darauf kommen.

So mußten sich weltweit 1000ende Administratoren mit eingeschränktem Kram rumschlagen... Schade, daß das keiner bezahlen will.


Gruß, Harald

 

[telchef]

Hallo gandalf!

Die korrekte Alternative wäre hier, IKE etc. über den Router verhandeln zu lassen und über Routing und Berechtigungen dann klären, welcher interne Rechner auf die VPN-Tunnel zugreifen darf.

Du meinst, daß der Router der VPN-Endpunkt ist? Sicher. Nur ist das für Road-Warrior wohl eher illusorisch.


Gruß, Harald

 

[KuniGunther]

Hallo Harald,

Das kann ich nicht finden.
In den RFCs um IKE v1 (in dem Fall RFC 2408 ) finde ich nur das:

Da hat mich meine Gedächtnis im Stich gelassen. Genau das meinte ich. Allerdings ist da von anderen Ports ja gar nichts die Rede, nur das Implementierungen (und dazu gehören auch Clients!) Senden und Empfangen auf Port 500 implementieren müssen.

Warum jemand dann auf die Idee kommen muß, Source-Ports eingrenzen zu müssen, kann ich mir nur mit mangelnder Weitsicht und vorauseilendem Beschränkungswahn erklären. Naja, es wäre wohl auch minimal aufwendiger, auf verschiedene Source-Ports zu antworten...

Richtig, es steht nur da, dass der Client auf Port 500 senden können muss, aber nicht, dass der Empfänger nur darauf antworten muss. Na ja, die explizite Anweisung, SENDEN auf Port 500 einzubauen, könnte man natürlich als Absicht interpretieren, das genauso gemeint haben zu wollen. Welchen Sinn sollte es sonst machen, jemandem vorzuschreiben, welchen Port ich für ausgehenden Traffic nutzen soll?

Eigentlich ist es ja sogar weniger aufwendig, weil man sich dann gar nicht um den Port kümmern muss, sondern einfach die Verbindung bearbeiten kann.

Es ist allerdings müßig, darüber zu diskutieren, warum jemand irgendwann mal einen Server so oder so implementiert. Die Frage ist höchstens, ob man von NAT-Routern erwarten soll, dass sie solche eingeschränkten Server unterstützen. In der FB gibt es eine Möglichkeit dazu, mit diesen zu arbeiten. Und das sollte eigentlich genügen.

Viele Grüße,
Volker

 

[telchef]

Hallo Volker!

Es ist allerdings müßig, darüber zu diskutieren, warum jemand irgendwann mal einen Server so oder so implementiert.

Stimmt. Ich mag aber auch gerne nebenbei mal politische Diskussion, denn die Technik verschlingt so viel Zeit, da kann man auch mal philosophieren.

Die Frage ist höchstens, ob man von NAT-Routern erwarten soll, dass sie solche eingeschränkten Server unterstützen.

Ich finde, daß ist keine Frage:
Ja, sie müssen es unterstützen!

In der FB gibt es eine Möglichkeit dazu, mit diesen zu arbeiten. Und das sollte eigentlich genügen.

Entschuldige, daß ich nochmal Korinthen kacken muß:

Naja, es gibt nur eine Möglichkeit *EINEN* Road-Warrior hinter einer FBF einen Tunnel aufbauen zu lassen - und für diesen "DHCPler" muß man dann auch noch extra die FBF konfigurieren.
Kommen in ein SoHo öfter mal Kollegen mit ihren Notebooks, muß man andauernd fummeln - das nervt.
Und erklär' das mal den DAUs - und das jedem Monat erneut, weil sie es ob der seltenen Anwendung immer wieder vergessen.

Am Ende bekommst Du noch einen schlechten Ruf, weil "*ES andauernd nicht funktioniert" - schließlich hast Du selber auch noch die Lösung im Jahre 2000 ausgesucht. Und damals hätte proprietäre und undokumentierte Cisco-Lösung noch > 40.000 DM gekostet, die freie Lösung um 4.000 DM.

Fazit: Mit einem 200-EUR-Home-User-Router fährt man TCO-/aufwandsmäßig teurer, als mit einem 600-EUR-Profi-Router. (Hatte ich gleich geschätzt.)
Aber heutzutage fällt das Nachdenken ja schwer.

Gruß, Harald

 

[telchef]

So, hier zitiere ich mich mal selbst:

Allerdings bleibt zu klären, warum andere Router das trotzdem durchleiten können - und auch mit mehreren Clients aus ihrem eigenen geNATeten LAN. Ich werde das noch untersuchen.

Ich hab' jetzt nochmal ein wenig mit einem hervorragenden Stück Technik, dem "LANCOM 1811 Wireless DSL", Traffic analysiert.

Der funktioniert einfach. Er macht den Schlüsselaustausch für verschiedene Roaad-Warrior in seinem geNATeten LAN mit Source-Port UDP 500, und kann dann auch verschiedene Tunnel gleichzeitig durchleiten.
Was er dazu genau macht, um die ESP-Tunnel korrekt den jeweiligen IKE-Verbindungen zuzuordnen bzw. umkekehrt, habe ich natürlich nicht heraus-"disassembliert", ich bin ja nicht der Entwickler.
Die ESP-Tunnelzuordnung an sich wird sicherlich über die ESP-SPIs geschehen.

Zusätzlich kann der 1811 auch noch selber als VPN-Endpunkt arbeiten, so daß man optimal flexibel ist.

Der "LANCOM 1811 Wireless DSL" hat zwar kein integriertes DSL-Modem, wie die FBF, jedoch gibts dafür ja den 1821.
Fehlen leider nur noch vergleichbare VoIP-Telefonanlagen-Funktionen und -Anschlußmöglichkeiten, wie bei der AVM FBF WLAN 7170, dann hätte man das perfekte Gerät.

Vielleicht bringt LANCOM ja noch sowas. Kann ich mir aber nicht so ganz wirklich vorstellen, da das Profi-Geräte sind. Und nur die wenigsten Profis dürften Interesse haben, 3 popelige Analog-Telefone und ein paar ISDN-Telefone an einen VoIP-Router anzuschließen....

Obwohl: Für ein Kleinstbüro mit 3-5 Mitarbeitern wäre das schon die Komplett-Lösung. Aber diese Klientel will höchstens 100 EUR für ihre Infrastruktur bezahlen, und nehmen maximal die mitgebrachten Völkner-China-Müll-Telefone, die der Chef noch aus seiner Schulzeit im Keller gelagert hatte, incl. seiner Kinder-Telefonanlage aus der ISDN-Förderzeit...

Oder auf einem Messestand - da könnte man sich dann den überteuerten Telefonanschluß sparen, und mit dem überteuerten Internetanschluß auskommen.


Gruß, Harald

 

[KuniGunther]

Zu den Möglichkeiten oder Unmöglichkeiten IKE/IPSec zu NATten ist das ganz interessant:
http://www.cisco.com/web/about/ac12...isco_ipj_archive_article09186a00800c83ec.html

 

[DirkKn]

Fehlen leider nur noch vergleichbare VoIP-Telefonanlagen-Funktionen und -Anschlußmöglichkeiten, wie bei der AVM FBF WLAN 7170, dann hätte man das perfekte Gerät.

Vielleicht bringt LANCOM ja noch sowas. Kann ich mir aber nicht so ganz wirklich vorstellen, da das Profi-Geräte sind. Und nur die wenigsten Profis dürften Interesse haben, 3 popelige Analog-Telefone und ein paar ISDN-Telefone an einen VoIP-Router anzuschließen....

Warum schaust Du nicht einfach mal auf der Homepage von Lancom vorbei, anstatt hier (falsche) Spekulationen anzustellen.

Zum einen kommt in Kürze die Firmware 6.00, die VoIP-Funktionalitäten enthält, zum anderen kommt dann auch der 1722, der ähnliche VoIP Funktionen wie eine FritzBox anbieten soll.

 

[telchef]

Hallo DirkKn!

Warum schaust Du nicht einfach mal auf der Homepage von Lancom vorbei, anstatt hier (falsche) Spekulationen anzustellen.

Zum einen kommt in Kürze die Firmware 6.00, die VoIP-Funktionalitäten enthält, zum anderen kommt dann auch der 1722, der ähnliche VoIP Funktionen wie eine FritzBox anbieten soll.

Spekulationen für die Zukunft können schon mal per Definition nicht "falsch" sein.
Daher sind es ja "Spekulationen" und keine Tatsachenberichte für zukünftige Ereignisse, welche es ohne Zeitmaschine nicht geben kann.


Daß ich Lancom Systems und deren Produkte liebe, sollte aus meinem vorigen Posting entnehmbar gewesen sein. Manche scheinen aber eine geringe Auffassungsgabe zu haben.


Deine genannten "VoIP-Funktionalitäten" sind eher lächerlich, wenn man keine herkömmlichen Telefone (ISDN UND [!] Analog) anschließen kann (an derzeit real existierende Produkte):
SIP-Telefone kann man auch ganz ohne eigenen SIP-Server betreiben, da brauche ich nicht erst einen LANCOM-Router.
Hier auch mal die Kosten vergleichen: SIP-Provider oder Asterisk. Das ist alles in der Nähe von 0 EUR - da denkt man nicht an LANCOM, es sei denn, man ist etwas dümmlich, wie die von der Marketingabteilung angepeilte neue Zielgruppe (denn wer klug ist, kauft schon LANCOM).

LANCOMs "VoIP ready" ist genauso lächerlich, wie "HD ready" (sorry Lancom Systems): Kann nix, aber erstmal schön mit Buzzword dahergelabert.


Umgesehen hatte ich mich schon, das darfst Du glauben:
Auf der Website von LANCOM ist so gut wie nichts über angekündigte VoIP-Produkte zu lesen, schon gar nicht über welche mit Anschlußmöglichkeit für herkömmliche Telefone (ISDN und Analog). Nur "VoIP-Ready"-Geschwafel über in der Praxis bedeutungslose Möglichkeiten.


Dein tolles (derzeitiges) Phantasieprodukt 1722 wird kein WLAN haben und vermutlich auch keine Analog-Anschlüsse. Insofern nicht mit der FBF vergleichbar.
Vielleicht kommt ja auch mal ein 1822. Wenn aber auch da keine reichlichen Telefonanschlüsse vorhanden sind, wird das auch ein nutzloses Produkt sein - vor allem in der Preisklasse von > 1.000 DM!
In dieser Preisklasse muß so ein Produkt schon eine TK-Anlage für ein SoHo VOLLSTÄNDIG ersetzen können.


Gruß, Harald

 

[DirkKn]

Spekulationen für die Zukunft können schon mal per Definition nicht "falsch" sein.
Daher sind es ja "Spekulationen" und keine Tatsachenberichte für zukünftige Ereignisse, welche es ohne Zeitmaschine nicht geben kann.

Na da haben wir mal wieder einen ganz schlauen getroffen. :blonk:
Hättest Du dich vorher besser informiert!

Deine genannten "VoIP-Funktionalitäten" sind eher lächerlich, wenn man keine herkömmlichen Telefone (ISDN UND [!] Analog) anschließen kann (an derzeit real existierende Produkte):

Du weisst dann aber, was Du willst.

Umgesehen hatte ich mich schon, das darfst Du glauben:
Auf der Website von LANCOM ist so gut wie nichts über angekündigte VoIP-Produkte zu lesen, schon gar nicht über welche mit Anschlußmöglichkeit für herkömmliche Telefone (ISDN und Analog). Nur "VoIP-Ready"-Geschwafel über in der Praxis bedeutungslose Möglichkeiten.

Glaub ich Dir nach den Zeilen nun wirklich nicht mehr!

Dein tolles (derzeitiges) Phantasieprodukt 1722

Geht's noch gut ja?! Was hab ich mit Lancom zu tun.:argh:

vor allem in der Preisklasse von > 1.000 DM!

Guten Morgen!!! Wir schreiben bereits das Jahr 2006! :idea:

Aber bei derart unqualifiziertem Geschreibsel erübrigt sich jede Diskussion!

 

[telchef]

Na da haben wir mal wieder einen ganz schlauen getroffen. :blonk:
Hättest Du dich vorher besser informiert!

Du raffst es nicht, nicht wahr!?
Auf der Website von LANCOM ist nichts über einen 1722 zu finden, bzw. irgendwo unverlinkt ein bedeutungsloses PDF, wo nebenbei mal in 3 Zeilen irgendwas grob angekündigt wird.

Geht's noch gut ja?! Was hab ich mit Lancom zu tun.:argh:

Habe ich nicht behauptet. Bist Du etwas dumm oder alkoholisiert?
Ich habe nur von "Deinem Phantasieprodukt 1722" gesprochen, denn Du hast davon erzählt. Deswegen mußt Du nichts "mit LANCOM zu tun" haben -> was faselst Du für zusammenhanglosen Unsinn!?

Guten Morgen!!! Wir schreiben bereits das Jahr 2006! :idea:

Aber bei derart unqualifiziertem Geschreibsel erübrigt sich jede Diskussion!

Und deswegen können manche hirnarmen Typen hier keine Umrechnung in EUR mehr bewältigen, was!?

Eigentlich war die Nennung von dem Betrag in DM (> 1000 DM) für solche kleinen Hirnis gedacht, die bei 500 EUR an "wenig" denken. Es sollte die Preisklasse verdeutlichen helfen. Aber sowas scheinst Du einfach geistig nicht erfassen zu können. Vermutlich bist Du einer dieser typischen MTV- und PISA-Generation.
Vermutlich bist Du auch erst 14, und kannst deswegen mit DM-Beträgen nicht umgehen.


Ich weiß gar nicht, warum ich immer wieder überrascht bin, wenn so beschränkte Wesen, wie Du, einem immer wieder begegnen...


Harald

 

[gandalf94305]

Beschränkt sind wir als menschliche Wesen ja nun alle auf die eine oder andere Weise, aber wir können in diesen Beschränkungen doch versuchen, nett und freundlich miteinander umzugehen. Schließlich ist das hier ja ein technisches Forum und es geht nicht um persönliche Dinge, oder? ;-)

Zum Lancom 1722: wenn ich eine der wenig bekannten Suchmaschinen verwende, z.B. www.google.de , und dort mal "lancom 1722" eintippe, kommt als erstes Dokument eins von Lancom selbst:

http://www.lancom-systems.de/produkte/feature/brochures/solution_guide_VoIP_de.pdf

Man findet auch Artikel wie z.B.

http://www.tecchannel.de/news/themen/telko/434119/

Es scheint also nicht ganz ein Phantasieprodukt zu sein, sondern demnächst ein Produkt von Lancom.

Ahem... zurück zum Thema... wo waren wir gerade?

--gandalf.

 

[DirkKn]

Du raffst es nicht, nicht wahr!?

Genau! Und Du bist hier der chef?!


Trottel!!! (ist ja sonst nicht so meine Art, aber was anderes kann man dazu nicht sagen)

 

[telchef]

Hallo gandalf!

Beschränkt sind wir als menschliche Wesen ja nun alle auf die eine oder andere Weise, aber wir können in diesen Beschränkungen doch versuchen, nett und freundlich miteinander umzugehen. Schließlich ist das hier ja ein technisches Forum und es geht nicht um persönliche Dinge, oder? ;-)

Weißt Du, es ist mir eben einfach zu blöde, mir von einem Schulkind (hiermit meine ich nicht Dich) dumm kommen zu lassen.

Die Foren sind zunehmend voll von Unterbelichteten und Friseusenkindern, die sich aus ihrem Kinderzimmer heraus oder aus der Sozialwohnung für IT-Experten halten, nur, weil sie z.B. mal -wie im aktuellen Fall- zufällig auf ein einziges Dokument mit der Randerwähnung "1722" gestoßen sind, da ist meine Reizschwelle nach Jahren in der Branche extrem niedrig.

Da müht man sich stundenlang mit schlecht dokumentierten Produkten der Hersteller ab, gibt hier seine Erfahrungen als Hilfe für andere zum besten (auch wenn ich zunächst die Hilfe anderer gesucht hatte, mußte ich doch wieder mal das ganze Problem alleine bis in's Detail untersuchen - abgesehen von Volkers hilfreicher Beobachtung einer [anderen] funktionierenden Konstellation), und gibt noch nebenbei eine (voraussichtlich richtige) Abschätzung für die Zukunft von LANCOM-Produkten heraus ("von LANCOM wird kein vergleichbares Home-User-Produkt zu der FBF zu erwarten sein"),

und dann kommt ein oberschlaues Kellerkind daher, und meint rumpupen zu können, weil es gerade mal ein einziges Dokument mit einer ganz groben Ankündigung gefunden hat, was niemand mit vertretbarem Aufwand auf der Herstellerseite finden kann, da es nicht direkt verlinkt ist bzw. man das nicht als quasi "Produktankündigung" finden kann.

Das ist eine Beleidigung! (Nicht die Tatsachenfeststellung über seine geistigen Fähigkeiten.) Leider wurde durch den Forums-Admin ja nur das "Trottel"-Posting von DirkKn mit einer Warnung belegt, nicht das Posting, welches mich beleidigt.

Der Typ wirft mir ja auch noch vor, mich nicht richtig informiert zu haben, und tut noch so, als ob an jeder Werbetafel "LANCOM 1722" stehen würde, und nur komplett verblödete Idioten nicht wüßten, daß LANCOM irgendwann mal das ach so "weltbekannte" 1722 rausbringen wird.
Denn auch schon in den Nachrichten um 20:00 Uhr auf SAT1 und sogar im ZDF wird verkündet: "LANCOM bringt bald den 1722!" Jedes Kind weiß das!

Zum Lancom 1722: wenn ich eine der wenig bekannten Suchmaschinen verwende, z.B. www.google.de , und dort mal "lancom 1722" eintippe, kommt als erstes Dokument eins von Lancom selbst:

http://www.lancom-systems.de/produkte/feature/brochures/solution_guide_VoIP_de.pdf

Nicht alle leben im Google-Universum! ;-)

Natürlich, wenn ich einen geplanten Produktnamen ("1722") kenne, dann kann ich auch mal danach googlen. Versuche das mal ohne "1722" zu finden...

Wenn ich aber nach Produktankündigungen suche, dann gehe ich auf die Seite des Herstellers. Und dort ist es ausgesprochen schwierig bis unmöglich, etwas von einem neuen Modell zu finden. Dein zitiertes PDF ist offenbar auch das einzige, was vom 1722 etwas erwähnt, und das nur beiläufig, Thema ist VoIP, nicht Produktankündigung. Im leeren Marketing-Blabla geht es dann auch noch nahezu unter.

Man findet auch Artikel wie z.B.

http://www.tecchannel.de/news/themen/telko/434119/

Es scheint also nicht ganz ein Phantasieprodukt zu sein, sondern demnächst ein Produkt von Lancom.

Ahem... zurück zum Thema... wo waren wir gerade?

Mit "Phantasieprodukt" meinte ich ein Produkt, das es bisher nur in DirkKns Phantasie gibt - oder hat es schon jemand bei sich zu Hause!?

Und es bleibt auch noch dabei: Es wird nicht vergleichbar mit der FBF WLAN 7050 sein, denn es wird sich in folgenden wichtigen Punkten unterscheiden:
- keine Analogports
- kein WLAN
- 6-facher Preis (oberhalb der 1.000-DM-Marke)

So könnte man auch einen goldenen NTBA als FBF-Ersatz ankündigen -> hat auch 2 Steckplätze für ISDN-Geräte.

Sein oberschlauer Einwurf gegen meine Spekulation ("eher keine Home-User-Produkte vergleichbar mit FBF von LANCOM zu erwarten") war und ist daher hirnrissig, sorry. Auch, wenn es bald mal ein Gerät mit einem zusätzlichen ISDN-Port geben wird.


Gruß, Harald

 

[DM41]

Da hier nur noch Beschimpfungen stattfinden, schließe ich den Thread.