11
ISA Server 2004 als Front Firewall konfigurieren
Hallo.
Ich habe mal wieder ein Problem mit nem ISA Server. Es geht darum, dass dieser eine Art front Firewall darstellen soll. Es soll ein externes Netz geben (192.168.10/24), ein Unternehmensnertzwerk (192.168.0/24) und ein weiteres durch nen Router abgegrenztes Testnetzwerk (172.16/16). Der ISA hat die Adressen 192.168.1.2 und 192.168.0.253. Der Router der zum Übergang ins andere Netz gehen soll hat die Adresse 192.168.0.254. Ich hab jetzt am ISA schon ne neue Konfiguration basierend auf der Frontfirewall eingerichtet. Dann noch ein neues Netzwerk angelegt (intern dann) und eine Netzwerregel eingefüggt und auch noch ne Firrewallregel. (und das ganze erst mal alles durchlassen, ist ja nur testweise.) Dann hab ich noch eine route in die lokale Routingtabelle eingefügt, dass 172.16.0.0 an 192.168.0.254 geleitet wird. Aber es kommt immer fehlgeschlagene Verbindung. Kann mir jemand sagen, was ich noch einstellen muss? Hab sogar schon ne Testversion vom enterprise server runtergeladen und installiert, weil ich gelesen habe, dass das nur mit dem Enterprise geht. Bin dankbar über jeden guten Ratschlag (der nicht nur "such doch mal bei Google" beinhaltet).
Danke
Ich habe mal wieder ein Problem mit nem ISA Server. Es geht darum, dass dieser eine Art front Firewall darstellen soll. Es soll ein externes Netz geben (192.168.10/24), ein Unternehmensnertzwerk (192.168.0/24) und ein weiteres durch nen Router abgegrenztes Testnetzwerk (172.16/16). Der ISA hat die Adressen 192.168.1.2 und 192.168.0.253. Der Router der zum Übergang ins andere Netz gehen soll hat die Adresse 192.168.0.254. Ich hab jetzt am ISA schon ne neue Konfiguration basierend auf der Frontfirewall eingerichtet. Dann noch ein neues Netzwerk angelegt (intern dann) und eine Netzwerregel eingefüggt und auch noch ne Firrewallregel. (und das ganze erst mal alles durchlassen, ist ja nur testweise.) Dann hab ich noch eine route in die lokale Routingtabelle eingefügt, dass 172.16.0.0 an 192.168.0.254 geleitet wird. Aber es kommt immer fehlgeschlagene Verbindung. Kann mir jemand sagen, was ich noch einstellen muss? Hab sogar schon ne Testversion vom enterprise server runtergeladen und installiert, weil ich gelesen habe, dass das nur mit dem Enterprise geht. Bin dankbar über jeden guten Ratschlag (der nicht nur "such doch mal bei Google" beinhaltet).
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 37805
Url: https://administrator.de/contentid/37805
Ausgedruckt am: 24.11.2024 um 06:11 Uhr
11 Kommentare
Neuester Kommentar
Hast du dem 172.16.0.0er Router denn auch gesagt das er das Netz 192.168.1.0/24 über die 192.168.0.253 erreicht ??? Wenn nicht landen alle Ping Versuche an die 172.16er Adressen im Nirwana, da sie den Rückweg nicht finden..Vermutlich ist das dein Problem.
Vom Server sollten alle Adressen in den 192.168.0er und 1er Segmenten problemlos pingbar sein, denn das sind ja Adressen die am Server selber direkt hängen. Beim 172.16er musst du natürlich Hin- und Rückweg per statischer Route bekanntgeben.
Ein "tracert ip-adresse" in der Eingabeaufforderung sagt dir auch immer direkt wie weit du kommst und an welchem Gateway es kneift...
Vom Server sollten alle Adressen in den 192.168.0er und 1er Segmenten problemlos pingbar sein, denn das sind ja Adressen die am Server selber direkt hängen. Beim 172.16er musst du natürlich Hin- und Rückweg per statischer Route bekanntgeben.
Ein "tracert ip-adresse" in der Eingabeaufforderung sagt dir auch immer direkt wie weit du kommst und an welchem Gateway es kneift...
na also was jetz das 1ser Netz zu sagen hat weiß ich erst mal nicht. Das geht ja nach drausen und steht eigentlich mit der Aufgabe in gar keinem Zusammenhang.
Ich hab am ISA erst mal alles erlaubt (wie schon geschrieben) und ein tracert kommt überhaupt nicht erst zu gange. bleibt direkt an der Isaschnittsetlle hängen.
Weitere Vorschläge?
Ich hab am ISA erst mal alles erlaubt (wie schon geschrieben) und ein tracert kommt überhaupt nicht erst zu gange. bleibt direkt an der Isaschnittsetlle hängen.
Weitere Vorschläge?
Wenn dein 192.168.1er Netz nach draussen geht, kann das aber kein Internet Zugang sein !? Alle deine Adressen sind RFC 1918 Adressen, die im Internet nicht geroutet werden, können folglich also nicht in irgendwelche öffentlichen Netze. Hier wäre dann NAT sowieso überflüssig, da der ISA Server dann ganz normal routen könnte. Ein ISA Port macht normalerweise auch NAT, so das alle Netze die hinter diesem Port hängen auf eine Adresse translated werden !
Ich weiss nicht ob bei ISA Servern generel IP Forwarding eingeschaltet ist ??? Bei XP oder SBS ist es das nicht und muss händisch aktiviert werden. Das solltest du auch nochmal klären, denn sonst werden gar keine Packete an die Interfaces geworwardet aus anderen Segmenten !
Dein Szenario müsste so aussehen:
(192.168.1er Segment)---(ISA Server)---192.168.0.0---(Router)---172.16.0.0
Um das routingtechnisch sauber zu gestalten musst du auf alle Fälle auf dem ISA Server eine statische Route zum 172.16er Netz eintragen und auf dem Router eine selbige zum 192.168.1er Netz, egal ob hier NAT stattfindet oder nicht.
Danach ist wenigstens Layer 3 technisch alles sauber. Alle Clients im 192.168.0er Segment sollten das default gateway auf den Router haben sofern sie vermehrt in das 172.16er Segment gehen. Sollten sie mehr in das 192.168.1er Segment gehen sollte der Server das def. Gateway sein. Letztlich ist es aber egal denn mit einem ICMP redirect wird das immer wieder angepasst.
Sollten keine Pings mehr an Endgeräte egal in welchem Segment nicht durchkommen kann eigentlich nur noch die Firewall auf dem ISA Server in Betracht kommen, das sie ICMP echo Packete filtert. Die sollte man ggf. um das Routing sicher zu testen temporär abschalten !
Ich weiss nicht ob bei ISA Servern generel IP Forwarding eingeschaltet ist ??? Bei XP oder SBS ist es das nicht und muss händisch aktiviert werden. Das solltest du auch nochmal klären, denn sonst werden gar keine Packete an die Interfaces geworwardet aus anderen Segmenten !
Dein Szenario müsste so aussehen:
(192.168.1er Segment)---(ISA Server)---192.168.0.0---(Router)---172.16.0.0
Um das routingtechnisch sauber zu gestalten musst du auf alle Fälle auf dem ISA Server eine statische Route zum 172.16er Netz eintragen und auf dem Router eine selbige zum 192.168.1er Netz, egal ob hier NAT stattfindet oder nicht.
Danach ist wenigstens Layer 3 technisch alles sauber. Alle Clients im 192.168.0er Segment sollten das default gateway auf den Router haben sofern sie vermehrt in das 172.16er Segment gehen. Sollten sie mehr in das 192.168.1er Segment gehen sollte der Server das def. Gateway sein. Letztlich ist es aber egal denn mit einem ICMP redirect wird das immer wieder angepasst.
Sollten keine Pings mehr an Endgeräte egal in welchem Segment nicht durchkommen kann eigentlich nur noch die Firewall auf dem ISA Server in Betracht kommen, das sie ICMP echo Packete filtert. Die sollte man ggf. um das Routing sicher zu testen temporär abschalten !
ich weiß nicht, ob das so sehr schwer zu verstehen ist. Das 01ser Netz zeigt ins Internet, davor hängt noch ein DSL Router, aber egal. Es geht ausschließlich um die Routen ins 172er netz. Kannst du mal bitte klar und präzise sagen wo ich was einzustellen habe, dass es geht?
Ja Sir !!!
Interessant ist aber noch zu wissen ob Maschinen aus dem 172er Segment und dem 0er Segment auch ins Internet müssen ???
OK, in deinem Szenario ist es ebenfalls wichtig zu wissen auf welchen Router (ISA Server oder den Router) die Clients im 192.168.0er Netz konfiguriert sind, denn davon ist es abhängig was du einzugeben hast...
Variante 1:
Default Gateway zeigt auf den Router also 192.168.0.254:
Das wäre die einfachste Variante, denn du musst nichts eingeben auf dem ISA Server. Die Clients im 172er Segment haben sicher auch den Router als Standardgateway und alle müssten sich sehen können die im 192.168.0er Netz und im 172er Netz sind denn der Router kennt ja beide Netze (sind an ihm direkt dran), kann die Packete entsprechend forwarden und alles ist gut !
Einzig und allein das 192.168.1er Netz hinter dem ISA Server kennt der nicht. Das bringe ich ihm aber mit einer dfault Route bei ala
ip route 0.0.0.0 0.0.0.0 192.168.0.253
Das hätte den sexy Vorteil das der Router nun alles was er nicht kennt (und das ist alles außer 192.168.0.0 und 172.16.0.0) nun an den ISA Server schaufelt in der Hoffnung der weiss nun wo es hingeht.
Hat dieser keine weiteren IP Segmente reicht hier auch ein default Gateway Eintrag auf die IP Adresse des Internet Routers im 192.168.1.0er Netz.
Damit wäre dann alles konsitent und bei richtigen DNS Serveradressen auf den Endsystemen kann man nun aus jedem Segment ins Internet und untereinander reden !
Variante 2:
Default Gateway zeigt auf den ISA Server also 192.168.0.253
Jetzt musst du auf dem ISA Server eine statische Route für das 172.16er Netz konfigurieren:
route add 172.16.0.0 mask 255.255.0.0 192.168.0.254 metric 1 -p
-p ist um sie permanent zu machen damit sie nach einem Reboot nicht verschwindet.
Die default Route auf dem Router muss aber ebenfalls zwingend bleiben um den Internetzugang zu sichern.
Egal ob du Variante 1 oder 2 benutzt sollte nun alles problemlos klappen. Ein Ping sollte das verifizieren sofern die Firewalls nicht ICMP Packet blocken
Interessant ist aber noch zu wissen ob Maschinen aus dem 172er Segment und dem 0er Segment auch ins Internet müssen ???
OK, in deinem Szenario ist es ebenfalls wichtig zu wissen auf welchen Router (ISA Server oder den Router) die Clients im 192.168.0er Netz konfiguriert sind, denn davon ist es abhängig was du einzugeben hast...
Variante 1:
Default Gateway zeigt auf den Router also 192.168.0.254:
Das wäre die einfachste Variante, denn du musst nichts eingeben auf dem ISA Server. Die Clients im 172er Segment haben sicher auch den Router als Standardgateway und alle müssten sich sehen können die im 192.168.0er Netz und im 172er Netz sind denn der Router kennt ja beide Netze (sind an ihm direkt dran), kann die Packete entsprechend forwarden und alles ist gut !
Einzig und allein das 192.168.1er Netz hinter dem ISA Server kennt der nicht. Das bringe ich ihm aber mit einer dfault Route bei ala
ip route 0.0.0.0 0.0.0.0 192.168.0.253
Das hätte den sexy Vorteil das der Router nun alles was er nicht kennt (und das ist alles außer 192.168.0.0 und 172.16.0.0) nun an den ISA Server schaufelt in der Hoffnung der weiss nun wo es hingeht.
Hat dieser keine weiteren IP Segmente reicht hier auch ein default Gateway Eintrag auf die IP Adresse des Internet Routers im 192.168.1.0er Netz.
Damit wäre dann alles konsitent und bei richtigen DNS Serveradressen auf den Endsystemen kann man nun aus jedem Segment ins Internet und untereinander reden !
Variante 2:
Default Gateway zeigt auf den ISA Server also 192.168.0.253
Jetzt musst du auf dem ISA Server eine statische Route für das 172.16er Netz konfigurieren:
route add 172.16.0.0 mask 255.255.0.0 192.168.0.254 metric 1 -p
-p ist um sie permanent zu machen damit sie nach einem Reboot nicht verschwindet.
Die default Route auf dem Router muss aber ebenfalls zwingend bleiben um den Internetzugang zu sichern.
Egal ob du Variante 1 oder 2 benutzt sollte nun alles problemlos klappen. Ein Ping sollte das verifizieren sofern die Firewalls nicht ICMP Packet blocken
Also vielen Dank für deine Hilfe, aber es geht immer noch nicht.
Also Variante 1, die ja so sexy sein soll ist größter Unfug in meinen Augen, da doch die meisten Aufrufe ins Internet gehen und ncht ins dahinterliegende Netz, und der dahinterliegende Router ist nicht gerade der schnellste. --> NEIN
Und ganz so einfach wie MS das sagt, scheint es nicht zu sein. Folgendes.
Zuerst mal alles platt gemacht, dass überhaupt was geht.
Dann keinen ISA installiert und nur ne Route (wie gesagt) eingetragen. --> Kein Client konnte ins 172er netz. Route raus, RAS + Routing aktiviert --> jetzt konnten Clients ins 172er Netz. War hellauf begeistert.
ISA std. installiert, nichts weiter eingeteragen --> Ging nicht (war klar, ist ja alles verboten und ISA kennt 172er netz nicht.
Netz angelegt (als intern) ne Netzwerkregel erstellt und alles zwischen intern, drinne (das neue) und localhost zugelassen. --> nix geht. Ping geht nicht, ftp geht nicht, http geht nicht. --> Doof. in den Logs von ISA steht immer, dass die erste Verbindung initiiert ist, dann kommt immer verweigert und am Ende kommt dann immer getrennte Verbindung.
Hast noch ne Idee?
in tiefster Trauer
Frank
Also Variante 1, die ja so sexy sein soll ist größter Unfug in meinen Augen, da doch die meisten Aufrufe ins Internet gehen und ncht ins dahinterliegende Netz, und der dahinterliegende Router ist nicht gerade der schnellste. --> NEIN
Und ganz so einfach wie MS das sagt, scheint es nicht zu sein. Folgendes.
Zuerst mal alles platt gemacht, dass überhaupt was geht.
Dann keinen ISA installiert und nur ne Route (wie gesagt) eingetragen. --> Kein Client konnte ins 172er netz. Route raus, RAS + Routing aktiviert --> jetzt konnten Clients ins 172er Netz. War hellauf begeistert.
ISA std. installiert, nichts weiter eingeteragen --> Ging nicht (war klar, ist ja alles verboten und ISA kennt 172er netz nicht.
Netz angelegt (als intern) ne Netzwerkregel erstellt und alles zwischen intern, drinne (das neue) und localhost zugelassen. --> nix geht. Ping geht nicht, ftp geht nicht, http geht nicht. --> Doof. in den Logs von ISA steht immer, dass die erste Verbindung initiiert ist, dann kommt immer verweigert und am Ende kommt dann immer getrennte Verbindung.
Hast noch ne Idee?
in tiefster Trauer
Frank
Es spielt keine Rolle ob der Router schnell oder langsam ist, da er bei Variante 1 immer ein ICMP redirect Frame an die Endgeräte schickt für den Internetzugang und dann sowieso alles auf den Server geroutet wird von den Clients. Performancetechnisch ist das also ziemlich egal. Ich fand es etwas einfacher, da man dann keine kryptischen Routen unter Windows anlegen müsste. Letztlich ist es aber routingtechnisch ziemlich gleich welche Varianten du anwendest...
Ich denke das das Problem klar auf der Win Seite liegt und deine Vorgehensweise um das zum Laufen zu bringen erstmal mit einen offenen Neuinstallation ist auch richtig.
Ich würde nochmals den Versuch machen erstmal ein "normales" Windows ohne alles zu installieren, Firewall temporär abschalten um keine weiteren Hürden zu schaffen...
Achtung: Windows kann per Default KEIN Routing !!!
Benutzt du XP musst du das in der Registry erst freischalten:
www.microsoft.com/windows2000/de/server/help/default.asp?url=/windows2000/de/server/help/sag_TCPIP_pro_EnableForwarding.htm
Wenn du 2003 benutzt dann ist es auch einzuschalten, allerdings ist das hier ein Häkchen in den TCP/IP Settings.
Ohne diese Konfigs routet Windows sowieso gar nicht und du wirst per se nichts mit dem Packet Forwarding !!!
Jetzt trägst du auf der Maschine folgende Route ein:
route add 172.16.0.0 mask 255.255.0.0 192.168.0.254 metric 1 -p
Beim externen Netz gibst du als Default Gateway am Server die IP des Internetrouters an.
(Du hast oben übrigens einen Fehler in der Beschreibung !!! Dein externes Netz soll die 192.168.10.0/24 haben aber die Adresse auf der NIC ist die 192.168.1.2 aber ich denke mal das soll .10.2 heissen...)
Unter der Voraussetzung das alle Clients im 172.16.0.0er Netz nun die Routeradresse 172.16.x.x als default Gateway haben und alle Clients im 192.168.0.0er Netz die 192.168.0.253 als Gateway haben MUSS ein Ping vom 192.168.0.0er Netz auf alle Komponenten im 172.16.0.0er Segment (und vice versa..) möglich sein. Sicher aber die 172.16.x.x Adresse des Routers, falls die Endgeräte dort ggf. eine Firewall aktiviert haben die ICMP Echo Packete (Ping) blockt.
Bis hierhin muss das gehen...sowas einfaches im Routing kann auch Windows
Ein Problem gibt es natürlich noch mit dem Internet Router im 192.168.10.0er Segment !
Der weiss natürlich nicht das sich das Netzwerk 192.168.0.0/24 und 172.16.0.0/16 hinter deinem Server verbergen und das MUSST du ihm natürlich auch beibringen !!!
Je nachdem was das für eine Maschine ist hat der ein grafisches Setup in das 2 ! Routen eingetragen werden müssen:
Zielnetz: 172.16.0.0 Maske 255.255.0.0 Gateway 192.168.10.2
Zielnetz: 192.168.0.0 Maske 255.255.255.0 Gateway 192.168.10.2
Auch braucht dein Router zum 172.16.0.0er Segment eine Route zum externen .10er Segment !! Da aber wohl auch alle Clients aus dem 172.16er Segment ins Internet sollen reicht hier eine default Route auf die Serveradresse 192.168.0.253 denn die deckt ja auch das .10er netz mit ab !!!
So wäre alles routingtechnisch sauber !!! Und ein PING von überall zu überall MUSS funktionieren.
Jetzt kannst du dir dann überlegen ob du nochmal die ISA SW drüberlegen willst um das sicherheitstechnisch noch zu kontrollieren !!??
Ich denke das das Problem klar auf der Win Seite liegt und deine Vorgehensweise um das zum Laufen zu bringen erstmal mit einen offenen Neuinstallation ist auch richtig.
Ich würde nochmals den Versuch machen erstmal ein "normales" Windows ohne alles zu installieren, Firewall temporär abschalten um keine weiteren Hürden zu schaffen...
Achtung: Windows kann per Default KEIN Routing !!!
Benutzt du XP musst du das in der Registry erst freischalten:
www.microsoft.com/windows2000/de/server/help/default.asp?url=/windows2000/de/server/help/sag_TCPIP_pro_EnableForwarding.htm
Wenn du 2003 benutzt dann ist es auch einzuschalten, allerdings ist das hier ein Häkchen in den TCP/IP Settings.
Ohne diese Konfigs routet Windows sowieso gar nicht und du wirst per se nichts mit dem Packet Forwarding !!!
Jetzt trägst du auf der Maschine folgende Route ein:
route add 172.16.0.0 mask 255.255.0.0 192.168.0.254 metric 1 -p
Beim externen Netz gibst du als Default Gateway am Server die IP des Internetrouters an.
(Du hast oben übrigens einen Fehler in der Beschreibung !!! Dein externes Netz soll die 192.168.10.0/24 haben aber die Adresse auf der NIC ist die 192.168.1.2 aber ich denke mal das soll .10.2 heissen...)
Unter der Voraussetzung das alle Clients im 172.16.0.0er Netz nun die Routeradresse 172.16.x.x als default Gateway haben und alle Clients im 192.168.0.0er Netz die 192.168.0.253 als Gateway haben MUSS ein Ping vom 192.168.0.0er Netz auf alle Komponenten im 172.16.0.0er Segment (und vice versa..) möglich sein. Sicher aber die 172.16.x.x Adresse des Routers, falls die Endgeräte dort ggf. eine Firewall aktiviert haben die ICMP Echo Packete (Ping) blockt.
Bis hierhin muss das gehen...sowas einfaches im Routing kann auch Windows
Ein Problem gibt es natürlich noch mit dem Internet Router im 192.168.10.0er Segment !
Der weiss natürlich nicht das sich das Netzwerk 192.168.0.0/24 und 172.16.0.0/16 hinter deinem Server verbergen und das MUSST du ihm natürlich auch beibringen !!!
Je nachdem was das für eine Maschine ist hat der ein grafisches Setup in das 2 ! Routen eingetragen werden müssen:
Zielnetz: 172.16.0.0 Maske 255.255.0.0 Gateway 192.168.10.2
Zielnetz: 192.168.0.0 Maske 255.255.255.0 Gateway 192.168.10.2
Auch braucht dein Router zum 172.16.0.0er Segment eine Route zum externen .10er Segment !! Da aber wohl auch alle Clients aus dem 172.16er Segment ins Internet sollen reicht hier eine default Route auf die Serveradresse 192.168.0.253 denn die deckt ja auch das .10er netz mit ab !!!
So wäre alles routingtechnisch sauber !!! Und ein PING von überall zu überall MUSS funktionieren.
Jetzt kannst du dir dann überlegen ob du nochmal die ISA SW drüberlegen willst um das sicherheitstechnisch noch zu kontrollieren !!??
Also danke für deine ausführliche Beschreibung zum Routing. Bissel was war mal interessant, weil ich die Registry Keys noch nicht kannte, aber der Rest, naja, ein bissel kenn ich mich ja auch damit aus Aber trotzdem vielen Dank. Also Routingtechnisch klappt erst mal alles. ISA Drauf nichts geht mehr. OK!!?? Wenn ich jetzt direkt zum internen Netz noch zusätzlich das 172er Netz hinzufüge, dann macht der das prima. Alles geht genau so wieder, wie ich mir das vorstelle. Aber so soll es ja nicht sein. Wenn ich für das 172er ein eigenes Netz definiere, eine Netzwerkregel (Routing) erstelle und dann eine Firewallrichtlinie einrichte, dann geht es immer noch nicht. Ich hab sogar in allen Systemrichtlinien noch eingetragen, dass alles wo intern bisher dort stand jetzt auch noch 172 mit drin steht, aber es hilft nicht. Hast noch paar Vorschläge?
Danke
Aber trotzdem vielen Dank. Also Routingtechnisch klappt erst mal alles. ISA Drauf nichts geht mehr. OK!!?? Wenn ich jetzt direkt zum internen Netz noch zusätzlich das 172er Netz hinzufüge, dann macht der das prima. Alles geht genau so wieder, wie ich mir das vorstelle. Aber so soll es ja nicht sein. Wenn ich für das 172er ein eigenes Netz definiere, eine Netzwerkregel (Routing) erstelle und dann eine Firewallrichtlinie einrichte, dann geht es immer noch nicht. Ich hab sogar in allen Systemrichtlinien noch eingetragen, dass alles wo intern bisher dort stand jetzt auch noch 172 mit drin steht, aber es hilft nicht. Hast noch paar Vorschläge?Danke
Sorry, das ist dann wohl eher ein ISA spezielles Ding und ich bin kein MS Knecht
Ggf. sollte man das mal bei OS Windows netzwerk posten oder Security...nur ein Tip..
Ggf. sollte man das mal bei OS Windows netzwerk posten oder Security...nur ein Tip..
Ja, ist ein sehr spezielles ISA Problem. ;.-) Aber ich werd weiterhin dran bleiben, und versuchen da mal noch was rauszubekommen. Ich denk, irgend eine Antwort muss es ja geben.
Vielen Dank für deine Hilfe
Vielen Dank für deine Hilfe
Bin durch Zufall über diesen Beitrag gestolpert. Möchte an dieser Stelle einfügen, dass wir mit fast identischer Vorraussetzung exakt die gleichen Probleme haben.
Haben nach unzähligen Versuchen mit statischen Routen etc. (siehe Tipps von aqui) die Frontfirewall probeweise mit dem Wizard auf "Edgefirefall" konfiguriert. Dann funktionierte das Routing nach "draußen" plötzlich. Nach unserer Erfahrung klappte die Verbindung nur mit NAT aber nicht mit ROUTE an der Frontfirewall.
Haben keine Erklärung gefunden....
Haben nach unzähligen Versuchen mit statischen Routen etc. (siehe Tipps von aqui) die Frontfirewall probeweise mit dem Wizard auf "Edgefirefall" konfiguriert. Dann funktionierte das Routing nach "draußen" plötzlich. Nach unserer Erfahrung klappte die Verbindung nur mit NAT aber nicht mit ROUTE an der Frontfirewall.
Haben keine Erklärung gefunden....
