111171
Apr 03, 2013
10218
9
0
VPN-Problem Bintec-Router am CompanyConnect
Hallo zusammen,
man hat mir hier folgendes Szenario vorgesetzt, das mich ein wenig zum Verzweifeln bringt:
1) Bintec Router R1202 konfiguriert mit ETH1 (en1-0) auf IP 192.x.y.1 und mit ETH3 (en1-2) auf IP 62.x.y.106
2) An ETH1 hängt ein DSL-Business (Teledat-Modem) mit fester IP 80.x.y.z
3) An ETH3 hängt ein CompanyConnect-2M (One60) mit fester IP 62.x.y.105 (lt. Aufkleber ein 29er Netz)
Die Konfiguration ist wohl historisch gewachsen (früher gab es wohl noch einen weiteren DSL auf ETH2),
es gibt keine Dokumentation zu der Konfiguration und leider auch keine sonstige Dokumentation oder
Vertragsunterlagen etc., da alles wohl mit wenig oder - wenn man so will - ohne Sorgfalt gehandhabt wurde.
Auf dem Bintec sind mehrere PPTP-(Mitarbeiter)- und IPSec-(Filialen/Kunden)-Zugänge auf die DSL-IP
konfiguriert und diese funktionieren auch problemlos. Ich würde nun gerne den DSL kappen und diesen
Router nur mit dem CC nutzen, da ich für den DSL mit einem zweiten Router einen anderen
Verwendungszweck wüsste. Ziehe ich aber den DSL von ETH1 ab und konfiguriere die VPN-Zugänge
entsprechend auf die IP des CC um, dann funktionieren nur die PPTP-Zugänge (und der Internetzugang
von intern nach außen), aber nicht die IPSec-Zugänge. Die beiden Router in den Filialen, die ich (fern)
konfigurieren kann, sind ebenfalls Bintec, bei den Kunden habe ich weder Zugriff, noch weiß ich bisher
etwas über die Hardware.
Ich war der Meinung, dass eigentlich alles korrekt konfiguriert ist, die Routen sind gesetzt, die FW-Ports
entsprechend offen, die CC-IP lässt sich von außen pingen, aber da es nicht funktioniert, liege ich mit
meiner Meinung offensichtlich falsch. Da ich noch zuvor noch nie mit Bintec und einem One60 zu tun
hatte und auch keinerlei Doku/Info vorliegen habe, habe ich keine Idee mehr, woran es noch liegen könnte.
Liegt das an dem Bintec oder eher dem One60? Muss ich da evtl. auch noch etwas konfigurieren bzw.
kann ich das überhaupt?
Würde mich echt freuen, wenn mir jemand helfen könnte!
man hat mir hier folgendes Szenario vorgesetzt, das mich ein wenig zum Verzweifeln bringt:
1) Bintec Router R1202 konfiguriert mit ETH1 (en1-0) auf IP 192.x.y.1 und mit ETH3 (en1-2) auf IP 62.x.y.106
2) An ETH1 hängt ein DSL-Business (Teledat-Modem) mit fester IP 80.x.y.z
3) An ETH3 hängt ein CompanyConnect-2M (One60) mit fester IP 62.x.y.105 (lt. Aufkleber ein 29er Netz)
Die Konfiguration ist wohl historisch gewachsen (früher gab es wohl noch einen weiteren DSL auf ETH2),
es gibt keine Dokumentation zu der Konfiguration und leider auch keine sonstige Dokumentation oder
Vertragsunterlagen etc., da alles wohl mit wenig oder - wenn man so will - ohne Sorgfalt gehandhabt wurde.
Auf dem Bintec sind mehrere PPTP-(Mitarbeiter)- und IPSec-(Filialen/Kunden)-Zugänge auf die DSL-IP
konfiguriert und diese funktionieren auch problemlos. Ich würde nun gerne den DSL kappen und diesen
Router nur mit dem CC nutzen, da ich für den DSL mit einem zweiten Router einen anderen
Verwendungszweck wüsste. Ziehe ich aber den DSL von ETH1 ab und konfiguriere die VPN-Zugänge
entsprechend auf die IP des CC um, dann funktionieren nur die PPTP-Zugänge (und der Internetzugang
von intern nach außen), aber nicht die IPSec-Zugänge. Die beiden Router in den Filialen, die ich (fern)
konfigurieren kann, sind ebenfalls Bintec, bei den Kunden habe ich weder Zugriff, noch weiß ich bisher
etwas über die Hardware.
Ich war der Meinung, dass eigentlich alles korrekt konfiguriert ist, die Routen sind gesetzt, die FW-Ports
entsprechend offen, die CC-IP lässt sich von außen pingen, aber da es nicht funktioniert, liege ich mit
meiner Meinung offensichtlich falsch. Da ich noch zuvor noch nie mit Bintec und einem One60 zu tun
hatte und auch keinerlei Doku/Info vorliegen habe, habe ich keine Idee mehr, woran es noch liegen könnte.
Liegt das an dem Bintec oder eher dem One60? Muss ich da evtl. auch noch etwas konfigurieren bzw.
kann ich das überhaupt?
Würde mich echt freuen, wenn mir jemand helfen könnte!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 204349
Url: https://administrator.de/contentid/204349
Printed on: April 23, 2024 at 20:04 o'clock
9 Comments
Latest comment
Hallo,
Auf das sind den die IPSec Tunnel terminiert?
Kann es sein, das die auf der gegenseite, (remote) auf die IP des DSL konfiguriert sind?
Dann kann das nicht funktionieren...
Brammer
Auf das sind den die IPSec Tunnel terminiert?
Kann es sein, das die auf der gegenseite, (remote) auf die IP des DSL konfiguriert sind?
Dann kann das nicht funktionieren...
Brammer
Wie schon erwähnt, wurden auch die IPSec-Gegenstellen (zumindest "meine" beiden) testweise umkonfiguriert, so wie die PPTP-Gegenstellen auch. Bei ersteren funktioniert es aber aus irgendeinem Grund trotzdem nicht...
Was meinst du mit "Bei ersteren.." Sind das DEINE beiden IPsec Gegenstellen ??
Wenn ja kommt es darauf an WIE diese konfiguriert sind ??.
Wie du sicher selber weisst sind die IPsec Einstellungen nicht so trivial wie PPTP und erfordern etwas mehr Sorgfalt. Ohne Details WIE diese Tunnel auf deinen Testroutern und dem Bintec definiert sind ist einen zielführende Hilfe ziemlich aussichtslos.
Ferner hast du keinerlei Logauszüge vom Bintec geschickt, WAS der mitloggt wollen deine testrouter einen IPsec Tunnel aufbauen ??
Dir leuchtet sicher selber ein das ein remote Hilfe über ein Forum wie dies ohne diese Informationen eher wie eine Heilung durch Handauflegen ablaufen....
Da musst du also nachbessern....
Grundlegende Hilfen vorab geben dir diese Tutorials:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
und
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Wenn ja kommt es darauf an WIE diese konfiguriert sind ??.
Wie du sicher selber weisst sind die IPsec Einstellungen nicht so trivial wie PPTP und erfordern etwas mehr Sorgfalt. Ohne Details WIE diese Tunnel auf deinen Testroutern und dem Bintec definiert sind ist einen zielführende Hilfe ziemlich aussichtslos.
Ferner hast du keinerlei Logauszüge vom Bintec geschickt, WAS der mitloggt wollen deine testrouter einen IPsec Tunnel aufbauen ??
Dir leuchtet sicher selber ein das ein remote Hilfe über ein Forum wie dies ohne diese Informationen eher wie eine Heilung durch Handauflegen ablaufen....
Da musst du also nachbessern....
Grundlegende Hilfen vorab geben dir diese Tutorials:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
und
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Ja, ich meinte damit meine beiden Gegenstellen und ich weiß auch, dass und wie sich IPSec von PPTP unterschiedet. Mein Problem ist ja nicht die IPSec-Verbindung an sich, sondern die Tatsache, dass die Verbindung nicht mehr funktioniert, wenn ich die Gegenstellen auf eine andere IP meines Routers verbinden will. Da sich (mMn) sonst keine Parameter ändern, sollte es doch eigentlich damit getan sein, dass ich in den IPSec-Konfigurationen der Gegenstllen die bisherige IP gegen die neue IP austausche.
Logs habe ich keine angehängt, da ich ehrlich gesagt bisher noch nicht heraus gefunden habe, wie ich bei den Bintec-Routern an die Logs komme...
Wenn ich mir beim Verbindungsaufbau die Details anschaue, dann meldet die Gegenstelle etwas wie "Warnung! Bezug zu ungültigem Datenbankeintrag!" und in der Tabelle, wo normalerweise die benutzten IKEv1-Algorithmen gelistet sind, steht statt "3DES/SHA1" plötzlich "Ungültiger Bezug/Ungültiger Bezug". Da ich vermutet habe, es könnte durch Löschen und Neuerstellen der Profile ein Problem in den MIBs aufgetreten sein, habe ich mir die Tabellen angeschaut, aber die dort stehenden Indizes für die genutzten Profile stimmen jeweils.
Mein Router meldet entsprechend "failed id fqdn". Diese hat sich aber nicht geändert, ich denke mal, es liegt daran, dass die Gegenstelle hier wohl keine IKE-Parameter verwendet und die Kommunikation deswegen nicht klappt. Weder die Bintec-Seiten, noch sonst irgendwo im Internet habe ich etwas zu den Meldungen der Gegenstellen gefunden, weswegen ich hier auf Hilfe hoffe. Aber natürlich nicht durch "Hand auflegen"...
Logs habe ich keine angehängt, da ich ehrlich gesagt bisher noch nicht heraus gefunden habe, wie ich bei den Bintec-Routern an die Logs komme...
Wenn ich mir beim Verbindungsaufbau die Details anschaue, dann meldet die Gegenstelle etwas wie "Warnung! Bezug zu ungültigem Datenbankeintrag!" und in der Tabelle, wo normalerweise die benutzten IKEv1-Algorithmen gelistet sind, steht statt "3DES/SHA1" plötzlich "Ungültiger Bezug/Ungültiger Bezug". Da ich vermutet habe, es könnte durch Löschen und Neuerstellen der Profile ein Problem in den MIBs aufgetreten sein, habe ich mir die Tabellen angeschaut, aber die dort stehenden Indizes für die genutzten Profile stimmen jeweils.Mein Router meldet entsprechend "failed id fqdn". Diese hat sich aber nicht geändert, ich denke mal, es liegt daran, dass die Gegenstelle hier wohl keine IKE-Parameter verwendet und die Kommunikation deswegen nicht klappt. Weder die Bintec-Seiten, noch sonst irgendwo im Internet habe ich etwas zu den Meldungen der Gegenstellen gefunden, weswegen ich hier auf Hilfe hoffe. Aber natürlich nicht durch "Hand auflegen"...
..."nicht mehr funktioniert, wenn ich die Gegenstellen auf eine andere IP meines Routers verbinden will" Ist doch logisch wenn man sich mal die Grundlagen zu IPsec durchliest.
IPsec kann (abgesehen von anderen Parametern) die Quell und Ziel IPs des Tunnels zur Authentisierung benutzen was häufig in PSK Umgebungen der Fall ist.
Änderst du diese IPs (was du oben ja machst) schlägt die Authentisierung fehl und nix iss mit VPN Tunnel...logo !
Deshalb die Frage nach deinem IPsec Setup !!
Log ist der allererste Anlaufpunkt das zu Troubleshooten. Warum also nimmst du nicht das Bintec Handbuch und gehst mal strategisch vor wie es sich gehört für einen Netzwerker ??
Bintec gehört ja nun wahrlich nicht zu den Billigheimern und ganz sicher haben die eine Log Funktion auf dem Router !! Mindestens aber eine Syslog Funktion wo du Logging meldungen auf einen Syslog schicken kannst wie z.B.. die kostenlosen:
Kiwi Syslog: http://www.kiwisyslog.com/products/kiwi-syslog-server/product-overview. ...
Mkrotik Syslog: http://www.mikrotik.com/archive.php
Draytek Syslog: http://www.draytek.com/user/SupportDLUtility.php
und und und...
Vermutlich hast du (geraten anhand deiner rudimentären Meldungen) einen Schlüsselprotokoll Mismatch DES, SHA, MD5 oder was noch wahrscheinlicher ist einen Mismatch der Authentisierung. Wenn du keinen FQDN Namen für die Authentisierung angegeben hast, fallen die Router häufig auf ihre IPs zurück...und dann nimmt das Unglück wieder seinen Lauf...
Es bleibt dabei: Log und Konfig (mindestens aber IPsec Parameter) helfen uns weiter...
IPsec kann (abgesehen von anderen Parametern) die Quell und Ziel IPs des Tunnels zur Authentisierung benutzen was häufig in PSK Umgebungen der Fall ist.
Änderst du diese IPs (was du oben ja machst) schlägt die Authentisierung fehl und nix iss mit VPN Tunnel...logo !
Deshalb die Frage nach deinem IPsec Setup !!
Log ist der allererste Anlaufpunkt das zu Troubleshooten. Warum also nimmst du nicht das Bintec Handbuch und gehst mal strategisch vor wie es sich gehört für einen Netzwerker ??
Bintec gehört ja nun wahrlich nicht zu den Billigheimern und ganz sicher haben die eine Log Funktion auf dem Router !! Mindestens aber eine Syslog Funktion wo du Logging meldungen auf einen Syslog schicken kannst wie z.B.. die kostenlosen:
Kiwi Syslog: http://www.kiwisyslog.com/products/kiwi-syslog-server/product-overview. ...
Mkrotik Syslog: http://www.mikrotik.com/archive.php
Draytek Syslog: http://www.draytek.com/user/SupportDLUtility.php
und und und...
Vermutlich hast du (geraten anhand deiner rudimentären Meldungen) einen Schlüsselprotokoll Mismatch DES, SHA, MD5 oder was noch wahrscheinlicher ist einen Mismatch der Authentisierung. Wenn du keinen FQDN Namen für die Authentisierung angegeben hast, fallen die Router häufig auf ihre IPs zurück...und dann nimmt das Unglück wieder seinen Lauf...
Es bleibt dabei: Log und Konfig (mindestens aber IPsec Parameter) helfen uns weiter...
Ich bin gerade nicht vor Ort, weswegen ich mich nicht um die Logs kümmern kann, aber irgendwie willst Du mich anscheinend auch nicht verstehen. Oder drücke ich mich tatsächlich so missverständlich aus? Ich habe die neue IP an den Stellen angepasst, an denen es notwendig war!
Zur Konfiguration: es gibt kein Schlüsselprotokoll-Mismatch! Es wurde und wird auf beiden Seiten 3DES/SHA1 in Phase 1 und 3DES/MD5 in Phase 2 benutzt, auch die anderen Parameter (Modus, DH-Gruppe etc.) sind alle unverändert. Als Authentisierung wird FQDN mit PSKs benutzt und der FQDN ist der jeweilige Routername und hat sich nicht geändert. Auch der PSK ist der gleiche geblieben, weil sich - wie bereits mehrfach erwähnt - nur die IP des Ziels (also meine Seite) geändert hat, die in der Konfiguration im Bintec bei den IPSec-Peers unter Peer-Adresse angegeben wird. Und noch einmal: mit der alten IP (an den gleichen Stellen wie testweise die neue IP, also wohl auch an den richtigen Stellen) funktioniert alles!
Laut den Infos, die ich recherchiert habe, fungiert beim CompanyConnect der One60 doch nur als Bridge und lässt den gesamten IP-Verkehr ungefiltert durch. Ist das korrekt oder ist es möglich, dass der schuld an der Misere ist? Der One60 ist ja außer der geänderten IP die zweite Änderung auf der "Strecke"...
Zur Konfiguration: es gibt kein Schlüsselprotokoll-Mismatch! Es wurde und wird auf beiden Seiten 3DES/SHA1 in Phase 1 und 3DES/MD5 in Phase 2 benutzt, auch die anderen Parameter (Modus, DH-Gruppe etc.) sind alle unverändert. Als Authentisierung wird FQDN mit PSKs benutzt und der FQDN ist der jeweilige Routername und hat sich nicht geändert. Auch der PSK ist der gleiche geblieben, weil sich - wie bereits mehrfach erwähnt - nur die IP des Ziels (also meine Seite) geändert hat, die in der Konfiguration im Bintec bei den IPSec-Peers unter Peer-Adresse angegeben wird. Und noch einmal: mit der alten IP (an den gleichen Stellen wie testweise die neue IP, also wohl auch an den richtigen Stellen) funktioniert alles!
Laut den Infos, die ich recherchiert habe, fungiert beim CompanyConnect der One60 doch nur als Bridge und lässt den gesamten IP-Verkehr ungefiltert durch. Ist das korrekt oder ist es möglich, dass der schuld an der Misere ist? Der One60 ist ja außer der geänderten IP die zweite Änderung auf der "Strecke"...
..."nicht vor Ort, weswegen ich mich nicht um die Logs kümmern kann"
Dafür muss man ja auch nie vor Ort sein denn es reicht ein remoter Zugriff auf die Maschine wenn man mitdenkender Netzwerker ist !
Nein, verstehen wollen wir dich schon sonst würden wir hier nicht antworten und dich mit deinem Problem einfach allein lassen. Du sagst ja oben das du keinen Zugriff auf die Client Router hast, die müssen aber zwingend auch angepasst werden bei Umbau des IPsec..ist dir aber vermutlich selber klar ?!
Testen kannst du es also einzig und allein NUR mit deinen beiden Testclients. Vermutlich gehts also nun im jetzigen Test einzig nur um diese beiden Systeme ?! Sorry wenn das missverstanden wurde...
OK, wenn dort Source- und Ziel Adressen des Tunnels angepasst wurden und das korrekt (worauf wir uns hier mal verlassen) dann sollte das klappen.
In den Proposals müssen dann analog auch die beiden remoten lokalen LANs angepasst sein auch das fliesst in die Authentisierung ein.
Gibt es einen tieferen Grund warum du unterschiedliche Hash Verfahren nutzt in Phase 1 und 2 ? Normalerweise macht man das nicht, denn das sind wieder Stolpersteine wenn die Proposals dazu nicht angepasst sind ?!
Aber egal...daran liegts nicht wenn es analog mit der anderen IP funktioniert und diesen 2 Testsystemen bei entsprechender Anpassung.
Vermutlich ist dann der One60 der böse Buhmann !
Per se ist das erstmal ein Router und keine Bridge:
http://extranet.oneaccess-net.com/download/one60/ONE60_install_manual_d ...
Wenn du am Bintec Port eine öffentliche IP hast also keine RFC 1918 IP, dann ist davon auszugehen das der Router einfach nur das /29er Subnetz an den Bintec Port vollkommen transparent routet.
Damit müsste dann auch IPsec Traffic dort sauber ankommen.
Besser (und sicherer zum wissen) wär das wenn du das mit einem Wireshark Sniffer mal verifizierst !! Im Router Log sieht man sowas aber auch...
Macht der One60 Router aber NAT in Richtung Bintec, dann ists aus mit IPsec, denn ohne aktives NAT Traversal und Port Forwarding ist ein NAT Port nicht zu überwinden für IPsec.
Das gilt es also rauszufinden für dich !!
Routet der One 60 transparent nur das Subnetz liegt es wieder an dir und deinen Routern bzw. der Konfiguration, das ist dann auch klar.
Company Connect überträgt immer IPsec (in der Regel) denn Firmen nutzen üblicherweise VPNs !!
Es bleibt dabei: Ohne Debug Output und Log vom Bintec kommen wir nicht viel weiter...
Dafür muss man ja auch nie vor Ort sein denn es reicht ein remoter Zugriff auf die Maschine wenn man mitdenkender Netzwerker ist !
Nein, verstehen wollen wir dich schon sonst würden wir hier nicht antworten und dich mit deinem Problem einfach allein lassen. Du sagst ja oben das du keinen Zugriff auf die Client Router hast, die müssen aber zwingend auch angepasst werden bei Umbau des IPsec..ist dir aber vermutlich selber klar ?!
Testen kannst du es also einzig und allein NUR mit deinen beiden Testclients. Vermutlich gehts also nun im jetzigen Test einzig nur um diese beiden Systeme ?! Sorry wenn das missverstanden wurde...
OK, wenn dort Source- und Ziel Adressen des Tunnels angepasst wurden und das korrekt (worauf wir uns hier mal verlassen) dann sollte das klappen.
In den Proposals müssen dann analog auch die beiden remoten lokalen LANs angepasst sein auch das fliesst in die Authentisierung ein.
Gibt es einen tieferen Grund warum du unterschiedliche Hash Verfahren nutzt in Phase 1 und 2 ? Normalerweise macht man das nicht, denn das sind wieder Stolpersteine wenn die Proposals dazu nicht angepasst sind ?!
Aber egal...daran liegts nicht wenn es analog mit der anderen IP funktioniert und diesen 2 Testsystemen bei entsprechender Anpassung.
Vermutlich ist dann der One60 der böse Buhmann !
Per se ist das erstmal ein Router und keine Bridge:
http://extranet.oneaccess-net.com/download/one60/ONE60_install_manual_d ...
Wenn du am Bintec Port eine öffentliche IP hast also keine RFC 1918 IP, dann ist davon auszugehen das der Router einfach nur das /29er Subnetz an den Bintec Port vollkommen transparent routet.
Damit müsste dann auch IPsec Traffic dort sauber ankommen.
Besser (und sicherer zum wissen) wär das wenn du das mit einem Wireshark Sniffer mal verifizierst !! Im Router Log sieht man sowas aber auch...
Macht der One60 Router aber NAT in Richtung Bintec, dann ists aus mit IPsec, denn ohne aktives NAT Traversal und Port Forwarding ist ein NAT Port nicht zu überwinden für IPsec.
Das gilt es also rauszufinden für dich !!
Routet der One 60 transparent nur das Subnetz liegt es wieder an dir und deinen Routern bzw. der Konfiguration, das ist dann auch klar.
Company Connect überträgt immer IPsec (in der Regel) denn Firmen nutzen üblicherweise VPNs !!
Es bleibt dabei: Ohne Debug Output und Log vom Bintec kommen wir nicht viel weiter...
Eigentlich muss ich mich nicht rechtfertigen, aber damit Du Dir evtl. Deinen nächsten "Oberlehrer-Kommentar" verkneifst... natürlich habe ich auch Remotezugriff auf die Router, aber ich will/kann gerade nicht, da der Deiner Meinung nach nicht mitdenkende Netzwerker eigentlich Urlaub hat und sich mit dem Thema derzeit gar nicht auseinandersetzen müsste. Aber der Gedanke daran (Apropos mitdenken...) lässt ihn einfach nicht los und so hat er sich seinen Tablet geschnappt und hier mal gepostet, um evtl. ein paar Hinweise zu erhalten und ein wenig Brainstorming zu betreiben. Stattdessen darf er sich aber hauptsächlich mit überheblichen und besserwisserischen Kommentaren rumschlagen...
Wenn Dir manche Fragen zu einfach gestrickt erscheinen, dann zwingt Dich ja niemand, darauf zu antworten, aber wenn Du es doch tust, dann erwidere doch höfliche Anfragen bitte in demselben höflichen Ton! Ich hätte auch nicht erwartet, dass ich bei einem Experten für IPSec bei "A" anfangen muss statt einfach nur darlegen zu können, dass alle sonstigen Parameter unverändert und damit ok sind. Dass Phase 1 und 2 sich unterscheiden, ist übrigens Historie, nicht von mir eingerichtet und ich wollte eben jetzt nicht alles auf einmal ändern. Optimieren kann ich immer noch!
Ich weiß auch, dass der One60 eigentlich ein Router ist, den Hinweis, dass er bei CC als Bridge betrieben wird, habe ich aus dem Internet, AFAIR sogar hier aus dem Forum, bin mir nicht mehr sicher... Aber ich werde dann erst einmal den One60 als Buhmann betrachten und das verfolgen, sogar mit Logs...
Sorry, dass ich auch mal meinem Unmut Luft gemacht habe...
...also dennoch vielen Dank für die Hinweise!
Wenn Dir manche Fragen zu einfach gestrickt erscheinen, dann zwingt Dich ja niemand, darauf zu antworten, aber wenn Du es doch tust, dann erwidere doch höfliche Anfragen bitte in demselben höflichen Ton! Ich hätte auch nicht erwartet, dass ich bei einem Experten für IPSec bei "A" anfangen muss statt einfach nur darlegen zu können, dass alle sonstigen Parameter unverändert und damit ok sind. Dass Phase 1 und 2 sich unterscheiden, ist übrigens Historie, nicht von mir eingerichtet und ich wollte eben jetzt nicht alles auf einmal ändern. Optimieren kann ich immer noch!
Ich weiß auch, dass der One60 eigentlich ein Router ist, den Hinweis, dass er bei CC als Bridge betrieben wird, habe ich aus dem Internet, AFAIR sogar hier aus dem Forum, bin mir nicht mehr sicher... Aber ich werde dann erst einmal den One60 als Buhmann betrachten und das verfolgen, sogar mit Logs...
Sorry, dass ich auch mal meinem Unmut Luft gemacht habe...
...also dennoch vielen Dank für die Hinweise!
Na ja wenn du schon diese ganze nicht fachspezifische Umfeld im Netzwerk in einem Fach Forum für Administratoren freiwillig schilderst will da schon manchmal der Oberlehrer durchbrechen....
Und wer dann noch zugibt im Urlaub zu arbeiten wo man sich erholen soll dem ist nicht mehr zu helfen...fass dir also mal an die eigene Nase ! Du solltest dich dann mal fragen ob du für einfach mal Brainstormen im richtigen Forum bist wenn du dedizierte Fachfragen stellst die aber zwingend eine recht genaue Analyse und einen dedizierten Log oder Debugg Output erfordern da sie schon komplexer sind als eine simple IP Adresse eingeben.
Aber Mist...da war er doch wieder der Oberlehrer den du aber auch ganz gut geben kannst. Willkommen also im Club !
Da hast du...oder vielleicht auch wir hier...eine vollkommen falsche Erwartungshaltung, keine Frage. Wenns dir also nur ein bischen ums IPsec Plauschen und Brainstormen geht ist OK aber dann kommunizier das bitte auch so.
Du solltest wenigstens mal so fair sein und dich in remote Hilfesteller versetzen die weder dich, deine Intention, dein Umfeld, dein technische KnowHow und auch nicht deine Mimick sehen können um zu erahnen, erraten oder was auch immer was die Ursache ist. Also fair bleiben...Oberlehrer können und kennen wir alle hier nur zu gut.
Luft machen darf man sich immer wenns hilft...
Aber egal Schwamm drüber...andere Baustelle...anderes Thema !
Auf Internet Äußerungen sollte man sich besser nicht verlassen. Um ganz sicher zu gehen sniffer und check ob IPsec Pakete am Port dort ankommen !
Alternativ ruf die Hotline an von CC und frag nach. Das hast du ein Recht drauf als Business Kunde !!
Damit hast du wenigstens sichere Fakten an der Hand und musst nicht spekulieren.
Und wer dann noch zugibt im Urlaub zu arbeiten wo man sich erholen soll dem ist nicht mehr zu helfen...fass dir also mal an die eigene Nase ! Du solltest dich dann mal fragen ob du für einfach mal Brainstormen im richtigen Forum bist wenn du dedizierte Fachfragen stellst die aber zwingend eine recht genaue Analyse und einen dedizierten Log oder Debugg Output erfordern da sie schon komplexer sind als eine simple IP Adresse eingeben.
Aber Mist...da war er doch wieder der Oberlehrer den du aber auch ganz gut geben kannst. Willkommen also im Club !
Da hast du...oder vielleicht auch wir hier...eine vollkommen falsche Erwartungshaltung, keine Frage. Wenns dir also nur ein bischen ums IPsec Plauschen und Brainstormen geht ist OK aber dann kommunizier das bitte auch so.
Du solltest wenigstens mal so fair sein und dich in remote Hilfesteller versetzen die weder dich, deine Intention, dein Umfeld, dein technische KnowHow und auch nicht deine Mimick sehen können um zu erahnen, erraten oder was auch immer was die Ursache ist. Also fair bleiben...Oberlehrer können und kennen wir alle hier nur zu gut.
Luft machen darf man sich immer wenns hilft...
Aber egal Schwamm drüber...andere Baustelle...anderes Thema !
Auf Internet Äußerungen sollte man sich besser nicht verlassen. Um ganz sicher zu gehen sniffer und check ob IPsec Pakete am Port dort ankommen !
Alternativ ruf die Hotline an von CC und frag nach. Das hast du ein Recht drauf als Business Kunde !!
Damit hast du wenigstens sichere Fakten an der Hand und musst nicht spekulieren.
