2 Probleme mit Bintec R3000; 1. ISDN Verbindung; 2. SSH via Internet

Dieses Thema im Forum "Bintec" wurde erstellt von wolfihe, 14. März 2010.

  1. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    Moin zusammen,

    ich habe 2 Bintec Router, mit denen ich momentan noch via ISDN eine Verbindung zueinander aufbaue, um 2 Netzwerke miteinander zu verbinden. Demnächst wird beides auf DSL & VPN umgestellt, noch bin ich aber nicht soweit.

    Der eine R3000 wurde erst kürzlich in Betrieb genommen und anfangs lief der Verbindungsaufbau zum zweiten R3000 problemfrei.
    Ca. 12h später hatte ich das Problem, dass ich mich von der einen Seite aus nicht mehr verbinden kann.
    Im Debug kommt immer nur ein Hinweis auf normalen Verbindungsaufbau und dann "Disconnect normal call clearing (0x90)".

    Er scheint also die Verbindung "regulär" zu beenden, baut sie anfangs laut Protokoll auch richtig auf, aber ich bekomme keinen einzigen Ping zurück, geschweige denn kann ich mich auf den anderen Router per ssh oder telnet verbinden. ISDNLogin will auch nicht.
    Hat da jemand einen Tipp, was ich testen kann? Zu dem Router, der erst kürzlich in Betrieb gegangen ist, habe ich keine alternative Verbindung. Sprich ich müsste vor Ort hin, was etwas umständlich ist, aber wohl nicht zu vermeiden ist.

    Da beide Router auch über eine DSL Verbindung verfügen, würde ich als 2. gerne die Möglichkeit haben, über SSH und Internet auf die Geräte zu können. Leider konnte ich den Funkwerk-Infos nicht ganz eindeutig entnehmen, ob SSH nur vom LAN aus geht oder ob das über Inet auf möglich ist. Weiß da jemand mehr?
     
  2. mvmmgda

    mvmmgda Kenner

    Registriert seit:
    16. Februar 2010
    Beiträge:
    99
    Punkte für Erfolge:
    6
    Hallo wolfihe,

    fangen wir mit dem 2. an:
    Natürlich kannst Du (falls die Keys generiert wurden) von überall her eine Verbindung mit SSH aufbauen. Das bedingt aber normalerweise von der WAN Seite her eine Freigabe in der NAT(die Firewall muss es sowieso erlauben, ansonsten läuft auch nix).

    Beim ersten Problem würde es helfen mal die Softwarestände der Router zu kennen und den kompletten debug eines Verbindungsaufbaues. Wurde über Setup Tool (telnet/ssh/serial) konfiguriert oder über FCI (HTML)? Hängen die Router direkt am NTBA oder hinter einer Telefonanlage?

    Was ist denn im "incoming call answering" eingetragen, dass isdnlogin nicht funktioniert?

    Fragen über Fragen

    hat

    MvmmgdA
     
  3. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    Hey,
    Danke mal vorab für Deine Antwort.

    Zu SSH:
    Die Keys wurden generiert, der betroffene Bintec baut selbst die WAN Verbindung auf. Muss ich dann dennoch NAT anpassen? NAT ist doch für die Geräte hinter dem WAN-Router, oder habe ich da was falsch verstanden?
    Die Firewall, sprich SIF muss ich wohl tatsächlich noch anpassen, das muss ich mir in Ruhe nochmal ansehen.

    Zur ISDN Verbindung:
    Konfiguriert wurden beide Geräte via telnet.
    Der Router an Standort A ist der, den es schon länger gibt und der versucht eine Verbindung zu B aufzubauen. Dieser hängt hinter einer TK-Anlage.
    Der Router an Standort B ist eben neu und hängt an der NTBA direkt. Ob die Verbindung von B nach A gehen würde, weiß ich aktuell nicht, da ich das nur von B aus testen kann.
    Incoming Call Answering SOLLTE auf PPP und ISDN Login stehen, aber da ich aktuell nicht auf Router B komme, kann ich es spontan nicht prüfen.
    Router B müsste v.7.5 Rev.1 Patch 6 sein,
    Router A ist 7.4 Rev. 3 Patch 9.
     
  4. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    Nachtrag:
    Ich habe gerade versucht von Router A eine Verbindung zu Router C aufzubauen, das ist ebenfalls ein Bintec R3000, der jedoch schon wesentlich länger in Betrieb ist. Auch dort bekomme ich ein erfolgreiches Dial Up, ein "outgoing connection established" und dann ein "outgoing connection closed. duration 59sec, 120bytes received, 250bytes sent ..." und "stack 0: disconnect cause: normal call clearing (0x90)"

    Das lässt mich hoffen, dass es an Router A liegt (gleiches Fehlverhalten), denn an den komme ich besser dran als an Router B.
     
  5. amigalover

    amigalover Stammgast

    Registriert seit:
    25. September 2008
    Beiträge:
    73
    Punkte für Erfolge:
    6
    Das hast Du wohl. NAT ist auf der WAN-Schnittstelle aktiv, also bevor ein Paket in die Routerlogik eintrifft (kannst ja mal nen "debug all" auf der Konsole einschalten und dann siehst Du die "NAT refused" Meldungen).
    Alles was nicht von innen her (hinter der NAT) initiiert worden ist, wird geblockt. Außer eben Du machst dafür Portforwardings und leitest die Soße an den Router direkt (LOCAL) oder einen Host im Netz weiter.

    Gruß
     
  6. amigalover

    amigalover Stammgast

    Registriert seit:
    25. September 2008
    Beiträge:
    73
    Punkte für Erfolge:
    6
    Uuiiii, nichts gegen Bintec, aber hier würde ich definitiv mal eine neuere Firmware draufziehen. Du mußt auch immer einen Bug im Hinterkopf haben (und dann suchst Du Dir nen Wolf ^^ wegen des Fehlers).

    Also isdnlogin ist nur für den Fernzugriff auf einen Router per ISDN gedacht, da nimmst Du das entsprechende Item "ISDN Login". Willst Du zwei Geräte miteinander einwählen lassen und die Netze verbinden, nimmst Du "PPP (routing)". Auf PPP und ISDN Login gleichzeitig sollte nicht gehen, kannst ja mal Deine Incoming Call Answering Einträge posten.
    Ach und am besten gleich noch die Ausgabe von "debug all&" damit man ggf. sieht was an Ruf rein- bzw. rausgeht.

    Gruß
     
  7. mvmmgda

    mvmmgda Kenner

    Registriert seit:
    16. Februar 2010
    Beiträge:
    99
    Punkte für Erfolge:
    6
    Hallo wolfihe,

    da auf den Router von "aussen" zugegriffen werden soll und NAT standardmaessig ALLES blockt, fuer das keine NAT-Session (aufgebaut von "innen") besteht, ist eine NAT-Freigabe für den Zugriff aus dem Internet zwingend notwendig.
    Funktioniert im Setup Tool (setup auf der SNMP-shell) folgendermassen:
    IP -> Network Address Translation
    Jetzt den entsprechenden WAN-Partner auswaehlen (NAT steht auf on) und im folgenden Menue auf "requested from OUTSIDE" gehen.
    Der Eintrag sollte dann ungefaehr so aussehen:

    R4100 Setup Tool Funkwerk Enterprise Communications GmbH
    [IP][NAT][EDIT][OUTSIDE][ADD]: NAT - sessions from OUTSIDE R4100
    ____________________________________________________________________________

    Description SSH
    Service user defined
    Protocol tcp

    Remote Address
    Remote Mask


    External Address
    External Mask
    External Port specify Port 22

    Internal Address 127.0.0.1
    Internal Mask 255.255.255.255
    Internal Port specify Port 22

    SAVE CANCEL
    ____________________________________________________________________________

    Mit diesem Eintrag wird aller Traffic TCP/22 der auf dem WAN-Partner-Interface "auftrifft" an den Router selber weitergeleitet.

    Damit sollte der SSH-Zugang aus dem Internet abgefruehstueckt sein (die Default Route sollte natuerlich auch ueber dieses Interface wieder ins Internet zeigen) .

    Viel Erfolg wünscht

    MvmmgdA
     
  8. amigalover

    amigalover Stammgast

    Registriert seit:
    25. September 2008
    Beiträge:
    73
    Punkte für Erfolge:
    6
    Morgens halb Zehn in Deutschland? Na dann Mahlzeit auch :D

    Gruß *in Knoppers beiss*
     
  9. mvmmgda

    mvmmgda Kenner

    Registriert seit:
    16. Februar 2010
    Beiträge:
    99
    Punkte für Erfolge:
    6
    @amigalover.
    War Brezn, is aber schon wech .. :cool:

    *Kaffee_schluerf*
     
  10. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    Danke für eure Hinweise und Infos.

    Der SSH Zugang klappt mittlerweile immerhin, das ist schonmal viel wert. Die SIF muss ich für SSH dann gar nicht anpassen? Nur NAT?


    Zur ISDN Problematik:
    Ich war heute morgen jetzt nochmal an Standort B vor Ort und habe den Router neu eingerichtet. Ich bin wirklich komplett gehangen und habe NICHT herausgefunden, warum er mir den Zugriff von Standort A nicht zulässt. Ich habe den Router dann vollständig zurückgesetzt und neu eingerichtet und der Zugriff funktionierte auf Anhieb.
    Der Witz ist: Ich bin dann wieder abgefahren und habe es eben von Standort A aus getestet: Zugriff geht nicht.
    Debug vom Router A spuckt bei Verbindungsversuch aus:
    Code:
    13:28:06 INFO/INET: dialup if 10002 prot 6 10.0.40.4:8266->192.168.103.1:23
    13:28:06 DEBUG/PPP: stroh_ma: event: 3, status: 0 (5) -> 1 (5)
    13:28:06 DEBUG/PPP: stroh_ma: dial number <XXXXXXXXX>
    13:28:06 DEBUG/ISDN: stack 0: activate
    13:28:07 DEBUG/PPP: layer 1 type hdlc, 64000 bit/sec
    13:28:27 DEBUG/PPP: stroh_ma: event: 11, status: 1 (5) -> 7 (8)
    13:28:27 INFO/PPP: stroh_ma: interface is blocked for 10 seconds
    13:28:27 DEBUG/ISDN: stack 0: disconnect cause: normal call clearing (0x90)
    13:28:37 DEBUG/PPP: stroh_ma: event: 27, status: 7 (8) -> 0 (5)
    13:28:37 INFO/PPP: stroh_ma: interface is unblocked after 10 seconds
    13:28:37 DEBUG/PPP: stroh_ma: event: 2, status: 0 (5) -> 0 (5)
    13:28:57 DEBUG/ISDN: stack 0: deactivate
    13:29:12 INFO/INET: dialup if 10002 prot 6 10.0.40.4:8319->192.168.103.1:23
    13:29:12 DEBUG/PPP: stroh_ma: event: 3, status: 0 (5) -> 1 (5)
    13:29:12 DEBUG/PPP: stroh_ma: dial number <XXXXXXXX>
    13:29:12 DEBUG/ISDN: stack 0: activate
    13:29:13 DEBUG/PPP: layer 1 type hdlc, 64000 bit/sec
    13:29:33 DEBUG/PPP: stroh_ma: event: 11, status: 1 (5) -> 7 (8)
    13:29:33 INFO/PPP: stroh_ma: interface is blocked for 10 seconds
    13:29:34 DEBUG/ISDN: stack 0: disconnect cause: normal call clearing (0x90)
    13:29:43 DEBUG/PPP: stroh_ma: event: 27, status: 7 (8) -> 0 (5)
    13:29:43 INFO/PPP: stroh_ma: interface is unblocked after 10 seconds
    13:29:43 DEBUG/PPP: stroh_ma: event: 2, status: 0 (5) -> 0 (5)
    13:30:04 DEBUG/ISDN: stack 0: deactivate
    
    Nicht böse sein, Tel. Nr. habe ich absichtlich unkenntlich gemacht :)

    Das einzige, was mir jetzt gerade noch einfällt: Es gab nachdem ich weggefahren bin, einen Versuch von einer Drittfirma, die eine spezielle Software betreut, via ISDN sich zu verbinden. Deren ISDN Verbindung ist als WAN Partner eingerichtet, Rufnummern entsprechend konfiguriert und die IP Settings sind auf "DYNAMIC Server" eingestellt, sprich deren Client wird vom R3000 eine IP zugewiesen. So zumindest die Theorie...Der Verbindungsversuch war anscheinend nicht erfolgreich. Warum habe ich bisher noch nicht herausgefunden; debug war ja leider schon wieder nicht mehr verfügbar.


    Die Firmware wird bald aktualisiert...ich kann nur gar nicht so einfach überall was einspielen, wenn ich nicht per Fernwartung drauf komme ;)
    Wenn es gar nicht geht, muss ich halt vorab nochmal eine Runde mit dem Auto drehen und jeweils local aktualisieren. Die Anleitung aus dem Handbuch habe ich mir diesbezüglich schonmal angesehen, doch die hat mich ehrlich gesagt verwirrt, da die dort beschriebene Updatemöglichkeit für mich nicht auffindbar ist.

    Grüße
     
  11. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    Update:
    Update OK! :D

    Ich habe jetzt bei allen beteiligten Geräten die Firmware 7.9 Rev. 2 drauf.

    SSH an Standort B konnte ich aktivieren, nachdem ich via Telefon einen Mitarbeiter dazu gebracht habe, einen Ping nach Standort A zu senden. Dann hat B nach A aufgebaut und nicht umgekehrt - und es ging.
    Jetzt habe ich auch den Output von Router B, wenn A versucht sich bei ihm einzuwählen; das ist ja das, was nicht funktioniert, siehe oben "disconnect cause: normal call clearing".
    Code:
    15:21:47 DEBUG/PPP: dialin from <> to local number <XXXXXXXX> (7/0)
    15:21:47 ERR/PPP: dispatch item missing
    
    Kann damit jemand etwas anfangen?
     
  12. wolfihe

    wolfihe Gelegenheits-User

    Registriert seit:
    14. März 2010
    Beiträge:
    10
    Punkte für Erfolge:
    1
    OK, sorry für den voreiligen Post.

    Scheint daran zu liegen, dass ich bei incoming calls die Nummer beim Rumtesten mit Vorwahl eingetragen hatte.
    Zumindest taucht der Fehler aktuell nicht mehr auf, ich hoffe das bleibt so.

    Nächstes Thema wird dann Sperrung von http Zugriffen an Standort B und die Umstellung auf VPN, wobei ich da vorher bei Standort A noch ein paar VLAN Konfigurationen durchführen muss.

    Grüße