6
Watchguard netzwerk config Problem
Ich habe ein Problem mit einer Watchguard X8500e Netzwerk config.
OS-Version:11.2.1.B260006
Folgende config: Die FB steht zwischen dem Internetrouter und einer internen Firewall. Für die Verbindung zwischen wird jeweils ein /30 Netz genutzt. Ich habe eine Testclient mit dem ich den Internetrouter anpingen will.
testclient (10.5.10.118) <=> (10.0.0.1) interne fw interface1 | interne firewall interface 2 (A.B.C.13/30) <=> (A.B.C.14/30) Fireware trusted Interface eth1 | (A.B.C.17/30) Fireware external Interface eth0 <=> (A.B.C.18/30) Internetrouter internal Interface | (A.B.C.D) Internetrouter Provider Interface.
Die Fireware hat also kein Interface in 10/8 aus dem die Anfrage des Clients kommt. Statt dessen gibt es passende Routingeinträge (10/8) wird zur internen Firewall geroutet.
Ping Firewall Rule:
ping from (any-trusted, any-optinal, testpc) to any icmp type8 code 255 no NAT.
An dieser Stelle sollte also ein Ping zum Internetrouter durchgehen.
Debugging:
Ein tcpdump auf dem internen Interface der Fireware (eth1) zeigt die ping Anfrage. Ein tcpdump auf dem externen Interface (eth0) zeigt kein Paket vom testclient.
NAT habe ich für die Ping Rule erstmal ausgeschaltet.
Hat irgendwer vielleicht eine Idee, was das falsch sein kann?
Danke
Peter
OS-Version:11.2.1.B260006
Folgende config: Die FB steht zwischen dem Internetrouter und einer internen Firewall. Für die Verbindung zwischen wird jeweils ein /30 Netz genutzt. Ich habe eine Testclient mit dem ich den Internetrouter anpingen will.
testclient (10.5.10.118) <=> (10.0.0.1) interne fw interface1 | interne firewall interface 2 (A.B.C.13/30) <=> (A.B.C.14/30) Fireware trusted Interface eth1 | (A.B.C.17/30) Fireware external Interface eth0 <=> (A.B.C.18/30) Internetrouter internal Interface | (A.B.C.D) Internetrouter Provider Interface.
Die Fireware hat also kein Interface in 10/8 aus dem die Anfrage des Clients kommt. Statt dessen gibt es passende Routingeinträge (10/8) wird zur internen Firewall geroutet.
Ping Firewall Rule:
ping from (any-trusted, any-optinal, testpc) to any icmp type8 code 255 no NAT.
An dieser Stelle sollte also ein Ping zum Internetrouter durchgehen.
Debugging:
Ein tcpdump auf dem internen Interface der Fireware (eth1) zeigt die ping Anfrage. Ein tcpdump auf dem externen Interface (eth0) zeigt kein Paket vom testclient.
NAT habe ich für die Ping Rule erstmal ausgeschaltet.
Hat irgendwer vielleicht eine Idee, was das falsch sein kann?
Danke
Peter
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: 141301
Url: https://administrator.de/contentid/141301
Printed on: April 18, 2024 at 02:04 o'clock
6 Comments
Latest comment
ICMP Typ 8 ist ja nur die halbe Miete und fürht logischerweise nicht zum (vollen) Erfolg !!! Also der Echo requst geht durch aber du musst ja wenigstens auf dem Rückweg noch den ICMP Typ 0 erlauben (Echo Reply) sonst kommt die Antwort (Typ 0) niemals an am Absender !!
http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
Sieht dein Testszenario so aus: ??
Wenn dem so ist du wirklich KEIN NAT machst auf den FWs, also sauberes, transparentes Routing, dann muss natürlich der Internet Router eine statische Route haben:
Zielnetz: 10.0.0.0, Maske: 255.0.0.0, Gateway: 172.16.1.17
..dann die externe Firewall entsprechend:
Zielnetz: 10.0.0.0, Maske: 255.0.0.0, Gateway: 172.16.1.13
Für den Rückweg verwendst du vermutlich ein default Gateway auf den FWs, oder ??
Wenn dem so ist dann dann ist nur der ICMP Typ 0 Filter der der dich zu Fall bringt !!
http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
Sieht dein Testszenario so aus: ??
Wenn dem so ist du wirklich KEIN NAT machst auf den FWs, also sauberes, transparentes Routing, dann muss natürlich der Internet Router eine statische Route haben:
Zielnetz: 10.0.0.0, Maske: 255.0.0.0, Gateway: 172.16.1.17
..dann die externe Firewall entsprechend:
Zielnetz: 10.0.0.0, Maske: 255.0.0.0, Gateway: 172.16.1.13
Für den Rückweg verwendst du vermutlich ein default Gateway auf den FWs, oder ??
Wenn dem so ist dann dann ist nur der ICMP Typ 0 Filter der der dich zu Fall bringt !!
Ich glaube nicht, daß die ping firewall Regel mein Problem ist. Ich habe trotzdem mal eine any rule gebaut in der Form "from any to any port any" und die ping rule disabled.
Im Grunde sieht meine config so aus, wie in dem Bild beschrieben. Die Netze zwischen der internen und der externen Firewall sowie zwischen der externen Firewall und dem Router kommen aus einem anderen Adreßbereich, aber das sollte das Problem nicht sein.
Auf dem Router ist natürlich ein Routing entsprechend eingestellt, genauso auf der externen Firewall.
Wenn mein ping die externe Firewall verlassen würde (also es nur an dem Rückweg scheitern würde) müßte ich auf eth0 der extenen Firewall mittels tcpdump irgendwas sehen... Klappt aber nicht. Das ping Paket geht noch auf eth1 der externen Firewall rein aber das war es dann.
Auf dem eingehenden Interface:
1272263644.058961 0:15:17:d9:aa:9b 0:15:17:d9:aa:9b 0800 74: 10.5.10.118 > xx.xx.xx.18: icmp: echo request
Das muß irgendeine Kleinigkeit sein, die ich nicht finde.
Danke trotzdem schonmal.
Im Grunde sieht meine config so aus, wie in dem Bild beschrieben. Die Netze zwischen der internen und der externen Firewall sowie zwischen der externen Firewall und dem Router kommen aus einem anderen Adreßbereich, aber das sollte das Problem nicht sein.
Auf dem Router ist natürlich ein Routing entsprechend eingestellt, genauso auf der externen Firewall.
Wenn mein ping die externe Firewall verlassen würde (also es nur an dem Rückweg scheitern würde) müßte ich auf eth0 der extenen Firewall mittels tcpdump irgendwas sehen... Klappt aber nicht. Das ping Paket geht noch auf eth1 der externen Firewall rein aber das war es dann.
Auf dem eingehenden Interface:
1272263644.058961 0:15:17:d9:aa:9b 0:15:17:d9:aa:9b 0800 74: 10.5.10.118 > xx.xx.xx.18: icmp: echo request
Das muß irgendeine Kleinigkeit sein, die ich nicht finde.
Danke trotzdem schonmal.
Mit tcpdump siehst du aber nur was wenn kein Switch dazwischen ist, das solltest du bedenken ! Im Zweifelsfalle einen Wireshark Sniffer auf einem Hub einschleifen oder einen Mirror Port am Switch setzen !
Wenn du dennoch keine Packete siehst hast du mit Sicherheit ein Konfig Problem auf der Watchguard !! Ohne Config Posting hier kann man aber leider nur raten...
Wenn du dennoch keine Packete siehst hast du mit Sicherheit ein Konfig Problem auf der Watchguard !! Ohne Config Posting hier kann man aber leider nur raten...
Switch? Das eingehende Interface von der Watchguard sieht das Paket (siehe tcpdump output in letzter Mail), das ausgehende Interface der Watchguard *nicht*. Ich mache ein tcpdump auf der Watchguard einmal auf eth0 und einmal auf eth1. Das kann also kein Switch dazwischen sein, oder verstehe ich dich falsch?
Von daher wird es wahrscheinlich ein Konfig Problem sein.
Hier mal die Rules..
Action Name Service From-alias To-alias
Allowed FTP FTP Any-Trusted,Any-Optional Any-External
Allowed WatchGuard Web UI WG-Fireware-XTM-WebUI Any-Trusted Firebox
Disabled Ping Ping Any-Trusted Any
Allowed WatchGuard WG-Firebox-Mgmt Any-Trusted Firebox
Disabled Outgoing TCP-UDP Any-Trusted Any-External
Allowed my-test-Any Any Any Any
Aus meiner Sicht sollte die letzte Rule (my-test-any) greifen.
Danke !!
Von daher wird es wahrscheinlich ein Konfig Problem sein.
Hier mal die Rules..
Action Name Service From-alias To-alias
Allowed FTP FTP Any-Trusted,Any-Optional Any-External
Allowed WatchGuard Web UI WG-Fireware-XTM-WebUI Any-Trusted Firebox
Disabled Ping Ping Any-Trusted Any
Allowed WatchGuard WG-Firebox-Mgmt Any-Trusted Firebox
Disabled Outgoing TCP-UDP Any-Trusted Any-External
Allowed my-test-Any Any Any Any
Aus meiner Sicht sollte die letzte Rule (my-test-any) greifen.
Danke !!
Hmm, wenn niemand mehr ne Idee hat, werde ich wohl mal kommerziellen Support einfangen müssen, ansonsten gehts hier bei uns nicht weiter.
danke trotzdem
danke trotzdem
Lösung:
die interne Firewall, die die Pakete vom testclient gezielt zur Watchguard umgebogen hat (source routing) hatte den falschen next hop gesetzt.
Für Openbsd Nutzer im Detail:
pass in quick on $internes_interface route-to { ($interface_to_watchguard $ip_int_interface_watchguard) } from $testrechner to any
die interne Firewall, die die Pakete vom testclient gezielt zur Watchguard umgebogen hat (source routing) hatte den falschen next hop gesetzt.
Für Openbsd Nutzer im Detail:
pass in quick on $internes_interface route-to { ($interface_to_watchguard $ip_int_interface_watchguard) } from $testrechner to any
