Zum Inhalt springen

Erfahrungen mit T-Com Sinus 154 DSL Basic SE


Chief Wiggum

Empfohlene Beiträge

Moin!

Folgender Fall:

Kunde beauftragt bei T-Com DSL und Router, T-Com Geschäftskundenbetreuung stellt denen einen Wlan-Router Sinus 154 DSL Basic SE hin, obwohl alles über Kat5 läuft. Wlan wird vom Techniker vor Ort deaktiviert, ich bin auch dabei, installiere auf den Clients IP gebunden auf die Nic, da das vorher in einem Novell-Netz nicht gebraucht wurde (IPX/SPX).

Router geht, nachdem alle Einträge funktionieren, nur macht der, wenn die "Firewall"-Funktion eingeschaltet wird, komplett dicht, also mehr als ein Ping oder Tracert geht nicht raus. Auch eine Art von Sicherheit. Deaktiviere ich die Firewall, komm ich natürlich raus. Das liegt definitv nicht an den Clients, ich habe dieses Phänomen an allen Rechnern im Netz dort.

T-Com Techniker staunt, ich verstehe die Welt nicht mehr und T-Hotline düdelt nur Musik.

Heute Abend hat der Kollege mich noch angerufen, es scheint wohl so zu sein, dass die Routerfirewall Amok spielt, wenn zuviel "verbotener" Traffic von innen nach aussen will und alles dicht macht. Nun muss ich dazu sagen, dass das ein Netz mit 5 PCs (3 XP, 2 Win98se) und einem Novell5-Server ist. Novell läuft auf IPX, das sollte den Router nicht interessieren, auf den 5 PCs ist jedesmal die Norton Internet Security 2004 installiert, da die vorher mit 5 ISDN-Karten Internet hatten (bitte keine Kommentare).

Dementsprechend sollte doch:

auszugehen sein, dass die Rechner halbwegs sauber sind (Viren und Ähnliches)

und durch die Desktop-Firewall die Gesprächigkeit von XP ein wenig eingegrenzt ist.

Kennt einer von euch so ein Phänomen mit diesem Router-Modell?

BTW: Problemlösung wird wohl werden, dass der T-Com-Techniker seinem Vertriebskollegen vorschlägt, dort einen Router aus dem nicht-SoHo-Bereich zu installieren (entweder der Teledat 830 oder den LanCom i10).

Wie gesagt, ich stehe da und staune... :rolleyes:

Link zu diesem Kommentar
Auf anderen Seiten teilen

@ Hades und Nic: den CT-Test habe ich auch schon gelesen.

Grundlegend kann ich den Testern zustimmen, die Konfig des Routers (auch wenn beim Kunden nur der Basic steht, die sind doch sehr ähnlich) geht ziemlich sauber, in den Firewall-Einstellungen finden sich schöne Einstellmöglichkeiten mit Deny-Lists für einzelne Clients, aber kein Wort über die Stabilität.

Laut dem T-Techniker taucht der Fehler zwar selten auf, ist aber bekannt. Naaaaa toll.

Was mich halt wundert: Ping und Tracert geht weiterhin, nur alles andere ist dicht. Wenn eine Firewall Amok spielt oder abstürtzt, sollte doch der gesamte Trafic gesperrt sein, nicht nur http und die Mailports.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

Sodele, nach ein paar Stunden Ethereal (bzw. Packetyzer) habe ich wenigstens den schuldigen PC gefunden und den User standrechtlich exekutiert.

Kann mir mal einer weiterhelfen bei diesen Phänomenen?

Packetyzer Trace:

Frame 1 (62 bytes on wire, 62 bytes captured)
Frame is marked: False
Arrival Time: Nov 19, 2004 11:25:02.1348274224
Time delta from previous packet: -318.000318000 seconds
Time since reference or first frame: 1238.001238000 seconds
Frame Number: 1
Packet Length: 62 bytes
Capture Length: 62 bytes
Ethernet II, Src: 00:30:05:38:25:df, Dst: 00:30:f1:ea:57:89
Destination: 00:30:f1:ea:57:89 (AcctonTe_ea:57:89)
Source: 00:30:05:38:25:df (FujitsuS_38:25:df)
Source or Destination Address: 00:30:f1:ea:57:89 (AcctonTe_ea:57:89)
Source or Destination Address: 00:30:05:38:25:df (FujitsuS_38:25:df)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.100.104 (192.168.100.104), Dst Addr: 149.160.115.186 (149.160.115.186)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 48
Identification: 0x4ac2 (19138)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x819a (correct)
Source: 192.168.100.104 (192.168.100.104)
Source or Destination Address: 192.168.100.104 (192.168.100.104)
Destination: 149.160.115.186 (149.160.115.186)
Source or Destination Address: 149.160.115.186 (149.160.115.186)
Transmission Control Protocol, Src Port: 2990 (2990), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 0
Source port: 2990 (2990)
Destination port: microsoft-ds (445)
Source or Destination Port: 2990
Source or Destination Port: 445
TCP Segment Len: 0
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 64240
Checksum: 0x1b26 (correct)
Options: (8 bytes)
TCP MSS Option: True
Maximum segment size: 1460 bytes
NOP
NOP
SACK permitted

0000: 00 30 F1 EA 57 89 00 30 05 38 25 DF 08 00 45 00 .0..W..0.8%...E.
0010: 00 30 4A C2 40 00 80 06 81 9A C0 A8 64 68 95 A0 .0J.@.......dh..
0020: 73 BA 0B AE 01 BD DB BA 55 77 00 00 00 00 70 02 s.......Uw....p.
0030: FA F0 1B 26 00 00 02 04 05 B4 01 01 04 02 ...&..........

[/code]

Dieser Müll kommt von einem Rechner, innerhalb von Sekunden rennt der die Ports von 1038 (als offensichtlich niedrigster Port) bis in die 4000er druch, einmal auch auf 46903, die IP-Range ist einmal eine 221.4.x.x, zum anderen 155.33.x.x, zudem wird das gesamte 192.168.x.x-Netz abgegrast. Dass bei dem Traffic der Router dichtmacht, ist klar.

Zudem hatte ich (leider ist da Packetyzer abgestürzt, ich habe kein Log) Anfragen auf die Multicast-Server224.0.1.35 und 224.0.0.22. Wofür ist das?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zudem hatte ich (leider ist da Packetyzer abgestürzt, ich habe kein Log) Anfragen auf die Multicast-Server224.0.1.35 und 224.0.0.22. Wofür ist das?

Die Gruppenadresse 224.0.0.22 wird für IGMPv3 Membership reports verwendet, die beispielsweise die durch IGMPv3 fähige Endsysteme (beispielsweise Windows XP) erzeugt werden. 224.0.1.35 (SVRLOC-DA) ist Dienst zur Service Location von Verzeichnisdiensten (Directory Agents) verwendet. Damit können Clients bestimmte Services innerhalb eines Netzwerkes lokalisieren; üblicherweise wird in diesem Zusammenhang auch noch die 224.0.1.22 (sicher das die zweite Adresse 224.0.0.22 war?) verwendet. Einsatzzweck sind unter anderem Drucker (habt Ihr einen HP-Drucker oder was ähnliches mit Netzwerkschnittstelle im Einsatz?)

Das Logfile zeigt als Destination Port 445, welcher von Windows für "SMB over TCP" verwendet wird. Braucht Ihr das?

Nic

Link zu diesem Kommentar
Auf anderen Seiten teilen

Tag Nic.

HP-Drucker sind nicht im Netz, es laufen dort Kyoceras mit Troysystems Extendnet SX Printserver als remote Printer über IPX/SPX. Netzwerkseitig ist das ein Netware 5.x-Netz unter IPX/SPX, so dass SMB über TCP nicht gebraucht wird. Freigaben auf den Clients sind auch keine da (ausser C$).

Zu den IP-Adressen: kann sein, dass ich mich verschrieben habe, kann auch 224.0.1.22 gewesen sein, wie gesagt, fehlt mir wegen Programmabsturz da das Logfile, wo mir das aufgefallen ist. Es sind mehrere XP-Rechner dort im Netz, von denen nur einer (eben jener 192.168.100.104), der auch den wüsten Traffic macht, auf diese Server zugreifen will.

Momentan blockt der Router Zugriff auf die beiden Server-IPs, ohne dass wir irgendwelche Beeinträchtigungen im Netz hatten.

Danke erstmal für die Erklärung. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...