Hallo,
ich habe ein seltsames Problem.
Ich habe eine ganze Reihe von Ports auf diesen PC weitergeleitet.
Zeitweise sind die Ports offen, dann wieder eine zeitlang geschlossen.
Ich teste z.B. mit
http://www.canyouseeme.org/
Ich habe die XP Firewall abgeschaltet - damit kann es nicht zu tun haben.
Die Xp Installation ist erst ein paar Tage alt, ich halte es für unwahrscheinlich, daß sich bereits ein Virus eingenistet hat. Zumal ich das gleiche Problem bereits mit der vorigen Installation von XP hatte. Damals hatte ich den Verdacht, daß es an meiner XP Installatation liegt.
Die Einstellungen in der Port Forwarding Tabelle
z.B.
Anfangsport End-Port Gegenstelle Adresse Map-Port Protokoll Wan-Ad.
538 538 Internet 192.168.1.3 538 TCP+UDP 0.0.0.0
Danke für die Aufmerksamkeit.
Michael
Probleme mit Port Fowarding beim 1821
Moderator: Lancom-Systems Moderatoren
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Hi Michael,
was Du tun kannst, wenn der Port vermeintlich geschlossen ist, auf dem LANCOM einen IP-Router Trace (trace # ip-ro @ "Port: 538") erstellen und schauen, ob die Pakete korrekt weitergeleitet werden. Sollten die Pakete vom Router zum Rechner geschickt werden, so kann man zumindest schon einmal Probleme mit dem LANCOM ausschliessen.
Ciao
LoUiS
was Du tun kannst, wenn der Port vermeintlich geschlossen ist, auf dem LANCOM einen IP-Router Trace (trace # ip-ro @ "Port: 538") erstellen und schauen, ob die Pakete korrekt weitergeleitet werden. Sollten die Pakete vom Router zum Rechner geschickt werden, so kann man zumindest schon einmal Probleme mit dem LANCOM ausschliessen.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Danke für den Hinweis.
Habe mit dem Hyperterminal eine Session gestartet und zeichne diese auf.
Die Rückmeldung war:
IP-Router ON @ "Port 583"
Bisher habe ich allerdings keinen Eintrag im Log, obwohl ich mehrfalls den Port gestestet habe (http://www.canyouseeme.org/). Zur Zeit ist der Port geöffnet.
Habe ich etwas vergessen?
Habe mit dem Hyperterminal eine Session gestartet und zeichne diese auf.
Die Rückmeldung war:
IP-Router ON @ "Port 583"
Bisher habe ich allerdings keinen Eintrag im Log, obwohl ich mehrfalls den Port gestestet habe (http://www.canyouseeme.org/). Zur Zeit ist der Port geöffnet.
Habe ich etwas vergessen?
... ja einen Doppelpunkt, trace # ip-ro @ "Port: 538" hatte ich geschrieben.Habe ich etwas vergessen?
Wenn Du mal kurz ein trace # ip-ro anschaltest und direkt wieder aus, dann wirst Du in den Paketen sehen, das dort die Port Angabe mit dem ":" ist und das muss halt passen, sonst wird nichts angezeigt.Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Das Problem ist gerade wieder da:
Im Log finden sich viele Einttäge (sind das alle wilde Portscans?)
Die relevanten Einträge sehen so aus (gestetet über http://www.canyouseeme.org/) :
(Mein PC hat die lokale IP 192.168.1.3):
[IP-Router] 2009/06/19 00:09:15,710
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 204.16.252.112, Len: 60, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 43809, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:09:15,710
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 204.16.252.112, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 43809, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
[IP-Router] 2009/06/19 00:09:22,980
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 204.16.252.112, Len: 60, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 43835, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:09:22,980
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 204.16.252.112, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 43835, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
Lassen sich daraus irgendwelche Schlüsse ziehen, warum der Port geschlossen ist?
Gruß
Michael
Im Log finden sich viele Einttäge (sind das alle wilde Portscans?)
Die relevanten Einträge sehen so aus (gestetet über http://www.canyouseeme.org/) :
(Mein PC hat die lokale IP 192.168.1.3):
[IP-Router] 2009/06/19 00:09:15,710
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 204.16.252.112, Len: 60, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 43809, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:09:15,710
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 204.16.252.112, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 43809, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
[IP-Router] 2009/06/19 00:09:22,980
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 204.16.252.112, Len: 60, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 43835, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:09:22,980
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 204.16.252.112, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 43835, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
Lassen sich daraus irgendwelche Schlüsse ziehen, warum der Port geschlossen ist?
Gruß
Michael
Hi,
also die Pakete aus Deinem Trace haben aber nichts mit dem urspruenglichen Port 538 zu tun. Hast Du den Trace auch tatsaechlich so gestartet wie beschrieben? Dann duerften die Ausgaben aber gar nicht kommen?
Da sind nur Pakete zu sehen, die von Deinem Rechner abgehend ins Internet geschickt werden und zwar an Port: 19905 der IP 204.16.252.112 und die passenden Antworten dazu.
Kommen in dem Trace keine Ausgaben zu dem Port 538?
Hast Du ggf. irgendwelche Firewall Regeln, in denen Ports gesperrt werden, oder bei IDS und DOS irgendwelche Sperren konfiguriert?
Ciao
LoUiS
also die Pakete aus Deinem Trace haben aber nichts mit dem urspruenglichen Port 538 zu tun. Hast Du den Trace auch tatsaechlich so gestartet wie beschrieben? Dann duerften die Ausgaben aber gar nicht kommen?
Da sind nur Pakete zu sehen, die von Deinem Rechner abgehend ins Internet geschickt werden und zwar an Port: 19905 der IP 204.16.252.112 und die passenden Antworten dazu.
Kommen in dem Trace keine Ausgaben zu dem Port 538?
Hast Du ggf. irgendwelche Firewall Regeln, in denen Ports gesperrt werden, oder bei IDS und DOS irgendwelche Sperren konfiguriert?
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Hallo,
danke für die Antwort.
Sorry, diesmal wollte ich den Port 19905 testen, nicht 538, das hätte ich dazusagen müssen.
Die Windows Firewall war abgeschaltet.
Ich weiss leider nicht, was IDS bzw. DOS Sperren sind - bewußt habe ich soetwas nicht konfiguriert.
Im Attachment habe ich das ganze Log File eingefügt. Das ist etwas länger,
Vielleicht ist das ja aufschlußreicher.
danke für die Antwort.
Sorry, diesmal wollte ich den Port 19905 testen, nicht 538, das hätte ich dazusagen müssen.
Die Windows Firewall war abgeschaltet.
Ich weiss leider nicht, was IDS bzw. DOS Sperren sind - bewußt habe ich soetwas nicht konfiguriert.
Im Attachment habe ich das ganze Log File eingefügt. Das ist etwas länger,
Vielleicht ist das ja aufschlußreicher.
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Hi,
ok, wenn das mit dem Port so richtig ist, dann ist auch das Log fuer den LANCOM soweit richtig. Die Pakete kommen aus dem Internet und werden vom LANCOM korrekt ins LAN weitergeleitet:
[IP-Router] 2009/06/18 23:56:57,660
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 212.98.184.26, Len: 48, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 4135, Flags: S
Route: LAN Tx (INTRANET):
Das Paket kommt von Source "SrcIP: 212.98.184.26" und wird aufs LAN "INTRANET" geschickt: "Route: LAN Tx (INTRANET)", der Empfaenger im LAN ist "DstIP: 192.168.1.3". Soweit fuers LANCOM alles ok. Ich vermute deshalb eher ein Problem auf dem Rechner im LAN. Um dies nun noch zu pruefen, muesstest Du noch mit Wireshark einen Trace auf dem Rechner erstellen und schauen ob die vom LANCOM gesendeten Pakete denn auch am Rechner ankommen.
Ciao
LoUiS
ok, wenn das mit dem Port so richtig ist, dann ist auch das Log fuer den LANCOM soweit richtig. Die Pakete kommen aus dem Internet und werden vom LANCOM korrekt ins LAN weitergeleitet:
[IP-Router] 2009/06/18 23:56:57,660
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 212.98.184.26, Len: 48, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 4135, Flags: S
Route: LAN Tx (INTRANET):
Das Paket kommt von Source "SrcIP: 212.98.184.26" und wird aufs LAN "INTRANET" geschickt: "Route: LAN Tx (INTRANET)", der Empfaenger im LAN ist "DstIP: 192.168.1.3". Soweit fuers LANCOM alles ok. Ich vermute deshalb eher ein Problem auf dem Rechner im LAN. Um dies nun noch zu pruefen, muesstest Du noch mit Wireshark einen Trace auf dem Rechner erstellen und schauen ob die vom LANCOM gesendeten Pakete denn auch am Rechner ankommen.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Wireshark ist eigentlich einfach zu bedienen 
Du waehlst das Netzwerk Interface aus, auf dem Du Pakete mitschneiden willst (wenn mehr als eine Schnittstelle vorhanden ist) und startetst das "Capture". Die Default Einstellungen im Ethereal sollten passen. Dann werden vermutlich viele Pakete durchrasseln, je nach dem was auf deinem Rechner so los ist. Du kannst dann erstmal die Ausgabe filtern auf z.B.: "ip.src == 192.168.1.3" oder "ip.addr == 192.168.1.3 && ip.addr == 204.16.252.112". Dabei schaust Du dann nach, ob die Pakete, die Du oeben auf dem LANCOM gesehen hast (mit den entsprechenden Ports) auch in diesem Capture vom Ethereal siehst.
Ciao
LoUiS
Du waehlst das Netzwerk Interface aus, auf dem Du Pakete mitschneiden willst (wenn mehr als eine Schnittstelle vorhanden ist) und startetst das "Capture". Die Default Einstellungen im Ethereal sollten passen. Dann werden vermutlich viele Pakete durchrasseln, je nach dem was auf deinem Rechner so los ist.
Du kannst dann erstmal die Ausgabe filtern auf z.B.: "ip.src == 192.168.1.3" oder "ip.addr == 192.168.1.3 && ip.addr == 204.16.252.112". Dabei schaust Du dann nach, ob die Pakete, die Du oeben auf dem LANCOM gesehen hast (mit den entsprechenden Ports) auch in diesem Capture vom Ethereal siehst.Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Hi MichaelB63
das Problem ist eindeutig auf deinem PC zu suchen... In deinem trace sieht man, daß die empfanegen Pakete an den PC weitergereicht werden von ihm aber zunächst keine Antwort kommt. Irgendwann reagiert der PC aber doch und lehnt die Pakete explizit ab:
[IP-Router] 2009/06/19 00:08:57,450
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 79.165.47.173, Len: 48, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 59553, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:08:57,460
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 79.165.47.173, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 59553, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
d.h,. auf dem PC lauscht entweder niemand auf dem Port oder es ist eine Desktopfirewall installiert, die den Zugriff blockiert
Gruß
Backslash
das Problem ist eindeutig auf deinem PC zu suchen... In deinem trace sieht man, daß die empfanegen Pakete an den PC weitergereicht werden von ihm aber zunächst keine Antwort kommt. Irgendwann reagiert der PC aber doch und lehnt die Pakete explizit ab:
[IP-Router] 2009/06/19 00:08:57,450
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.3, SrcIP: 79.165.47.173, Len: 48, DSCP/TOS: 0x28
Prot.: TCP (6), DstPort: 19905, SrcPort: 59553, Flags: S
Route: LAN Tx (INTRANET):
[IP-Router] 2009/06/19 00:08:57,460
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 79.165.47.173, SrcIP: 192.168.1.3, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 59553, SrcPort: 19905, Flags: RA
Route: WAN Tx (INTERNET)
d.h,. auf dem PC lauscht entweder niemand auf dem Port oder es ist eine Desktopfirewall installiert, die den Zugriff blockiert
Gruß
Backslash
-
MichaelB63
- Beiträge: 48
- Registriert: 30 Mai 2008, 15:59
Hi MichaelB63
Es gibt folgende Flags:
S bedeutet SYN (SYNchronize) und ist im ersten Paket gesetzt. Der Empfänger wird angewiesen die Sequenznummer des Senders anzunehmen
A bedeutet ACK (ACKnowledge) und bestätigt die Sequenz-Nummer des letzten Pakets.
F bedeutet FIN (FINish) und fordert bzw. bestätigt das Ende einer Session
R bedeutet RST (ReSet) und beendet eine Session sofort.
Eine normale TCP-Session verwendet in den Paketen folgende Flags:
S -> SA -> A (die Verbindung steht und es werden Daten übertragen, ab nun enthalten alle Pakete nur noch das A-Flag)
Wenn eine bestehende Session abgebaut wird, dann werden folgende Flags verwendet
FA -> FA -> A
eine bestehende Session kann zwar auch mit einem einzelnen (und unbestätigten)
RA
beendet werden, jedoch wird das z.B. vom Browser mit einer Fehlermeldung quittiert, weshalb man das R-Flag i.A. nur bei der Ablehnung einer Session verwendet, was dann wie folgt aussieht:
S -> RA
Gruß
Backslash
fast...RA bedeutet rejected?
Es gibt folgende Flags:
S bedeutet SYN (SYNchronize) und ist im ersten Paket gesetzt. Der Empfänger wird angewiesen die Sequenznummer des Senders anzunehmen
A bedeutet ACK (ACKnowledge) und bestätigt die Sequenz-Nummer des letzten Pakets.
F bedeutet FIN (FINish) und fordert bzw. bestätigt das Ende einer Session
R bedeutet RST (ReSet) und beendet eine Session sofort.
Eine normale TCP-Session verwendet in den Paketen folgende Flags:
S -> SA -> A (die Verbindung steht und es werden Daten übertragen, ab nun enthalten alle Pakete nur noch das A-Flag)
Wenn eine bestehende Session abgebaut wird, dann werden folgende Flags verwendet
FA -> FA -> A
eine bestehende Session kann zwar auch mit einem einzelnen (und unbestätigten)
RA
beendet werden, jedoch wird das z.B. vom Browser mit einer Fehlermeldung quittiert, weshalb man das R-Flag i.A. nur bei der Ablehnung einer Session verwendet, was dann wie folgt aussieht:
S -> RA
Gruß
Backslash