12
ZyXEL ZyWALL WAN2 für Test Netz
Hallo zusammen,
ich dachte eigentlich, das Grundgerüste würde schnell stehen, aber warum auch immer klappt schon das pingen nicht und darum bau ich da erst gar nicht weiter.
Hier mal die Konstellation:
ZyXEL ZyWALL 35 (wie unten angemerkt kann es keine ZyWALL 5 sein)
WAN1: 91. .... (Telekom)
WAN2: 172.16.10.9/30 [R1]
LAN: 10.20.20.0/24 [L1]
ZyXEL ZyWALL USG 20
WAN: 172.16.10.10/30 [R2]
LAN: 192.168.1.0/24 [L2]
Eigentlich möchte ich VPN testen, zuvor war kurz geplant die Teststellung hinter einen echten Internetanschluss zu setzen, was dann jedoch wieder verworfen wurde, weil wir keinen frei hatten. Nun soll eben später ein VPN Tunnel aus dem 10.20.20.0 Netz in das 192.168.1.0 Netz aufgebaut werden. Wobei das Netz 172.16.10.8/30 als Transportnetz genutzt wird. Trotz, wie ich denke, richtiger ICMP Freigaben klappt aber schon der Ping von [L1] auf [R2] nicht, weitaus verwirrender ist aber das auch der Ping über CLI von [R2] auf [R1] nicht möglich ist.
Nur mal um sicher zu gehen, ohne irgendwelche Anpassungen kann ich aus dem [L1] dessen GW und [R1], nicht jedoch [R2] erreichen.
Aus [L2] kann ich jedoch [R2] und [R1] pingen weil [R2] dank alleinigem WAN auch das Default GW ist.
Ich hoffe ich konnte kein Problem erklären, bin mittlerweile schon so verwirrt, hab einen richtigen Knoten im Kopf.
Danke für eure Hilfe!
LG mcdy
ich dachte eigentlich, das Grundgerüste würde schnell stehen, aber warum auch immer klappt schon das pingen nicht und darum bau ich da erst gar nicht weiter.
Hier mal die Konstellation:
ZyXEL ZyWALL 35 (wie unten angemerkt kann es keine ZyWALL 5 sein)
WAN1: 91. .... (Telekom)
WAN2: 172.16.10.9/30 [R1]
LAN: 10.20.20.0/24 [L1]
ZyXEL ZyWALL USG 20
WAN: 172.16.10.10/30 [R2]
LAN: 192.168.1.0/24 [L2]
Eigentlich möchte ich VPN testen, zuvor war kurz geplant die Teststellung hinter einen echten Internetanschluss zu setzen, was dann jedoch wieder verworfen wurde, weil wir keinen frei hatten. Nun soll eben später ein VPN Tunnel aus dem 10.20.20.0 Netz in das 192.168.1.0 Netz aufgebaut werden. Wobei das Netz 172.16.10.8/30 als Transportnetz genutzt wird. Trotz, wie ich denke, richtiger ICMP Freigaben klappt aber schon der Ping von [L1] auf [R2] nicht, weitaus verwirrender ist aber das auch der Ping über CLI von [R2] auf [R1] nicht möglich ist.
Nur mal um sicher zu gehen, ohne irgendwelche Anpassungen kann ich aus dem [L1] dessen GW und [R1], nicht jedoch [R2] erreichen.
Aus [L2] kann ich jedoch [R2] und [R1] pingen weil [R2] dank alleinigem WAN auch das Default GW ist.
Ich hoffe ich konnte kein Problem erklären, bin mittlerweile schon so verwirrt, hab einen richtigen Knoten im Kopf.
Danke für eure Hilfe!
LG mcdy
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: 215251
Url: https://administrator.de/contentid/215251
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
also ich möchte Dir jetzt nicht zu nahe treten oder kommen, aber ich würde Dir dringend dazu raten so ein Szenario
immer live aufzusetzen und erst recht live zu testen und nicht lokal im LAN.
Und wenn schon zwei Internetverbindungen vorhanden sind dann würde ich auch mindestens einen Dual WAN Router
oder eine Dual WAN Firewall besorgen wollen mit der ich das dann durch teste!
Es kommt auch immer darauf an was Du für ein Konzept hast und wie Du das umsetzt.
Load Balancing oder Failover und welche Mehtoden man dafür verwendet, also Policy based Routing,
Session based Routing oder gar Service based Routing
Über einen WAN Port das VPN abwickeln und über den anderen WAN Port den restlichen Internetverkehr wäre
zum Beispiel eine Methode.
Gruß
Dobby
also ich möchte Dir jetzt nicht zu nahe treten oder kommen, aber ich würde Dir dringend dazu raten so ein Szenario
immer live aufzusetzen und erst recht live zu testen und nicht lokal im LAN.
Und wenn schon zwei Internetverbindungen vorhanden sind dann würde ich auch mindestens einen Dual WAN Router
oder eine Dual WAN Firewall besorgen wollen mit der ich das dann durch teste!
Es kommt auch immer darauf an was Du für ein Konzept hast und wie Du das umsetzt.
Load Balancing oder Failover und welche Mehtoden man dafür verwendet, also Policy based Routing,
Session based Routing oder gar Service based Routing
Über einen WAN Port das VPN abwickeln und über den anderen WAN Port den restlichen Internetverkehr wäre
zum Beispiel eine Methode.
Gruß
Dobby
Hallo Dobby,
ich glaube ich habe mich obwohl ich mich sehr bemüht habe schlecht ausgedrückt.
Ich habe eine funktionstüchtige Installation mit welcher ich aus von der ZyWALL 5 aus dem LAN über WAN1 ins Internet komme. Da ich für ein Konzept (Software VPN) nun einen L2TP Tunnel testen soll, ehe wir mehr USG 20 kaufen, wollte ich ursprünglich eine USG 20 konfigurieren und dann an irgendeinen Anschluss hängen, da das aber nicht geht ich also nicht testen kann wie es sich verhält wenn ich aus dem WAN einen Tunnel aufbaue, war der nächste Gedanke den WAN2 Anschluss unserer ZyWALL5 zu nutzen um einen Transportnetz mit der USG 20 aufzubauen und so dann VPN zu testen.
Ich habe nun auch eben getestet, mit einem Notebook kann ich auf der USG 20 die WAN Adresse pingen, es klappt jedoch nicht die WAN2 Adresse der ZyWALL 5 anzupingen.
Während des schreibens kam mir nun der Gedanke das Notebook auch für den VPN Test direkt am WAN Port anzuhängen und so dann einen Tunnel aufzubauen, würde zumindest sämtliche Probleme mit der ZyWALL 5 umgehen. Gute Idee oder bin ich schon wieder auf dem Holzweg?
Danke!
LG mcdy
ich glaube ich habe mich obwohl ich mich sehr bemüht habe schlecht ausgedrückt.
Ich habe eine funktionstüchtige Installation mit welcher ich aus von der ZyWALL 5 aus dem LAN über WAN1 ins Internet komme. Da ich für ein Konzept (Software VPN) nun einen L2TP Tunnel testen soll, ehe wir mehr USG 20 kaufen, wollte ich ursprünglich eine USG 20 konfigurieren und dann an irgendeinen Anschluss hängen, da das aber nicht geht ich also nicht testen kann wie es sich verhält wenn ich aus dem WAN einen Tunnel aufbaue, war der nächste Gedanke den WAN2 Anschluss unserer ZyWALL5 zu nutzen um einen Transportnetz mit der USG 20 aufzubauen und so dann VPN zu testen.
Ich habe nun auch eben getestet, mit einem Notebook kann ich auf der USG 20 die WAN Adresse pingen, es klappt jedoch nicht die WAN2 Adresse der ZyWALL 5 anzupingen.
Während des schreibens kam mir nun der Gedanke das Notebook auch für den VPN Test direkt am WAN Port anzuhängen und so dann einen Tunnel aufzubauen, würde zumindest sämtliche Probleme mit der ZyWALL 5 umgehen. Gute Idee oder bin ich schon wieder auf dem Holzweg?
Danke!
LG mcdy
Wenns Dir gelingt, spendiere ich einen Kasten Hefeweizen!
(Die Zywall 5 hat nämlich nur einen WAN-Port...)
Gruß
sk
Na dann schnell mal jemanden aus der Firma abkommandiert, der Dir dabei zur Hand geht bzw. Dir hilft!
Oder von zu hause aus ein VPN zur Firma aufgebaut und dann bleibt der Laptop eben an heute Nacht!
Gruß
Dobby
Oder von zu hause aus ein VPN zur Firma aufgebaut und dann bleibt der Laptop eben an heute Nacht!
Gruß
Dobby
Hier kannst du dir einmal ein Testszenario für IPsec VPN Netze ansehen:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Wenn du es analog so aufbaust kommt das im Handumdrehen zum Fliegen !!
Das du die WAN Rx Interfaces nicht pingen kannst ist normal bei einer Firewall und auch so gewollt, da diese auf den öffentlichen Interfaces ICMP blockiert.
Du müsstest auf diesen Rx Interfaces in einer inbound ACL ICMP Echo Request Pakete erlauben das ist ICMP Typ 8
Ohne das kein Ping !!
Kann man wohl davon ausgehen das du schon beim Erstellen dieser FW Regeln gravierende Fehler gemacht hast ?!
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Wenn du es analog so aufbaust kommt das im Handumdrehen zum Fliegen !!
Das du die WAN Rx Interfaces nicht pingen kannst ist normal bei einer Firewall und auch so gewollt, da diese auf den öffentlichen Interfaces ICMP blockiert.
Du müsstest auf diesen Rx Interfaces in einer inbound ACL ICMP Echo Request Pakete erlauben das ist ICMP Typ 8
Ohne das kein Ping !!
Kann man wohl davon ausgehen das du schon beim Erstellen dieser FW Regeln gravierende Fehler gemacht hast ?!
Zitat von @sk:
> Zitat von @mc-doubleyou:
> ----
> es klappt jedoch nicht die WAN2 Adresse der ZyWALL 5 anzupingen.
Wenns Dir gelingt, spendiere ich einen Kasten Hefeweizen!
(Die Zywall 5 hat nämlich nur einen WAN-Port...)
Gruß
sk
> Zitat von @mc-doubleyou:
> ----
> es klappt jedoch nicht die WAN2 Adresse der ZyWALL 5 anzupingen.
Wenns Dir gelingt, spendiere ich einen Kasten Hefeweizen!
(Die Zywall 5 hat nämlich nur einen WAN-Port...)
Gruß
sk
habs gerade geändert, ist natürlich eine ZyWALL 35 - danke für den Einwand.
Zitat von @aqui:
Das du die WAN Rx Interfaces nicht pingen kannst ist normal bei einer Firewall und auch so gewollt, da diese auf den
öffentlichen Interfaces ICMP blockiert.
Du müsstest auf diesen Rx Interfaces in einer inbound ACL ICMP Echo Request Pakete erlauben das ist ICMP Typ 8
Ohne das kein Ping !!
Kann man wohl davon ausgehen das du schon beim Erstellen dieser FW Regeln gravierende Fehler gemacht hast ?!
Das du die WAN Rx Interfaces nicht pingen kannst ist normal bei einer Firewall und auch so gewollt, da diese auf den
öffentlichen Interfaces ICMP blockiert.
Du müsstest auf diesen Rx Interfaces in einer inbound ACL ICMP Echo Request Pakete erlauben das ist ICMP Typ 8
Ohne das kein Ping !!
Kann man wohl davon ausgehen das du schon beim Erstellen dieser FW Regeln gravierende Fehler gemacht hast ?!
das war mir nach etwas gegrübel auch klar und darum hab ich auf der ZyWALL 35 auch folgende Firewallregelausnahme gesetzt:
- WAN2 to WAN2 Echo Request ICMP Typ 8 (somit müsste zumindest der Ping von ZyXEL zu ZyXEL möglich sein.
Danke!
LG mcdy
So ich hab das Problem nun glaube ich mit eurere Hilfe erkannt.
Statt dem WAN 2 Port nutze ich nun einen LAN Port welcher als DMZ konfiguriert ist. Somit kann ich das WAN GW pingen und mit Hilfe einer statischen Route (nur zum Test) komme ich auch in das andere Netz.
Der VPN Tunnel lässt sich aber leider nicht aufbauen, scheinbar wird irgendwo etwas geblockt und der Log der ZyWALL 35 ist nicht sehr ergiebig.
Für einen IPSec Tunnel brauche ich den Port 500, welche brauche ich den für dien L2TP Tunnel?
In den Tutorials welche ich bis jetzt gesehen habe wird leider auf dieses Thema überhaupt nicht eingegangen.
THX mcdy
Statt dem WAN 2 Port nutze ich nun einen LAN Port welcher als DMZ konfiguriert ist. Somit kann ich das WAN GW pingen und mit Hilfe einer statischen Route (nur zum Test) komme ich auch in das andere Netz.
Der VPN Tunnel lässt sich aber leider nicht aufbauen, scheinbar wird irgendwo etwas geblockt und der Log der ZyWALL 35 ist nicht sehr ergiebig.
Für einen IPSec Tunnel brauche ich den Port 500, welche brauche ich den für dien L2TP Tunnel?
In den Tutorials welche ich bis jetzt gesehen habe wird leider auf dieses Thema überhaupt nicht eingegangen.
THX mcdy
Falsch !
Für IPsec VPNs brauchst du zwingend:
L2TP benutzt IPsec als Transport Tunnel !
Hier sind es genau die obigen Ports bzw. Protokolle zusätzlich aber noch der Port:
Für IPsec VPNs brauchst du zwingend:
- UDP 500 (IKE)
- UDP 4500 (NAT Traversal)
- ESP Protokoll mit der IP Protokoll Nummer 51 (Achtung: Nicht Port 51, denn ESP ist ein eigenständiges IP Protokoll !)
L2TP benutzt IPsec als Transport Tunnel !
Hier sind es genau die obigen Ports bzw. Protokolle zusätzlich aber noch der Port:
- UDP 1701
2
Danke aqui, my personal hero 
Leider habe ich denke ich nicht sooo schnell Zeit das nun zu testen, aber danke schon mal, ich schätz jetzt kann ich es lösen.
Hast auch einen Tipp um die ZyWALL 35 zu motivieren besser zu loggen? Solche Blocks müssten doch geloggt werden oder?
LG mcdy
Leider habe ich denke ich nicht sooo schnell Zeit das nun zu testen, aber danke schon mal, ich schätz jetzt kann ich es lösen.
Hast auch einen Tipp um die ZyWALL 35 zu motivieren besser zu loggen? Solche Blocks müssten doch geloggt werden oder?
LG mcdy
Hallo, ich nochmal
zwar hab ich durch die Nutzung des DMZ Anschlusses statt des WAN2 eine Verbindung über das Transportnetz zum anderen Router und danke aqui baut sich auch ein Tunnel auf. Leider kann ich ihn nicht testen weil der Traffic welcher eigentlich in die DMZ müsste immer über 0.0.0.0 geschickt wird.
Kann ich irgendwo zumindest zum Test im Lab, produktiveinsatz wäre das wieder passend, das Gateway anpassen oder so?
Klar ist mir bekannt das zwei Gateways falsch, wenn auch möglich sind, aber irgendwie muss ich den Traffic umleiten, dachte auch schon an eine statische Route am PC, dann zieht die Route vom VPN aber leider trotzdem stärker.
Danke!
LG mcdy
zwar hab ich durch die Nutzung des DMZ Anschlusses statt des WAN2 eine Verbindung über das Transportnetz zum anderen Router und danke aqui baut sich auch ein Tunnel auf. Leider kann ich ihn nicht testen weil der Traffic welcher eigentlich in die DMZ müsste immer über 0.0.0.0 geschickt wird.
Kann ich irgendwo zumindest zum Test im Lab, produktiveinsatz wäre das wieder passend, das Gateway anpassen oder so?
Klar ist mir bekannt das zwei Gateways falsch, wenn auch möglich sind, aber irgendwie muss ich den Traffic umleiten, dachte auch schon an eine statische Route am PC, dann zieht die Route vom VPN aber leider trotzdem stärker.
Danke!
LG mcdy
Zitat von @mc-doubleyou:
das war mir nach etwas gegrübel auch klar und darum hab ich auf der ZyWALL 35 auch folgende
Firewallregelausnahme gesetzt:
- WAN2 to WAN2 Echo Request ICMP Typ 8 (somit müsste zumindest der Ping von ZyXEL zu ZyXEL > möglich sein.
das war mir nach etwas gegrübel auch klar und darum hab ich auf der ZyWALL 35 auch folgende
Firewallregelausnahme gesetzt:
- WAN2 to WAN2 Echo Request ICMP Typ 8 (somit müsste zumindest der Ping von ZyXEL zu ZyXEL > möglich sein.
Es könnte auch sein, dass die Zywall so eingestellt ist, dass sie unabhängig vom Firewallregelwerk nicht auf Pings auf das WAN-Interface reagiert. Siehe http://www.zyxeltech.de/previews/zw2plus404xu0b4/AntiProbing.html
Zitat von @mc-doubleyou:
Statt dem WAN 2 Port nutze ich nun einen LAN Port welcher als DMZ konfiguriert ist.
Somit kann ich das WAN GW pingen
Statt dem WAN 2 Port nutze ich nun einen LAN Port welcher als DMZ konfiguriert ist.
Somit kann ich das WAN GW pingen
Ich wäre bei WAN2 geblieben, denn nun fehlt Dir an der 2Plus das NAT für ein realitätsnahes Test-Szenario.
Allenfalls macht das als Zwischenschritt Sinn, um Fehler auszuschließen. Dann wäre es aber sinnvoller gewesen, zunächst als vorherigen Schritt das Notebook an WAN1 der USG20 anzuschließen bzw. ins Transfernetz zu stellen.
Zitat von @mc-doubleyou:
und mit Hilfe einer statischen Route (nur zum Test) komme ich auch in das andere Netz.
und mit Hilfe einer statischen Route (nur zum Test) komme ich auch in das andere Netz.
Es ist nicht sinnvoll, das Regelwerk der USG20 so zu konfigurieren. In das andere Netz willst Du ja erst kommen, wenn der Tunnel steht (und zwar durch diesen hindurch).
Zitat von @mc-doubleyou:
Hast auch einen Tipp um die ZyWALL 35 zu motivieren besser zu loggen?
Solche Blocks müssten doch geloggt werden oder?
Hast auch einen Tipp um die ZyWALL 35 zu motivieren besser zu loggen?
Solche Blocks müssten doch geloggt werden oder?
Die ZW2Plus hat ein sehr aussagekräftiges Logging, wenn man es entsprechend konfiguriert.
Zum einen kann man das Logging natürlich für jede Firewall-Regel ein- und ausschalten. Zum anderen gibt es pro Zonenpaarung eine konfigurierbare Default-Regel, die greift, wenn keine andere speziellere Firewallregel greift. Auch hier ist ein Logging konfigurierbar. Siehe http://www.zyxeltech.de/previews/zw2plus404xu0b4/DefRule.html
Zitat von @mc-doubleyou:
danke aqui baut sich auch ein Tunnel auf. Leider kann ich ihn nicht testen weil der
Traffic welcher eigentlich in die DMZ müsste immer über 0.0.0.0 geschickt wird.
danke aqui baut sich auch ein Tunnel auf. Leider kann ich ihn nicht testen weil der
Traffic welcher eigentlich in die DMZ müsste immer über 0.0.0.0 geschickt wird.
Häh? Der Traffic wird mit Sicherheit nicht über 0.0.0.0 geschickt. Du meinst sicherlich die sog. Nullroute. Deren Ziel ist aber nicht 0.0.0.0
Das Notebook befindet sich ja im LAN der ZW2+ und die USG20 in der DMZ der ZW2+. Wenn das Default-Gateway des Notebooks auf die LAN-IP der ZW2+ steht ist alles gut. Das Notebook baut den Tunnel ja zur IP-Adresse der USG20 in der DMZ der ZW2+ auf. Und die Route dorthin kennt die ZW2+ automatisch, weil sie mit diesem Netz unmittelbar verbunden ist. Lediglich die USG20 muss die Rückroute zum Notebook kennen, weil Dir ja wie gesagt aufgrund der Nutzung der DMZ hier das NAT fehlt. Am einfachsten geht dies, wenn Du die Default-Route des WAN-Interfaces der USG20 auf die IP-Adresse der ZW2+ im Transfernetz (also deren DMZ-IP) zeigen lässt.
Zitat von @mc-doubleyou:
dachte auch schon an eine statische Route am PC, dann zieht die Route
vom VPN aber leider trotzdem stärker.
dachte auch schon an eine statische Route am PC, dann zieht die Route
vom VPN aber leider trotzdem stärker.
???
Bedenke, dass die USG20 zwischen ihrem lokalen Netz und den L2TPVPN-Clients zwingend routen will. Anders als z.B. bei einem Windowes-Server kann der IP-Pool der VPN-CLients nicht Teil des lokalen Netzes der USG sein. Auch darf der L2TP-IP-Pool keine Teilmenge des entfernten lokalen Netzes sein (also des LANs an der ZW2+).
Praktisch bedeutet dies, dass beim Einsatz eines L2TPoverIPSEc-VPNs gegen eine Zywall USG bei derzeitigem Firmwarestand kein "Split Tunnel" möglich ist. Steht der Tunnel, muss - mit Ausnahme des lokalen IP-Netzes, in dem sich der Client befindet) auch alles durch diesen hindurch. Insbesondere der Internetzugriff erfolgt dann also durch den Tunnel.
Gruß
sk
Danke sk für deine Antwort,
bin leider grad etwas im Stress, manches hast du leider falsch verstanden oder ich schlecht formuliert.
Wir werden nun aber ohnehin einen Echttest machen darum werde ich mich mit dem "Lab" nicht mehr länger beschäftigen.
Das mit den Ports war aber Gold wert ^^
LG mcdy
bin leider grad etwas im Stress, manches hast du leider falsch verstanden oder ich schlecht formuliert.
Wir werden nun aber ohnehin einen Echttest machen darum werde ich mich mit dem "Lab" nicht mehr länger beschäftigen.
Das mit den Ports war aber Gold wert ^^
LG mcdy
