7
Ping im statischen Bereich klappt, Ping im DHCP Bereich klappt nicht
Hallo,
ich habe ein Problem, das evtl. mit dem VAMT WMI Problem hier zu tun haben könnte
VAMT 3.1 meldet Fehler Unable to connect to the WMI service on the remote machine
Vom Server aus kann ich alle statischen IP anpingen, auch mit dem DNS-Namen. Alle IP bzw. DNS-Namen die im DHCP Bereich liegen, kann ich plötzlich nicht mehr anpingen (Zeitüberschreitung).
Wie kann das sein?
ich habe ein Problem, das evtl. mit dem VAMT WMI Problem hier zu tun haben könnte
VAMT 3.1 meldet Fehler Unable to connect to the WMI service on the remote machine
Vom Server aus kann ich alle statischen IP anpingen, auch mit dem DNS-Namen. Alle IP bzw. DNS-Namen die im DHCP Bereich liegen, kann ich plötzlich nicht mehr anpingen (Zeitüberschreitung).
Wie kann das sein?
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: 228783
Url: https://administrator.de/contentid/228783
Printed on: April 18, 2024 at 16:04 o'clock
7 Comments
Latest comment
Hi,
können "die Dynamischen" den Server pingen?
Firewall-Regeln?
Dynamisch versorgte Clients sind im selben Subnet wir der Server? Falls ja, haben sie tatsächlich die selbe Netzwerk-Maske? Und sind im selben logischen Netz?
Post bitte mal:
ipconfig vom Server
ipconfig eines dynamisch versorgten Clients
DHCP-Konfig
E.
können "die Dynamischen" den Server pingen?
Firewall-Regeln?
Dynamisch versorgte Clients sind im selben Subnet wir der Server? Falls ja, haben sie tatsächlich die selbe Netzwerk-Maske? Und sind im selben logischen Netz?
Post bitte mal:
ipconfig vom Server
ipconfig eines dynamisch versorgten Clients
DHCP-Konfig
E.
Bereich stimmen definitiv, am System wurde dort nichts geändert.
192.168.1.1 - .50 (hier sind die ganzen statischen IP vergeben wie Firewall, Server, Printserver usw.)
192.168.1.100 - .150 (DHCP für Clients)
255.255.255.0
Vom Client aus kann ich alles anpingen, statische, dynamische und DNS Einträge. So wie es sein soll.
Gateway und DNS Einträge stimmen dort auch.
Vom Server aus kann ich nur die statischen IP / DNS Namen anpingen. Ich mach später noch einen screenshot.
192.168.1.1 - .50 (hier sind die ganzen statischen IP vergeben wie Firewall, Server, Printserver usw.)
192.168.1.100 - .150 (DHCP für Clients)
255.255.255.0
Vom Client aus kann ich alles anpingen, statische, dynamische und DNS Einträge. So wie es sein soll.
Gateway und DNS Einträge stimmen dort auch.
Vom Server aus kann ich nur die statischen IP / DNS Namen anpingen. Ich mach später noch einen screenshot.
Warum nimmst du dir nicht einen kostenlosen Wireshark oder MS Netmonitor und snifferst mal WO diese ICMP (Ping) Pakete bleiben und ob sie überhaupt vom Absender ins LAN gehen und auch am Empfänger ankommen und ob der überhaupt antwortet.
Dann weisst du doch in 3 Minuten sofort was los ist !
Dann weisst du doch in 3 Minuten sofort was los ist !
Gute Idee. Nur habe ich da kaum Ahnung.
Also, bei MS Netmonitor sehe ich ICMP Protokollmeldungen, wenn ich von meinem Client-PC aus einen anderen Client-PC im DHCP Bereich anpinge. Nur kann ich damit leider nichts anfangen. Oder muss ich einen speziellen Filter einstellen?
- Ipv4: Src = 192.168.92.104, Dest = 192.168.92.101, Next Protocol = ICMP, Packet ID = 14177, Total IP Length = 60
+ UINT8 Versions: IPv4, Internet Protocol; Header Length = 20
+ UINT8 DifferentiatedServicesField: DSCP: 0, ECN: 0
UINT16 TotalLength: 60 (0x3C)
UINT16 Identification: 14177 (0x3761)
+ UINT16 FragmentFlags: 0 (0x0)
UINT8 TimeToLive: 128 (0x80)
UINT8 NextProtocol: ICMP, 1(0x1)
UINT16 Checksum: 0 (0x0)
IPv4Address SourceAddress: 192.168.92.104
IPv4Address DestinationAddress: 192.168.92.101
Options:
- Icmp: Echo Request Message, From 192.168.92.104 To 192.168.92.101
UINT8 Type: Echo Request Message, 8(0x8)
- EchoReplyRequest: 0x1
UINT8 Code: 0 (0x0)
UINT16 Checksum: 19750 (0x4D26)
UINT16 ID: 1 (0x1)
UINT16 SequenceNumber: 53 (0x35)
BLOB ImplementationSpecificData: Binary Large Object (32 Bytes)
Bzw. ARP:
Frame: Number = 30, Captured Frame Length = 60, MediaType = ETHERNET
- Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-19-]
- MacAddress DestinationAddress: *BROADCAST [FF-FF-FF-FF-FF-FF]
UINT8 Rsv: (111111..)
UINT8 UL: (......1.) Locally Administered Address
UINT8 IG: (.......1) Group address (multicast)
- MacAddress SourceAddress: Fujitsu Siemens Computers 4F11F4 [00-19-]
UINT8 Rsv: (000000..)
UINT8 UL: (......0.) Universally Administered Address
UINT8 IG: (.......0) Individual address (unicast)
UINT16 EthernetType: ARP, 2054(0x806)
BLOB UnknownData: Binary Large Object (18 Bytes)
- Arp: Request, 192.168.92.115 asks for 192.168.92.1
UINT16 HardwareType: Ethernet
UINT16 ProtocolType: Internet IP (IPv4)
UINT8 HardwareAddressLen: 6 (0x6)
UINT8 ProtocolAddressLen: 4 (0x4)
UINT16 OpCode: Request, 1(0x1)
MacAddress SendersMacAddress: 00-19-
IPv4Address SendersIp4Address: 192.168.92.115
MacAddress TargetMacAddress: 00-00-00-00-00-00
IPv4Address TargetIp4Address: 192.168.92.1
Also, bei MS Netmonitor sehe ich ICMP Protokollmeldungen, wenn ich von meinem Client-PC aus einen anderen Client-PC im DHCP Bereich anpinge. Nur kann ich damit leider nichts anfangen. Oder muss ich einen speziellen Filter einstellen?
- Ipv4: Src = 192.168.92.104, Dest = 192.168.92.101, Next Protocol = ICMP, Packet ID = 14177, Total IP Length = 60
+ UINT8 Versions: IPv4, Internet Protocol; Header Length = 20
+ UINT8 DifferentiatedServicesField: DSCP: 0, ECN: 0
UINT16 TotalLength: 60 (0x3C)
UINT16 Identification: 14177 (0x3761)
+ UINT16 FragmentFlags: 0 (0x0)
UINT8 TimeToLive: 128 (0x80)
UINT8 NextProtocol: ICMP, 1(0x1)
UINT16 Checksum: 0 (0x0)
IPv4Address SourceAddress: 192.168.92.104
IPv4Address DestinationAddress: 192.168.92.101
Options:
- Icmp: Echo Request Message, From 192.168.92.104 To 192.168.92.101
UINT8 Type: Echo Request Message, 8(0x8)
- EchoReplyRequest: 0x1
UINT8 Code: 0 (0x0)
UINT16 Checksum: 19750 (0x4D26)
UINT16 ID: 1 (0x1)
UINT16 SequenceNumber: 53 (0x35)
BLOB ImplementationSpecificData: Binary Large Object (32 Bytes)
Bzw. ARP:
Frame: Number = 30, Captured Frame Length = 60, MediaType = ETHERNET
- Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-19-]
- MacAddress DestinationAddress: *BROADCAST [FF-FF-FF-FF-FF-FF]
UINT8 Rsv: (111111..)
UINT8 UL: (......1.) Locally Administered Address
UINT8 IG: (.......1) Group address (multicast)
- MacAddress SourceAddress: Fujitsu Siemens Computers 4F11F4 [00-19-]
UINT8 Rsv: (000000..)
UINT8 UL: (......0.) Universally Administered Address
UINT8 IG: (.......0) Individual address (unicast)
UINT16 EthernetType: ARP, 2054(0x806)
BLOB UnknownData: Binary Large Object (18 Bytes)
- Arp: Request, 192.168.92.115 asks for 192.168.92.1
UINT16 HardwareType: Ethernet
UINT16 ProtocolType: Internet IP (IPv4)
UINT8 HardwareAddressLen: 6 (0x6)
UINT8 ProtocolAddressLen: 4 (0x4)
UINT16 OpCode: Request, 1(0x1)
MacAddress SendersMacAddress: 00-19-
IPv4Address SendersIp4Address: 192.168.92.115
MacAddress TargetMacAddress: 00-00-00-00-00-00
IPv4Address TargetIp4Address: 192.168.92.1
Gute Idee. Nur habe ich da kaum Ahnung.
Keine guten Voraussetzungen fürs Troubleshooting 
Hast du keinen der diese hat und dir helfen kann ?!Das erste Paket 192.168.92.104, Dest = 192.168.92.101, Next Protocol = ICMP ist ein ICMP Echo Request also eine Ping Anfrage !
Der Rechner 192.168.92.104 sendet diese also raus an den Zielrechner 192.168.92.101.
Jetzt solltest du nur nochmal an 192.168.92.101 checken ob dort dieses Paket auch ankommt und ob 192.168.92.101 darauf mit einem ICMP Echo Reply antwortet bzw. raussendet !!
Das wäre nämlich die Ping Antwort an 192.168.92.104 ?!
Fazit: Weitersniffern....
Vielen Dank für die tollen Beiträge.
Das Problem ist gefunden, es lag an der neuen Version der F-Secure Firewall.
Dort wurden ein paar Sachen zu viel blockiert.
Nun klappt wieder alles wie es soll!
Interessanterweise ist damit auch das WMI Problem der VAMT gelöst, siehe meine Frage hier:
VAMT 3.1 meldet Fehler Unable to connect to the WMI service on the remote machine
Danke!
Das Problem ist gefunden, es lag an der neuen Version der F-Secure Firewall.
Dort wurden ein paar Sachen zu viel blockiert.
Nun klappt wieder alles wie es soll!
Interessanterweise ist damit auch das WMI Problem der VAMT gelöst, siehe meine Frage hier:
VAMT 3.1 meldet Fehler Unable to connect to the WMI service on the remote machine
Danke!
Klassischer Fehler wenn man überflüssige und sinnfreie zusätzliche Firewalls installiert unter Winblows.
Gut wenns nun klappt wie es soll.
Gut wenns nun klappt wie es soll.
