Wireshark Trace per WAN Schnittstelle

[MaHe]

Hallo,

ich bin noch neu hier und platze direkt mal mit einer, vielleicht nicht ganz so neuen, Frage hier ins Forum rein.

Kurz zu mir, ich bin Operation-Manager bei einem Mittelständischen Dienstleister für Netzwerk und alles was so dran hängt. Wir haben inzwischen mehrere tausend LANCOM Router bei unseren Kunden im Einsatz, und haben uns bislang entweder mit den LANCOM eigenen Tools beholfen, bzw. die Capture Funktion im Web Interface verwendet, die einem ein pcap ins download Verzeichnis des Browsers schiebt.

Da aber manchmal ein live Trace mit Wireshark die bessere Variante ist, habe ich mich dran gemacht die Variante mittels RPCap zu verwenden. Allerdings funktioniert das ganze nicht so wie erwartet.

Ich habe wie bei LANCOM beschrieben das ganze auf dem Router aktiviert :

| LANCOM 1793VA-4G+
| Ver. 10.50.0530RU4 / 10.01.2022
| SN.
| Copyright (c) LANCOM Systems

xxxx-0000, Connection No.: 002 (WAN)


root@xxxx-0000:/
> cd /Setup/Packet-Capture

root@xxxx-0000:/Setup/Packet-Capture
> ls

LCOSCap-Algorithms VALUE: Simple,SHA256,SHA512
LCOSCap-Max.-Capture-Length VALUE: 1472
LCOSCap-Operating VALUE: No
LCOSCap-Port VALUE: 41047
RPCap-Blocking-TCP VALUE: No
RPCap-Operating VALUE: Yes
RPCap-Port VALUE: 2002

Und dann im Wireshark versucht eine Verbindung mit der entfernten Router Schnittstelle herzustellen.
Wir verwenden hier übrigens kein VPN um auf den Router zu kommen, da wir eigene Radius Server Betreiben und die Router bei den Kunden sich bei uns einwählen und, sofern gewünscht, über einen eigenen Internet Breakout dann ins www kommen.
Ich habe also von einem Management Server, auf dem Wireshark installiert ist, direkten Zugriff in Richtung Kunde.
Eine entsprechende Regel für zwischengeschaltet FWs ist auch aktiv und geprüft.
Der Router lehnt meinen Verbindungsversuch über den Port 2002 von Seiten Wireshark aktiv ab.

In dem Fall ist der Kundenrouter sogar einer mit den wenigsten Einstellungen. Er baut lediglich die Verbindung zu uns auf, macht DHCP relay für den Kunden, und ist sonst weitestgehend mit default settings unterwegs.

Ich sehe hier zwei mögliche Probleme. Das eine, ist der Umstand das ich versuche die Verbindung mit dem WAN Interface (WAN IP) herzustellen. Da wie oben zu sehen ist, als connection 002 (WAN) angegeben ist.
Das andere, vielleicht ist meine Wireshark Version zu neu? Der NCAP Treiber hat die Version 1.71 und WS ist die aktuelle 4er Version.

Oder, und das wäre auch meine Frage an die Runde, ich muss noch irgendwas auf dem Router konfigurieren damit es funktioniert, was aber in der offiziellen Doku vielleicht nicht auftaucht?
Für Hinweise wäre ich dankbar.

[Dr.Einstein]

Hab vorhin erst wieder einen Mitschnitt gemacht. Meine Rahmenbedingungen:

- Zugriff über temporär WAN-IPv4 aktiviert / genutzt
- User root
-

Code: Alles auswählen

RPCap-Blocking-TCP           VALUE:   No
RPCap-Operating              VALUE:   Yes
RPCap-Port                   VALUE:   2002

- Wireshark 4.0.10 + 1.71 auf Win10
- LCOS 10.72RU5

Ich denke, damit solltest du deine Abweichung erkennen können bzw das Fehlerbild eingrenzen können. Greift ihr immer via Root-User zu oder habt ihr mehrere lokale Accounts oder nutzt ihr vllt sogar TACACS zur Authentifizerung?

[MaHe]

Danke für die Rückmeldung.

Wir verwenden eigentlich immer den root user. Ich habe auch schon überlegt es mal mit anderen LANCOM Routern zu testen, da wir auch unterschiedliche LCOS Versionen fahren.
Liegt daran das sich manche Kundenwünsche nicht immer direkt mit bestimmten Versionen realisierbar sind.

TACACS nutzen wir im Moment erst bei einem Kunden, wo wir noch Bintec Router verwenden. Aber letztlich stellen wir nach und nach alle Kunden auf LANCOM um und wollen auch breit die Authentifizierung auf TACACS umstellen. Bei einigen verwenden wir auch die LMC.

Der Wireshark läuft auf Windows Server 2022.

Fern Zugriff per WAN ist auf dem Router standardmäßig aktiv. Da die sich bei uns einwählen, haben auch alle Kunden Router feste IP Adressen auf der WAN Schnittstelle.
Ich werde das heute Mal mit weiteren Kunden Routern versuchen die andere LCOS Versionen und Router Typen haben. Sollte es an der LCOS Version liegen, müsste es ja auch mal klappen.

[Dr.Einstein]

Du solltest deinen Versuchsaufbau auch etwas vereinfachen. Nehme ein Notebook vorbei an euren Unternehmensfirewalls. Einfach via Handy-Hotspot und los gehts. Danach kannst du weiterschauen, woran es liegt. Kann mir jedenfalls nicht vorstellen, dass der einfache Aufbau scheitert, unabhängig vom LCOS.

[MaHe]

Das kann ich leider nicht.
Zumindest nicht an der Stelle.
Aber ich habe es mit einem anderen Router Typ noch Mal probiert. Einem 1800er. Der hat für rpcap sogar noch einen Parameter mehr die man auf yes setzen muss.
Da habe ich im Wireshark sogar die Interface Liste bekommen, allerdings als ich LAN1 ausgewählt habe, und den Trace starten wollte, kam wieder die Fehlermeldung seitens der Verbindung.
Aber was mir hier aufgefallen ist, Wireshark hatte automatisch einen Filter drin stehen, das Port 3389 ausgenommen ist.
Da stellt sich mir die Frage ob man neben dem Port 2002 noch einen weiteren benötigt? Eben den 3389?

Für den Port 3389 habe ich in unseren FW's natürlich noch keine Freigabe.

[tobiasr]

3389 ist idr. für Microsoft Remote Desktop reserviert. Ich vermute du bist auf deiner Testmaschine intern per RDP? Dann wird dieser Port gefiltert, damit du überhaupt was siehst, denn sonst ist ja jeder Frame auch noch ein anzuzeigendes Datenpaket.

[MaHe]

Ja, ich bin mit dem Server mit dem ich das mache in der Tat per RDP verbunden.
Nur warum sollte ich im Trace den ich per rpcap vom Router empfange irgendwelche RDP Pakete sehen?

Der Weg ist ja:

Ich -> RDP -> Server | Wireshark über Port 2002 -> FW1 -> FW2 -> Router Kunde Port 2002

Und auf dem Rückweg:

Router Kunde -> FW2 -> FW1 -> Wireshark | Server -> RDP -> Ich

Warum sollte Wireshark hier RDP Pakete filtern die dort eigentlich gar nicht ankommen? Denn das Interface in Richtung Kunde ist nicht das gleiche über das ich auf den Server gehe! Die Wege sind hier Strickt getrennt.

[plumpsack]

Und dann im Wireshark versucht eine Verbindung mit der entfernten Router Schnittstelle herzustellen.
Wir verwenden hier übrigens kein VPN um auf den Router zu kommen, ...

Und genau hier sollten die Alarmglocken leuten !!!