21
L2TP Verbindungsproblem und kein Ping trotz IPSec Tunnel
Hallo zusammen,
ich habe nun die ZyXEL ausgeliefert und es läuft zumindest fast alles was zuvor ging. (ZyXEL ZyWALL 2 Plus => ZyXEL USG 20)
Fangen wir mal mit dem ersten Problem an:
Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird, den entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
Folglich wird der Tunnel nicht aufgebaut
Nun zum zweiten Problem:
Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch andere) nicht erreichen
Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort von .1 diese kommt aber nie an.
Der Zugriff auf das Netzlaufwerk ist ebenso nicht möglich.
Einen Converter von 2 Plus auf USG 20 gibt es wahrscheinlich nicht, den abgesehen von der L2TP Funktion (nicht dabei) funktionieren diese super.
€dit (Screenshots): ich hoffe es ist was passendes dabei
Routing:
Firewall:
VPN Connection:
VPN Gateway:
Danke!
LG mcdy
ich habe nun die ZyXEL ausgeliefert und es läuft zumindest fast alles was zuvor ging. (ZyXEL ZyWALL 2 Plus => ZyXEL USG 20)
Fangen wir mal mit dem ersten Problem an:
Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird, den entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
[ID]: Tunnel [RTBF-Linz_Connection] Remote IP mismatch
Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
Folglich wird der Tunnel nicht aufgebaut
VPN-Verbindung
Der L2TP-VPN-Server antwortet nicht. Versuchen Sie es erneut oder ...
Der L2TP-VPN-Server antwortet nicht. Versuchen Sie es erneut oder ...
Nun zum zweiten Problem:
Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch andere) nicht erreichen
Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort von .1 diese kommt aber nie an.
Zeitüberschreitung der Anforderung.
Der Zugriff auf das Netzlaufwerk ist ebenso nicht möglich.
Einen Converter von 2 Plus auf USG 20 gibt es wahrscheinlich nicht, den abgesehen von der L2TP Funktion (nicht dabei) funktionieren diese super.
€dit (Screenshots): ich hoffe es ist was passendes dabei
Routing:
Firewall:
VPN Connection:
VPN Gateway:
Danke!
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: 218382
Url: https://administrator.de/forum/l2tp-verbindungsproblem-und-kein-ping-trotz-ipsec-tunnel-218382.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
21 Kommentare
Neuester Kommentar
hello,
eine etwas genauere Beschreibung deiner config wäre interessant.
auf einem hast du 2 tunnel definiert wo er denn falschen nimmt ? desshalb ip missmatch - den nicht benötigten löschen ?
screens?
lg
Mike
eine etwas genauere Beschreibung deiner config wäre interessant.
auf einem hast du 2 tunnel definiert wo er denn falschen nimmt ? desshalb ip missmatch - den nicht benötigten löschen ?
screens?
lg
Mike
Hallo Mike,
hab mal 4 Screenshots dazu gefügt hoffe es ist was passendes dabei.
Danke!
LG mcdy
hab mal 4 Screenshots dazu gefügt hoffe es ist was passendes dabei.
Danke!
LG mcdy
Das du die remoten Geräte nicht erreichen kannst liegt vermutlich daran das
Bedenke das du via VPN nun mit fremden IP Absender Adressen auf diese Geräte zugreifst. Die lokale Firewall der Rechner blockt aber IMMER alle Zugriffe von IP Adressen die NICHT aus dem lokalen Netzen kommen !
Wenn du also die lokale Firewall nicht anpasst, dann ist klar das du nicht zugreifen kannst ! Das weiss jeder Anfänger..?!
- 1.) Entweder deren Default Gateway falsch ist und nicht auf den VPN Router zeigt oder...
- 2.) Daran das du die lokale Firewall dieser Endgeräte nicht angepasst hast !
Bedenke das du via VPN nun mit fremden IP Absender Adressen auf diese Geräte zugreifst. Die lokale Firewall der Rechner blockt aber IMMER alle Zugriffe von IP Adressen die NICHT aus dem lokalen Netzen kommen !
Wenn du also die lokale Firewall nicht anpasst, dann ist klar das du nicht zugreifen kannst ! Das weiss jeder Anfänger..?!
Hallo aqui,
das spannende ist, dass dieser Fehler erst besteht seit ich die USG hingestellt habe, mit der 2 Plus konnte ich pingen usw.
Natürlich war L2TP nicht möglich, weil noch nicht unterstützt, der Fehler ist also neu.
Wenn ich meine Config posten soll, muss ich diese zwar zuvor zensieren, dann wäre das aber durchaus eine Möglichkeit.
Danke!
LG mcdy
das spannende ist, dass dieser Fehler erst besteht seit ich die USG hingestellt habe, mit der 2 Plus konnte ich pingen usw.
Natürlich war L2TP nicht möglich, weil noch nicht unterstützt, der Fehler ist also neu.
Wenn ich meine Config posten soll, muss ich diese zwar zuvor zensieren, dann wäre das aber durchaus eine Möglichkeit.
Danke!
LG mcdy
Na dann ist die Fehlersuche doch ganz einfach und es liegt nur an der USG und du kannst dich ganz darauf konzentrieren.
Vermutlich filtert die dann dediziert ICMP (Ping) und deshalb klappt es nicht ?!
Vermutlich filtert die dann dediziert ICMP (Ping) und deshalb klappt es nicht ?!
Zitat von @mc-doubleyou:
Fangen wir mal mit dem ersten Problem an:
Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird, den
entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
> [ID]: Tunnel [RTBF-Linz_Connection] Remote IP mismatch
Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
Folglich wird der Tunnel nicht aufgebaut
Fangen wir mal mit dem ersten Problem an:
Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird, den
entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
> [ID]: Tunnel [RTBF-Linz_Connection] Remote IP mismatch
Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
Folglich wird der Tunnel nicht aufgebaut
Was mir sofort auffällt ist, dass die Phase2-Policy des L2TPoverIPSec-Tunnels nicht korrekt konfiguriert ist. Unter "local Policy" musst Du bei einer RAS-Regel im Transport-Mode die öffentliche IP-Adresse des Routers angeben bzw. das Objekt, welches diese repräsentiert (kann auch dynamisch sein). Du hast dort hingegen den L2TP-VPN-Pool angegeben.
Im Übrigen kann man Deine Config anhand der Screenshots nur unzureichend prüfen, weil sie a) nur Ausschnitte zeigen und b) nicht erläutert wird, welche Werte sich hinter den Objekten verbergen. Außerdem müsste man wissen, wie der Internetzugang erfolgt: wenn die Einwahl per PPPoE erfolgt, musst Du überall dort, wo Du WAN1 ausgewählt hast, WAN1_ppp angeben.
Sämtliche Deiner Policyrouten sind übrigens bei aktuellem Firmwarestand völlig entbehrlich.
Nun zum zweiten Problem:
Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch
andere) nicht erreichen
Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort von .1
diese kommt aber nie an.
Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch
andere) nicht erreichen
Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort von .1
diese kommt aber nie an.
Und diese Problembeschreibung soll nun ernsthaft ein Außenstehender verstehen? Versetze Dich doch mal ein wenig in unsere Lage!
Zitat von @aqui:
Na dann ist die Fehlersuche doch ganz einfach und es liegt nur an der USG und du kannst dich ganz darauf konzentrieren.
Vermutlich filtert die dann dediziert ICMP (Ping) und deshalb klappt es nicht ?!
Na dann ist die Fehlersuche doch ganz einfach und es liegt nur an der USG und du kannst dich ganz darauf konzentrieren.
Vermutlich filtert die dann dediziert ICMP (Ping) und deshalb klappt es nicht ?!
Ja, das ist naheliegend, nur leider sehe ich nicht wo, allgemein ist alles andere im Netzwerk außer dem Router scheinbar über die interne IP nicht erreichbar.
Zitat von @sk:
> Zitat von @mc-doubleyou:
> ----
> Fangen wir mal mit dem ersten Problem an:
> Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird,
den
> entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
>
> > [ID]: Tunnel [RTBF-Linz_Connection] Remote IP mismatch
>
> Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
> Folglich wird der Tunnel nicht aufgebaut
Was mir sofort auffällt ist, dass die Phase2-Policy des L2TPoverIPSec-Tunnels nicht korrekt konfiguriert ist. Unter
"local Policy" musst Du bei einer RAS-Regel im Transport-Mode die öffentliche IP-Adresse des Routers angeben bzw.
das Objekt, welches diese repräsentiert (kann auch dynamisch sein). Du hast dort hingegen den L2TP-VPN-Pool angegeben.
Im Übrigen kann man Deine Config anhand der Screenshots nur unzureichend prüfen, weil sie a) nur Ausschnitte zeigen und
b) nicht erläutert wird, welche Werte sich hinter den Objekten verbergen. Außerdem müsste man wissen, wie der
Internetzugang erfolgt: wenn die Einwahl per PPPoE erfolgt, musst Du überall dort, wo Du WAN1 ausgewählt hast, WAN1_ppp
angeben.
Sämtliche Deiner Policyrouten sind übrigens bei aktuellem Firmwarestand völlig entbehrlich.
> Zitat von @mc-doubleyou:
> ----
> Fangen wir mal mit dem ersten Problem an:
> Der L2TP Tunnel kann nicht aufgebaut werden, im Log der ZyXEL sehe ich, dass eigentlich auf den falschen Tunnel bezogen wird,
den
> entsprechenden Fehler in der Konfig sehe ich aber leider nicht.
>
> > [ID]: Tunnel [RTBF-Linz_Connection] Remote IP mismatch
>
> Was auch logisch ist weil der L2TP Tunnel sich eigentlich auf diesen Tunnel [L2TP_VPN_Connection] beziehen müsste.
> Folglich wird der Tunnel nicht aufgebaut
Was mir sofort auffällt ist, dass die Phase2-Policy des L2TPoverIPSec-Tunnels nicht korrekt konfiguriert ist. Unter
"local Policy" musst Du bei einer RAS-Regel im Transport-Mode die öffentliche IP-Adresse des Routers angeben bzw.
das Objekt, welches diese repräsentiert (kann auch dynamisch sein). Du hast dort hingegen den L2TP-VPN-Pool angegeben.
Im Übrigen kann man Deine Config anhand der Screenshots nur unzureichend prüfen, weil sie a) nur Ausschnitte zeigen und
b) nicht erläutert wird, welche Werte sich hinter den Objekten verbergen. Außerdem müsste man wissen, wie der
Internetzugang erfolgt: wenn die Einwahl per PPPoE erfolgt, musst Du überall dort, wo Du WAN1 ausgewählt hast, WAN1_ppp
angeben.
Sämtliche Deiner Policyrouten sind übrigens bei aktuellem Firmwarestand völlig entbehrlich.
Ok, den ersten Fehler sollte ich beheben könne, danke mal dafür.
Einwahl erfolgt mit dem Telekom Modem darum müsste auch die Version ohne _ppp passen.
Um ehrlich zu sein, hatte ich das befürchtet, die Policyrouten kamen auch erst als es nicht wie gewünscht funktionierte.
> Nun zum zweiten Problem:
> Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch
> andere) nicht erreichen
> Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort
von .1
> diese kommt aber nie an.
Und diese Problembeschreibung soll nun ernsthaft ein Außenstehender verstehen? Versetze Dich doch mal ein wenig in unsere
Lage!
> Einen Site 2 Site VPN Tunnel konnte ich aufbauen, jedoch kann ich die Remote-Geräte per Ping, SMB (wahrscheinlich auch
> andere) nicht erreichen
> Der Log zeigt einen Empfangten Ping auf .1 an obwohl der Router .254 hat und ich .253 pinge und versendet auch eine Antwort
von .1
> diese kommt aber nie an.
Und diese Problembeschreibung soll nun ernsthaft ein Außenstehender verstehen? Versetze Dich doch mal ein wenig in unsere
Lage!
Sag mir bitte was genau ich posten soll, bzw. eben die gesamte Konfig und ich mach das.
Trotzdem nochmal kurz erklärt was oben steht.
Router: hat die .254
NAS: hat die .235
Wenn ich nun die .253 pinge steht im Log der USG ein Ping auf .1 inkl. einer versendeten Antwort, die kommt aber bei mir am Host nie an, ob mein GW sie bekommt kann ich schlecht prüfen, irgendwie steht im Log nicht alles, obwohl aktiviert.
Danke!
LG mcdy
Zitat von @mc-doubleyou:
Sag mir bitte was genau ich posten soll, bzw. eben die gesamte Konfig und ich mach das.
Sag mir bitte was genau ich posten soll, bzw. eben die gesamte Konfig und ich mach das.
Schick mir mal das Config-File per PN. Kennwörter etc. bitte rauseditieren.
Zitat von @mc-doubleyou:
Trotzdem nochmal kurz erklärt was oben steht.
Router: hat die .254
NAS: hat die .235
Wenn ich nun die .253 pinge steht im Log der USG ein Ping auf .1 inkl. einer versendeten Antwort, die kommt aber bei mir am Host
nie an, ob mein GW sie bekommt kann ich schlecht prüfen, irgendwie steht im Log nicht alles, obwohl aktiviert.
Trotzdem nochmal kurz erklärt was oben steht.
Router: hat die .254
NAS: hat die .235
Wenn ich nun die .253 pinge steht im Log der USG ein Ping auf .1 inkl. einer versendeten Antwort, die kommt aber bei mir am Host
nie an, ob mein GW sie bekommt kann ich schlecht prüfen, irgendwie steht im Log nicht alles, obwohl aktiviert.
Von wo wird denn auf das NAS gepingt? Von der anderen Seite des Tunnels oder lokal?
Ein Screenshot des Logs wäre zudem nicht schlecht... Im Log kann sich zusätzliche Spalten einblenden lassen. Hier bitte auch das Source- und Destination-Interface einblenden!
Hey ..sk..
soll ich zuvor die Sachen welche ich aus Verzweiflung eingebaut habe wieder löschen, oder drinnen lassen?
Danke!
LG mcdy
soll ich zuvor die Sachen welche ich aus Verzweiflung eingebaut habe wieder löschen, oder drinnen lassen?
Danke!
LG mcdy
So wie es ist. Ich hau Dir das dann schon um die Ohren... 
Ich kommentiere Deine Konfig mal öffentlich. Ist ja schließlich ein Forum.
ftp://ftp.zyxel.com/ZyWALL_USG_20/firmware/
So jedenfalls ergibt das keinen Sinn --> löschen!
Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
Ich zitiere: "Bedenke, dass die USG20 zwischen ihrem lokalen Netz und den L2TPVPN-Clients zwingend routen will. Anders als z.B. bei einem Windows-Server kann der IP-Pool der VPN-Clients nicht Teil des lokalen Netzes der USG sein."
Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil) als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen. Hierzu müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
Womit wir beim Thema Policyrouten wären....
Das Routing Richtung WAN1 erfolgt automatisch, weil WAN1 per Default Teil des SYSTEM_DEFAULT_WAN_TRUNKs ist. Jedenfalls sofern keine höher priorisierte Routinginformation (idR eine Policyroute; siehe das obige Thema Eingriff in die Abarbeitungsreihenfolge!) zuvor greift.
Das erforderliche Source-NAT beim Übergang vom LAN nach WAN erledigt die Zywall ebenfalls automatisch. Sofern nicht deaktiviert oder übersteuert, tut sie dies immer dann, wenn der Traffic von einem "internal Interface" zu einem "external Interface" wechselt. Bei den kleinen Zywalls rauf bis zur 200er ist der Interfacetyp der Ethernetinterfaces (mit Ausnahme des Opt-Ports) "hart verdrahtet". Erst aber der 300er aufwährts sind alle Ports frei konfigurierbar. Lediglich bei VLAN- und Bridge-Interfaces geht dies auch bei den kleineren Modellen.
Diese Policy kann also ersatzlos entfallen.
Versuch macht "kluch"...
Diese Einstellung soll natürlich ermöglichen, dass man zur ZyWALL ein SSL-VPN aufbauen kann. M.E. gehören aber Admins, die SSL-VPN auf der Frontfirewall implementieren ebenso an die Wand gestellt! Soetwas gehört auf eine separate Appliance in der DMZ.
Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
Gruß
Steffen
03. ! firmware version: 3.00(BDQ.1)
Bitte auf die aktuelle Version updaten!ftp://ftp.zyxel.com/ZyWALL_USG_20/firmware/
412. ip virtual-server NAT interface wan1 original-ip LAN1_SUBNET map-to LAN1_SUBNET map-type any nat-loopback nat-1-1-map
Was soll das bewirken?So jedenfalls ergibt das keinen Sinn --> löschen!
410. ip ip-mac-binding lan1 log
Benutze ich ungern. Wenn man vergessen hat, dass diese Option an ist und man versucht von einem Host mit statischer IP zuzugreifen, sucht man sich einen Wolf. Immerhin ist das Logging an.598. policy controll-ipsec-dynamic-rules activate
Dies ist eine der Optionen, die es dem Admin ermöglicht, den Paketflow innerhalb der Box - also die Abarbeitungsreihenfolge/Prioritäten von Routinginformationen und damit das grundsätzliche Verhalten der ZyWALL - zu verändern. Für Neueinsteiger in ZLD sicherlich "harter Tobak" und nur verständlich, wenn man tiefer einsteigt und sich vorallem mit von älteren Firmwareständen übernommenden Konfigurationen beschäftigen muss.Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
64. interface lan1
65. ip address 10.20.40.254 255.255.255.0
88. address-object L2TP_VPN_Pool 10.20.40.101-10.20.40.150
Das ist schonmal der Kardinalsfehler! Darauf hatte ich in Deinem anderen Thread auch schon hingewiesen. Siehe ZyXEL ZyWALL WAN2 für Test Netz65. ip address 10.20.40.254 255.255.255.0
88. address-object L2TP_VPN_Pool 10.20.40.101-10.20.40.150
Ich zitiere: "Bedenke, dass die USG20 zwischen ihrem lokalen Netz und den L2TPVPN-Clients zwingend routen will. Anders als z.B. bei einem Windows-Server kann der IP-Pool der VPN-Clients nicht Teil des lokalen Netzes der USG sein."
Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil) als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen. Hierzu müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
Womit wir beim Thema Policyrouten wären....
618. policy 4
619. interface lan1
620. source LAN1_SUBNET
621. dscp any
622. next-hop interface wan1
623. snat outgoing-interface
Diese Policy ist in Deiner Konfiguration bei diesem Firmwarestand nicht erforderlich.619. interface lan1
620. source LAN1_SUBNET
621. dscp any
622. next-hop interface wan1
623. snat outgoing-interface
Das Routing Richtung WAN1 erfolgt automatisch, weil WAN1 per Default Teil des SYSTEM_DEFAULT_WAN_TRUNKs ist. Jedenfalls sofern keine höher priorisierte Routinginformation (idR eine Policyroute; siehe das obige Thema Eingriff in die Abarbeitungsreihenfolge!) zuvor greift.
Das erforderliche Source-NAT beim Übergang vom LAN nach WAN erledigt die Zywall ebenfalls automatisch. Sofern nicht deaktiviert oder übersteuert, tut sie dies immer dann, wenn der Traffic von einem "internal Interface" zu einem "external Interface" wechselt. Bei den kleinen Zywalls rauf bis zur 200er ist der Interfacetyp der Ethernetinterfaces (mit Ausnahme des Opt-Ports) "hart verdrahtet". Erst aber der 300er aufwährts sind alle Ports frei konfigurierbar. Lediglich bei VLAN- und Bridge-Interfaces geht dies auch bei den kleineren Modellen.
Diese Policy kann also ersatzlos entfallen.
612. policy 3
613. source LAN1_SUBNET
615. destination LAN_RTBF-Linz
616. next-hop tunnel RTBF-Linz_Connection
Diese Informationen hat die Zywall bereits aus der Crypto-Map des S2S-Tunnels. Auch diese Policy kann also ersatzlos entfallen.613. source LAN1_SUBNET
615. destination LAN_RTBF-Linz
616. next-hop tunnel RTBF-Linz_Connection
606. policy 2
607. source any
609. destination L2TP_VPN_Pool
610. next-hop tunnel L2TP_VPN_Connection
Auch das ist der ZyWALL nicht neu. Weiss sie bereits aus der L2TP-Konfiguration und wird hier auch nicht von anderen erforderlichen Policyrouten übersteuert. Also weg damit!607. source any
609. destination L2TP_VPN_Pool
610. next-hop tunnel L2TP_VPN_Connection
600. policy 1
601. source L2TP_VPN_Pool
603. next-hop trunk SYSTEM_DEFAULT_WAN_TRUNK
604. snat outgoing-interface
Diese Policy-Route ist vermutlich die einzige, die bleiben muss. Die Wegefindung ist der Zywall bereits klar. Jedoch würde sie kein SNAT machen, weil der VPN-Tunnel nicht als "internal Interface" (siehe oben) geflagt ist. Jedenfalls war dies noch vor einigen Firmwareversionen so, als ich dies das letzte Mal getestet hatte. Es ist durchaus möglich, dass dies zwischenzeitlich gefixt wurde. ZLD3.30 habe ich z.B. noch gar nicht angetestet.601. source L2TP_VPN_Pool
603. next-hop trunk SYSTEM_DEFAULT_WAN_TRUNK
604. snat outgoing-interface
Versuch macht "kluch"...
246. object-group service Default_Allow_WAN_To_ZyWALL
247. description System Default Allow From WAN To ZyWALL
248. service-object AH
249. service-object ESP
250. service-object HTTPS
251. service-object IKE
252. service-object NATT
253. service-object GRE
254. service-object VRRP
255. service-object L2TP-UDP
In Verbindung mit dem Default-Firewallregelwerk bewirkt dies, dass das Webinterface der Zywall per Default vom Internet aus per HTTPS erreichbar ist. Und da dies von Zyxel so unauffällig in einer Service-Gruppe versteckt wurde, merken dies die meisten Admins noch nicht einmal! Diejenigen, die dies zu verantworten haben, gehören an die Wand gestellt!247. description System Default Allow From WAN To ZyWALL
248. service-object AH
249. service-object ESP
250. service-object HTTPS
251. service-object IKE
252. service-object NATT
253. service-object GRE
254. service-object VRRP
255. service-object L2TP-UDP
Diese Einstellung soll natürlich ermöglichen, dass man zur ZyWALL ein SSL-VPN aufbauen kann. M.E. gehören aber Admins, die SSL-VPN auf der Frontfirewall implementieren ebenso an die Wand gestellt! Soetwas gehört auf eine separate Appliance in der DMZ.
Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
Gruß
Steffen
Zitat von @sk:
Ich kommentiere Deine Konfig mal öffentlich. Ist ja schließlich ein Forum.
> 03. ! firmware version: 3.00(BDQ.1)
Bitte auf die aktuelle Version updaten!
ftp://ftp.zyxel.com/ZyWALL_USG_20/firmware/
Ich kommentiere Deine Konfig mal öffentlich. Ist ja schließlich ein Forum.
> 03. ! firmware version: 3.00(BDQ.1)
Bitte auf die aktuelle Version updaten!
ftp://ftp.zyxel.com/ZyWALL_USG_20/firmware/
damit hatte ich schon fast gerechnet, musste aber ohnehin warten bis die Kollegen nicht arbeiten (mach also grad das Update)
> 412. ip virtual-server NAT interface wan1 original-ip LAN1_SUBNET map-to LAN1_SUBNET map-type any nat-loopback nat-1-1-map
Was soll das bewirken?
So jedenfalls ergibt das keinen Sinn --> löschen!
Was soll das bewirken?
So jedenfalls ergibt das keinen Sinn --> löschen!
keine Ahnung wo ich das eingestellt haben könnte, du?
> 410. ip ip-mac-binding lan1 log
Benutze ich ungern. Wenn man vergessen hat, dass diese Option an ist und man versucht von einem Host mit statischer IP
zuzugreifen, sucht man sich einen Wolf. Immerhin ist das Logging an.
Benutze ich ungern. Wenn man vergessen hat, dass diese Option an ist und man versucht von einem Host mit statischer IP
zuzugreifen, sucht man sich einen Wolf. Immerhin ist das Logging an.
ist das das statische DHCP? wenn ja ist das gewollt
> 598. policy controll-ipsec-dynamic-rules activate
Dies ist eine der Optionen, die es dem Admin ermöglicht, den Paketflow innerhalb der Box - also die
Abarbeitungsreihenfolge/Prioritäten von Routinginformationen und damit das grundsätzliche Verhalten der ZyWALL - zu
verändern. Für Neueinsteiger in ZLD sicherlich "harter Tobak" und nur verständlich, wenn man tiefer
einsteigt und sich vorallem mit von älteren Firmwareständen übernommenden Konfigurationen beschäftigen muss.
Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu
DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
Dies ist eine der Optionen, die es dem Admin ermöglicht, den Paketflow innerhalb der Box - also die
Abarbeitungsreihenfolge/Prioritäten von Routinginformationen und damit das grundsätzliche Verhalten der ZyWALL - zu
verändern. Für Neueinsteiger in ZLD sicherlich "harter Tobak" und nur verständlich, wenn man tiefer
einsteigt und sich vorallem mit von älteren Firmwareständen übernommenden Konfigurationen beschäftigen muss.
Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu
DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
sagt mir gar nichts, wo finde ich das?
> 64. interface lan1
> 65. ip address 10.20.40.254 255.255.255.0
>
> 88. address-object L2TP_VPN_Pool 10.20.40.101-10.20.40.150
Das ist schonmal der Kardinalsfehler! Darauf hatte ich in Deinem anderen Thread auch schon hingewiesen. Siehe
ZyXEL ZyWALL WAN2 für Test Netz
Ich zitiere: "Bedenke, dass die USG20 zwischen ihrem lokalen Netz und den L2TPVPN-Clients zwingend routen will. Anders als
z.B. bei einem Windows-Server kann der IP-Pool der VPN-Clients nicht Teil des lokalen Netzes der USG sein."
Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen
Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu
halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil)
als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch
die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen. Hierzu
müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz
von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende
Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls
bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic
explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
Womit wir beim Thema Policyrouten wären....
> 65. ip address 10.20.40.254 255.255.255.0
>
> 88. address-object L2TP_VPN_Pool 10.20.40.101-10.20.40.150
Das ist schonmal der Kardinalsfehler! Darauf hatte ich in Deinem anderen Thread auch schon hingewiesen. Siehe
ZyXEL ZyWALL WAN2 für Test Netz
Ich zitiere: "Bedenke, dass die USG20 zwischen ihrem lokalen Netz und den L2TPVPN-Clients zwingend routen will. Anders als
z.B. bei einem Windows-Server kann der IP-Pool der VPN-Clients nicht Teil des lokalen Netzes der USG sein."
Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen
Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu
halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil)
als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch
die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen. Hierzu
müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz
von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende
Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls
bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic
explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
Womit wir beim Thema Policyrouten wären....
hatte gehofft wenn man es in einer Range definiert geht es, also wenn ich es wirklich so machen will müsste ich alles neu aufziehen und das Netz Subneten? Ansonsten eigenes Netz für den VPN Pool (achja wie löse ich das dann wegen der Fernwartung? immerhin kennt die ZyXEL in zB Linz nicht ob die ZyXEL in Freistadt bereits diese IP Adresse vergeben hat, darum ja eigentlich auch die direkte Zuordnung)
> 618. policy 4
> 619. interface lan1
> 620. source LAN1_SUBNET
> 621. dscp any
> 622. next-hop interface wan1
> 623. snat outgoing-interface
Diese Policy ist in Deiner Konfiguration bei diesem Firmwarestand nicht erforderlich.
Das Routing Richtung WAN1 erfolgt automatisch, weil WAN1 per Default Teil des SYSTEM_DEFAULT_WAN_TRUNKs ist. Jedenfalls sofern
keine höher priorisierte Routinginformation (idR eine Policyroute; siehe das obige Thema Eingriff in die
Abarbeitungsreihenfolge!) zuvor greift.
Das erforderliche Source-NAT beim Übergang vom LAN nach WAN erledigt die Zywall ebenfalls automatisch. Sofern nicht
deaktiviert oder übersteuert, tut sie dies immer dann, wenn der Traffic von einem "internal Interface" zu einem
"external Interface" wechselt. Bei den kleinen Zywalls rauf bis zur 200er ist der Interfacetyp der Ethernetinterfaces
(mit Ausnahme des Opt-Ports) "hart verdrahtet". Erst aber der 300er aufwährts sind alle Ports frei konfigurierbar.
Lediglich bei VLAN- und Bridge-Interfaces geht dies auch bei den kleineren Modellen.
Diese Policy kann also ersatzlos entfallen.
> 612. policy 3
> 613. source LAN1_SUBNET
> 615. destination LAN_RTBF-Linz
> 616. next-hop tunnel RTBF-Linz_Connection
Diese Informationen hat die Zywall bereits aus der Crypto-Map des S2S-Tunnels. Auch diese Policy kann also ersatzlos entfallen.
> 606. policy 2
> 607. source any
> 609. destination L2TP_VPN_Pool
> 610. next-hop tunnel L2TP_VPN_Connection
Auch das ist der ZyWALL nicht neu. Weiss sie bereits aus der L2TP-Konfiguration und wird hier auch nicht von anderen
erforderlichen Policyrouten übersteuert. Also weg damit!
> 619. interface lan1
> 620. source LAN1_SUBNET
> 621. dscp any
> 622. next-hop interface wan1
> 623. snat outgoing-interface
Diese Policy ist in Deiner Konfiguration bei diesem Firmwarestand nicht erforderlich.
Das Routing Richtung WAN1 erfolgt automatisch, weil WAN1 per Default Teil des SYSTEM_DEFAULT_WAN_TRUNKs ist. Jedenfalls sofern
keine höher priorisierte Routinginformation (idR eine Policyroute; siehe das obige Thema Eingriff in die
Abarbeitungsreihenfolge!) zuvor greift.
Das erforderliche Source-NAT beim Übergang vom LAN nach WAN erledigt die Zywall ebenfalls automatisch. Sofern nicht
deaktiviert oder übersteuert, tut sie dies immer dann, wenn der Traffic von einem "internal Interface" zu einem
"external Interface" wechselt. Bei den kleinen Zywalls rauf bis zur 200er ist der Interfacetyp der Ethernetinterfaces
(mit Ausnahme des Opt-Ports) "hart verdrahtet". Erst aber der 300er aufwährts sind alle Ports frei konfigurierbar.
Lediglich bei VLAN- und Bridge-Interfaces geht dies auch bei den kleineren Modellen.
Diese Policy kann also ersatzlos entfallen.
> 612. policy 3
> 613. source LAN1_SUBNET
> 615. destination LAN_RTBF-Linz
> 616. next-hop tunnel RTBF-Linz_Connection
Diese Informationen hat die Zywall bereits aus der Crypto-Map des S2S-Tunnels. Auch diese Policy kann also ersatzlos entfallen.
> 606. policy 2
> 607. source any
> 609. destination L2TP_VPN_Pool
> 610. next-hop tunnel L2TP_VPN_Connection
Auch das ist der ZyWALL nicht neu. Weiss sie bereits aus der L2TP-Konfiguration und wird hier auch nicht von anderen
erforderlichen Policyrouten übersteuert. Also weg damit!
das sind die erwähnten Verzweiflungstaten ^^
> 600. policy 1
> 601. source L2TP_VPN_Pool
> 603. next-hop trunk SYSTEM_DEFAULT_WAN_TRUNK
> 604. snat outgoing-interface
Diese Policy-Route ist vermutlich die einzige, die bleiben muss. Die Wegefindung ist der Zywall bereits klar. Jedoch würde
sie kein SNAT machen, weil der VPN-Tunnel nicht als "internal Interface" (siehe oben) geflagt ist. Jedenfalls war dies
noch vor einigen Firmwareversionen so, als ich dies das letzte Mal getestet hatte. Es ist durchaus möglich, dass dies
zwischenzeitlich gefixt wurde. ZLD3.30 habe ich z.B. noch gar nicht angetestet.
Versuch macht "kluch"...
> 601. source L2TP_VPN_Pool
> 603. next-hop trunk SYSTEM_DEFAULT_WAN_TRUNK
> 604. snat outgoing-interface
Diese Policy-Route ist vermutlich die einzige, die bleiben muss. Die Wegefindung ist der Zywall bereits klar. Jedoch würde
sie kein SNAT machen, weil der VPN-Tunnel nicht als "internal Interface" (siehe oben) geflagt ist. Jedenfalls war dies
noch vor einigen Firmwareversionen so, als ich dies das letzte Mal getestet hatte. Es ist durchaus möglich, dass dies
zwischenzeitlich gefixt wurde. ZLD3.30 habe ich z.B. noch gar nicht angetestet.
Versuch macht "kluch"...
OK, werd ich testen
> 246. object-group service Default_Allow_WAN_To_ZyWALL
> 247. description System Default Allow From WAN To ZyWALL
> 248. service-object AH
> 249. service-object ESP
> 250. service-object HTTPS
> 251. service-object IKE
> 252. service-object NATT
> 253. service-object GRE
> 254. service-object VRRP
> 255. service-object L2TP-UDP
In Verbindung mit dem Default-Firewallregelwerk bewirkt dies, dass das Webinterface der Zywall per Default vom Internet aus per
HTTPS erreichbar ist. Und da dies von Zyxel so unauffällig in einer Service-Gruppe versteckt wurde, merken dies die meisten
Admins noch nicht einmal! Diejenigen, die dies zu verantworten haben, gehören an die Wand gestellt!
Diese Einstellung soll natürlich ermöglichen, dass man zur ZyWALL ein SSL-VPN aufbauen kann. M.E. gehören aber
Admins, die SSL-VPN auf der Frontfirewall implementieren ebenso an die Wand gestellt! Soetwas gehört auf eine separate
Appliance in der DMZ.
Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
> 247. description System Default Allow From WAN To ZyWALL
> 248. service-object AH
> 249. service-object ESP
> 250. service-object HTTPS
> 251. service-object IKE
> 252. service-object NATT
> 253. service-object GRE
> 254. service-object VRRP
> 255. service-object L2TP-UDP
In Verbindung mit dem Default-Firewallregelwerk bewirkt dies, dass das Webinterface der Zywall per Default vom Internet aus per
HTTPS erreichbar ist. Und da dies von Zyxel so unauffällig in einer Service-Gruppe versteckt wurde, merken dies die meisten
Admins noch nicht einmal! Diejenigen, die dies zu verantworten haben, gehören an die Wand gestellt!
Diese Einstellung soll natürlich ermöglichen, dass man zur ZyWALL ein SSL-VPN aufbauen kann. M.E. gehören aber
Admins, die SSL-VPN auf der Frontfirewall implementieren ebenso an die Wand gestellt! Soetwas gehört auf eine separate
Appliance in der DMZ.
Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
Es ist gewünscht den Zugriff mittels https auf der externen IP Adresse zu haben für den Fall das der VPN Tunnel mal nicht will oder so, damit muss ich also leben.
Die Erklärungen oben werden Schuld am nicht funktionierenden VPN Tunnel L2TP sein.
Habe ich die Lösung für mein Verbindungsproblem trotz Tunnel bei Site 2 Site überlesen oder brauchst du da eine andere Info und konntest daher nichts finden?
Danke und schönes WE!
mcdy
1
Ja, denn Kollege hat das ja unter dem Stichwort "Kardinalsfehler" hinreichend genau beschrieben !
Fixe das, dann lösst das auch dein Verbindungsproblem...!
Fixe das, dann lösst das auch dein Verbindungsproblem...!
Zitat von @mc-doubleyou:
Zitat von @sk:
>> 412. ip virtual-server NAT interface wan1 original-ip LAN1_SUBNET map-to LAN1_SUBNET map-type
>> any nat-loopback nat-1-1-map
> Was soll das bewirken?
> So jedenfalls ergibt das keinen Sinn --> löschen!
keine Ahnung wo ich das eingestellt haben könnte, du?
Configuration>Network>NATZitat von @sk:
>> 412. ip virtual-server NAT interface wan1 original-ip LAN1_SUBNET map-to LAN1_SUBNET map-type
>> any nat-loopback nat-1-1-map
> Was soll das bewirken?
> So jedenfalls ergibt das keinen Sinn --> löschen!
keine Ahnung wo ich das eingestellt haben könnte, du?
Zitat von @mc-doubleyou:
> Zitat von @sk:
>> 410. ip ip-mac-binding lan1 log
> Benutze ich ungern. Wenn man vergessen hat, dass diese Option an ist und man versucht von einem Host mit statischer IP
> zuzugreifen, sucht man sich einen Wolf. Immerhin ist das Logging an.
ist das das statische DHCP? wenn ja ist das gewollt
Diese Einstellung bewirkt, dass die Zywall nur IP-Traffic von MAC-Adressen akzeptiert, denen Sie zuvor über ihren DHCP-Server eine IP-Adresse zugeteilt hat.> Zitat von @sk:
>> 410. ip ip-mac-binding lan1 log
> Benutze ich ungern. Wenn man vergessen hat, dass diese Option an ist und man versucht von einem Host mit statischer IP
> zuzugreifen, sucht man sich einen Wolf. Immerhin ist das Logging an.
ist das das statische DHCP? wenn ja ist das gewollt
Static DHCP kann man unabhängig davon machen, ob diese Option nun ein- oder ausgeschaltet ist. Die Option schließt nur den Zugriff durch händisch konfigurierte Hosts aus.
Zitat von @mc-doubleyou:
> Zitat von @sk:
> > 598. policy controll-ipsec-dynamic-rules activate
> Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu
> DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
sagt mir gar nichts, wo finde ich das?
Configuration>VPN>IPSec-VPN>VPN-Connection>Global Setting> Zitat von @sk:
> > 598. policy controll-ipsec-dynamic-rules activate
> Diese Option ist m.W. seit ZLD2.20 per Default eingeschaltet. In 90% der Fälle ist es jedoch m.E. sinnvoller, sie zu
> DEaktivieren! In Deiner einfachen Konfig wird sie aber (zunächst) keine Relevanz haben.
sagt mir gar nichts, wo finde ich das?
Zitat von @mc-doubleyou:
> Zitat von @sk:
> Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen
> Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu
> halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil)
> als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch
> die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen.
> Hierzu müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz
> von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende
> Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls
> bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic
> explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
hatte gehofft wenn man es in einer Range definiert geht es, also wenn ich es wirklich so machen will müsste ich alles neu
aufziehen und das Netz Subneten? Ansonsten eigenes Netz für den VPN Pool (achja wie löse ich das dann wegen der
Fernwartung? immerhin kennt die ZyXEL in zB Linz nicht ob die ZyXEL in Freistadt bereits diese IP Adresse vergeben hat, darum ja
eigentlich auch die direkte Zuordnung)
Häh? Lies noch einmal, was ich geschrieben habe. Steht doch eigentlich alles drin.> Zitat von @sk:
> Du musst den L2TP-IP-Pool also in ein bislang ungenutztes Netz verlegen. Dabei sind natürlich Deine funktionalen
> Anforderungen im Adressierungskonzept zu berücksichtigen, um die Konfiguration auch weiterhin möglichst einfach zu
> halten. Ideal wäre es z.B., wenn das Netz 10.20.41.0/24 noch nicht in Verwendung wäre und dieses (zumindest zum Teil)
> als L2TP-Pool verwendet würde. Dies würde es nämlich ermöglichen, mit minimalstem Konfigurationsaufwand auch
> die Kommunikation zwischen den L2TP-Clients und dem Remotenetzwerk des IPSec-Site-to-Site-Tunnels zu ermöglichen.
> Hierzu müsste in der Crypto-Map des S2S-Tunnels als "local Policy" ein Objekt angegeben werden, welches sowohl das Netz
> von LAN1 als auch den L2TP-Pool umfasst. Also im Beispiel 10.20.40.0/23 (=10.20.40.0-10.20.41.255). Eine korrespondierende
> Konfigurationsänderung muss selbstverständlich auch auf dem Remotegateway durchgeführt werden. Anderenfalls
> bräuchte man für die gleiche Funktionalität entweder eine zweite Crypto-Map oder man müsste den Traffic
> explizit per Policyroute in den Tunnel zwingen, was voraussetzt, dass beim Remotegateway selbiges möglich ist.
hatte gehofft wenn man es in einer Range definiert geht es, also wenn ich es wirklich so machen will müsste ich alles neu
aufziehen und das Netz Subneten? Ansonsten eigenes Netz für den VPN Pool (achja wie löse ich das dann wegen der
Fernwartung? immerhin kennt die ZyXEL in zB Linz nicht ob die ZyXEL in Freistadt bereits diese IP Adresse vergeben hat, darum ja
eigentlich auch die direkte Zuordnung)
Um Tips zu geben, müsste ich Dein Adressierungsschema kennen.
Zitat von @mc-doubleyou:
> Zitat von @sk:
> Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
Es ist gewünscht den Zugriff mittels https auf der externen IP Adresse zu haben für den Fall das der VPN Tunnel mal
nicht will oder so, damit muss ich also leben.
Dann schränke den HTTPS-Zugriff per Firewall auf legitime feste Absender-IP-Adressen ein. Alles andere ist nicht zu verantworten.> Zitat von @sk:
> Also nimm HTTPS aus der Gruppe raus oder noch besser: wirf das gesamte Default-Regelwerk weg und setze es neu auf!
Es ist gewünscht den Zugriff mittels https auf der externen IP Adresse zu haben für den Fall das der VPN Tunnel mal
nicht will oder so, damit muss ich also leben.
Zitat von @mc-doubleyou:
Die Erklärungen oben werden Schuld am nicht funktionierenden VPN Tunnel L2TP sein.
Habe ich die Lösung für mein Verbindungsproblem trotz Tunnel bei Site 2 Site überlesen oder brauchst du da eine
andere Info und konntest daher nichts finden?
Zum einen warte ich noch auf eine Antwort zu meiner Nachfrage und zum anderen wurden mit der unsinnigen NAT-Regel und dem IP-MAC-Binding auch zwei mögliche Ursachen aufgezeigt, die es zunächst einmal auszuschließen gilt.Die Erklärungen oben werden Schuld am nicht funktionierenden VPN Tunnel L2TP sein.
Habe ich die Lösung für mein Verbindungsproblem trotz Tunnel bei Site 2 Site überlesen oder brauchst du da eine
andere Info und konntest daher nichts finden?
Gruß
sk
Hallo zusammen,
endlich hab ich wieder ein bisschen Zeit mich damit zu beschäftigen und dabei ist gleich mal die erste Frage aufgetaucht, bin mir zwar ziemlich sicher aber eben doch nicht ganz.
Unser LAN ist so aufgebaut: 10.20.x.y wobei x für eine Betriebsstätte steht und y ist Host.
Nun darf ja wie bereits von euch erwähnt, eigentlich Schade weil schöner, die VPN Adresse nicht in diesem Bereich liegen.
Darum zuerst der Gedanke es so aufzubauen: 10.20.1x.y also zB.: 10.20.132.y nur stosse ich so schnell an meine Grenzen,
darum nun der Gedanke es besser so zu machen: 10.30.x.y liegt damit natürlich nicht im Netz und sollte bis auf ein paar Firewallerweiterungen eigentlich funktionieren oder?
Danke!
LG mcdy
endlich hab ich wieder ein bisschen Zeit mich damit zu beschäftigen und dabei ist gleich mal die erste Frage aufgetaucht, bin mir zwar ziemlich sicher aber eben doch nicht ganz.
Unser LAN ist so aufgebaut: 10.20.x.y wobei x für eine Betriebsstätte steht und y ist Host.
Nun darf ja wie bereits von euch erwähnt, eigentlich Schade weil schöner, die VPN Adresse nicht in diesem Bereich liegen.
Darum zuerst der Gedanke es so aufzubauen: 10.20.1x.y also zB.: 10.20.132.y nur stosse ich so schnell an meine Grenzen,
darum nun der Gedanke es besser so zu machen: 10.30.x.y liegt damit natürlich nicht im Netz und sollte bis auf ein paar Firewallerweiterungen eigentlich funktionieren oder?
Danke!
LG mcdy
Hallo,
ich habe eben eine weitere Schwachstelle entdeckt.
Unser IT Helpdesk (so auch ich) sind unter 10.20.20.y wenn die mobilen Geräte nun 10.30.x.y haben kann ich mich doch gar nicht auf die Geräte verbinden oder?
Es ist zwar ein Tunnel zwischen 10.20.20.0 und 10.20.x.0 der nutzt da dann aber herzlich wenig, oder? Kann ich also mobile Geräte nicht fernwarten?
Hoffe ihr könnt den Konten lösen, falls eine Skizze oder so nötig ist kann ich diese gerne nachreichen.
Danke!
LG mcdy
ich habe eben eine weitere Schwachstelle entdeckt.
Unser IT Helpdesk (so auch ich) sind unter 10.20.20.y wenn die mobilen Geräte nun 10.30.x.y haben kann ich mich doch gar nicht auf die Geräte verbinden oder?
Es ist zwar ein Tunnel zwischen 10.20.20.0 und 10.20.x.0 der nutzt da dann aber herzlich wenig, oder? Kann ich also mobile Geräte nicht fernwarten?
Hoffe ihr könnt den Konten lösen, falls eine Skizze oder so nötig ist kann ich diese gerne nachreichen.
Danke!
LG mcdy
Das lässt sich alles lösen. Um qualifizierte Tips zu geben, benötige ich aber - wie bereits erwähnt - das gesamte bisherige IP-Adressschema. Am besten als Skizze und unter Angabe der Typbezeichnung der verwendeten Router. Alte ZyNOS-Gateways wie z.B. die 2Plus sind in ihren Konfigurationsmöglichkeiten halt eingeschränkt im Vergleich zur USG-Serie und geben daher u.U. ein bestimmtes Design vor...
Gruß
sk
P.S.
IP-Netze bitte immer mit verwendeter Subnetzmaske angeben. Am besten per Bitnotation! Formulierungen wie 192.168.x.y gehören in den Kindergarten!
Gruß
sk
P.S.
IP-Netze bitte immer mit verwendeter Subnetzmaske angeben. Am besten per Bitnotation! Formulierungen wie 192.168.x.y gehören in den Kindergarten!
Hallo ..sk..
ich hoffe diese Skizze ist nützlich, sie zeigt das Schema einer Betriebstätte, alle anderen sind gleich aufgebaut.
https://docs.google.com/file/d/0B1ccie93EagxcjdBckZWWnFIOEE
derzeit existieren 22 Betriebsstätten
Falls noch was offen ist bitte einfach sagen.
Danke!
LG mcdy
ich hoffe diese Skizze ist nützlich, sie zeigt das Schema einer Betriebstätte, alle anderen sind gleich aufgebaut.
https://docs.google.com/file/d/0B1ccie93EagxcjdBckZWWnFIOEE
| LAN | mobil (VPN) | Kommentar | |
|---|---|---|---|
| Zentrale | 10.20.20.0/24 | 10.30.20.0/24 | Verbindung in jede Betriebstätte und zu mobil (Fernwartung) |
| Betriebsstätte 1 | 10.20.21.0/24 | 10.30.21.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 1, teilweise Betriebstätten untereinander |
| Betriebsstätte 2 | 10.20.22.0/24 | 10.30.22.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 2 |
| Betriebsstätte 3 | 10.20.23.0/24 | 10.30.23.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 3 |
| Betriebsstätte 4 | 10.20.24.0/24 | 10.30.24.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 4 |
| Betriebsstätte 5 | 10.20.25.0/24 | 10.30.25.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 5, teilweise Betriebstätten untereinander |
| Betriebsstätte 6 | 10.20.26.0/24 | 10.30.26.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 6 |
| Betriebsstätte 7 | 10.20.27.0/24 | 10.30.27.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 7 |
| Betriebsstätte 8 | 10.20.28.0/24 | 10.30.28.0/24 | Verbindung in Zentrale und von mobil zu Betriebstätte 8 |
| Betriebsstätte 9 | … | … | Verbindung in Zentrale und von mobil zu Betriebstätte 9, teilweise Betriebstätten untereinander |
derzeit existieren 22 Betriebsstätten
Falls noch was offen ist bitte einfach sagen.
Danke!
LG mcdy
Muss an jedem Standort zwingend eine direkte Einwahl per L2TP-VPN möglich sein oder genügt es, wenn die Einwahl nur an der Zentrale erfolgt und von dort der VPN-Client auch auf die Betriebsstätten zugreifen kann?
Aus administrativer Sicht empfiehlt es sich, alle Tunnel - egal ob Site-to-Site oder Client-to-Site - immer an der Zentrale zu terminieren und dort die Zugriffberechtigungen per Firewallregelwerk zu reglementieren. Also z.B. Betriebsstätte 1 darf nach BS 2 aber nicht nach BS 3 usw. Im Falle der L2TP-VPN-Einwahl kann man dies sogar Benutzerabhängig regeln - und zwar single sign-on!
Das wäre eine simple Hub-and-Spoke-Konfiguration, wie ich sie bereits seit Jahren betreibe. Mit vorliegendem Adressierungsschema auch problemlos umzusetzen. Voraussetzung ist freilich, dass die Internetanbindung der Zentrale ausreichend performant und zuverlässig ist und dass die Anzahl der VPN-Tunnel, die die dortige Zywall unterstützt, ausreicht.
Gruß
sk
Aus administrativer Sicht empfiehlt es sich, alle Tunnel - egal ob Site-to-Site oder Client-to-Site - immer an der Zentrale zu terminieren und dort die Zugriffberechtigungen per Firewallregelwerk zu reglementieren. Also z.B. Betriebsstätte 1 darf nach BS 2 aber nicht nach BS 3 usw. Im Falle der L2TP-VPN-Einwahl kann man dies sogar Benutzerabhängig regeln - und zwar single sign-on!
Das wäre eine simple Hub-and-Spoke-Konfiguration, wie ich sie bereits seit Jahren betreibe. Mit vorliegendem Adressierungsschema auch problemlos umzusetzen. Voraussetzung ist freilich, dass die Internetanbindung der Zentrale ausreichend performant und zuverlässig ist und dass die Anzahl der VPN-Tunnel, die die dortige Zywall unterstützt, ausreicht.
Gruß
sk
Hallo ..sk..
muss ist wahrscheinlich übertrieben, aber da die Verbindung über die Zentrale sicher die Performance beeinträchtigen würde entstand der Gedanke immer die jeweilige Betriebsstätte mit den mobilen zu "belasten", sozusagen loadbalancing in simpelster Form.
Wenn ich nun wie von euch erwähnt das mobile VPN Netz vom eigentlichen abtrenne, was zumindest bei ZyXEL zwingend nötig ist, dann besteht eben das Problem bei der Fernwartung. Ich könnte nun für diese Fälle TeamViewer als Alternative nehmen, aber eigentlich wäre das nicht die angestrebte Lösung welche im Konzept definiert ist.
Im Konzept wäre eben geplant gewesen einen Teilbereich des Netzes für VPN zu reservieren. Ich könnte also im schlimmsten Fall das Netzt auch subneten, was aber die Struktur des Netzes zerstört.
1 ... - LAN
250 bis 252 - Drucker
253 - Netzlaufwerk
254 - Router
Ich mache aber was immer nötig ist um mein Konzept technisch umzusetzen und bin für die Hilfe sehr sehr dankbar!
LG mcdy
muss ist wahrscheinlich übertrieben, aber da die Verbindung über die Zentrale sicher die Performance beeinträchtigen würde entstand der Gedanke immer die jeweilige Betriebsstätte mit den mobilen zu "belasten", sozusagen loadbalancing in simpelster Form.
Wenn ich nun wie von euch erwähnt das mobile VPN Netz vom eigentlichen abtrenne, was zumindest bei ZyXEL zwingend nötig ist, dann besteht eben das Problem bei der Fernwartung. Ich könnte nun für diese Fälle TeamViewer als Alternative nehmen, aber eigentlich wäre das nicht die angestrebte Lösung welche im Konzept definiert ist.
Im Konzept wäre eben geplant gewesen einen Teilbereich des Netzes für VPN zu reservieren. Ich könnte also im schlimmsten Fall das Netzt auch subneten, was aber die Struktur des Netzes zerstört.
1 ... - LAN
250 bis 252 - Drucker
253 - Netzlaufwerk
254 - Router
Ich mache aber was immer nötig ist um mein Konzept technisch umzusetzen und bin für die Hilfe sehr sehr dankbar!
LG mcdy
Zitat von @mc-doubleyou:
muss ist wahrscheinlich übertrieben, aber da die Verbindung über die Zentrale sicher die Performance
beeinträchtigen würde entstand der Gedanke immer die jeweilige Betriebsstätte mit den mobilen zu
"belasten", sozusagen loadbalancing in simpelster Form.
muss ist wahrscheinlich übertrieben, aber da die Verbindung über die Zentrale sicher die Performance
beeinträchtigen würde entstand der Gedanke immer die jeweilige Betriebsstätte mit den mobilen zu
"belasten", sozusagen loadbalancing in simpelster Form.
Das würde ich mir an Deiner Stelle nochmal gut überlegen. Über wieviele VPN-Clients reden wir denn? Die Zentrale muss ohnehin ausreichend performant und ausfallsicher angebunden werden, da die einzig sinnvolle VPN-Konfiguration bei dieser Anzahl Außenstellen die Hub-and-Spoke-Konfiguration ist. Ein Full- oder Teil-Mesh ist bei mehr als 4 Lokationen nicht mehr handhabbar! Der Hub muss ja nicht die eigentliche Zentrale, sondern kann durchaus eine Außenstelle sein, wenn die leitungsmäßigen Voraussetzungen dort besser sind, als an der eigentlichen Zentrale. Unser Hub/VPN-Konzentrator besteht z.B. aktuell (noch) aus 2x USG300 als Active/Passive-Cluster mit per VRRP redundant angebundenem öffentlichen IP-Netz (1x per LWL mit 48MBit/s symmetrisch und 1x Backup per Kupfer mit 2MBit/s symmetrisch). Das kostet natürlich. Man kann mit den Zywalls aber auch ein VPN-Failover über eine Multi-WAN-Konfiguration hinweg fahren. Das ist hinsichtlich der Providerkosten wesentlich billiger. Wichtig am Hub ist ein hoher Upload!
Zitat von @mc-doubleyou:
Wenn ich nun wie von euch erwähnt das mobile VPN Netz vom eigentlichen abtrenne, was zumindest bei ZyXEL zwingend nötig
ist, dann besteht eben das Problem bei der Fernwartung. Ich könnte nun für diese Fälle TeamViewer als Alternative
nehmen, aber eigentlich wäre das nicht die angestrebte Lösung welche im Konzept definiert ist.
Wenn ich nun wie von euch erwähnt das mobile VPN Netz vom eigentlichen abtrenne, was zumindest bei ZyXEL zwingend nötig
ist, dann besteht eben das Problem bei der Fernwartung. Ich könnte nun für diese Fälle TeamViewer als Alternative
nehmen, aber eigentlich wäre das nicht die angestrebte Lösung welche im Konzept definiert ist.
Nein das Abtrennen ist kein Problem, sondern nur eine Frage der richtigen Konfiguration.
Es gibt grundsätzlich 2 Arten, wie ein IPSec-Gateway hinsichtlich des VPN-Routings "tickt":
1) Das Gateway entnimmt die Routing-Informationen ausschließlich der Phase2-Policy.
2) Das Gateway kann den Traffic _zumindest auch_ auf andere Weise in den Tunnel leiten (z.B. per Policy-Route oder über ein Routingprotokoll wie OSPF erlernt).
Variante 1 heisst "policy-based". Die alten ZyNOS-Gateways wie die Zywall35, die 2Plus usw. arbeiten ausschließlich so!
Variante 2 heisst "route-based". Die Linux-basierten ZyXEL-Firewalls wie etwa die USG-Serie oder die neuen Zywall 110/310/1100 können sowohl policy-based als auch route-based arbeiten und sind daher hinsichtlich des Adressierungskonzeptes wesentlich flexibler!
Solange Du noch ZyNOS-Geräte verwendest, muss man das also berücksichtigen.
Policy-based bedeutet normalerweise weniger Konfigurationsaufwand, sofern das IP-Adressierungsschema routingorientiert aufgebaut ist - also man die Standortabhängigkeit vor die inhaltliche Klassifizierung des Netzes stellt.
Beispiel zu Verdeutlichung:
Zentrale = 10.120.0.0/16 bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/17 oder noch kleiner; z.B. 256x /24)
Betriebsstätte 1 = 10.121.0.0/16 bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/17 oder noch kleiner; z.B. 256x /24)
Betriebsstätte x = 10.12x.0.0/16 bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/17 oder noch kleiner; z.B. 256x /24)
In diesem Beispiel unterscheide ich den Standort zur Verdeutlichung im 2. Oktett. Das ist für einen Menschen sehr einfach zu lesen, hat aber einen gravierenden Nachteil: Dadurch verbrät man ohne Not einen sehr großen Teil des möglichen Adressraumes, wodurch die Wahrscheinlichkeit steigt, dass es irgendwann zu Überlappungen/Konflikten mit dem Adressschema von Partnern etc. kommt!
Ein versierter Netzwerker arbeitet daher sparsamer und verschiebt den "Strich" zwischen die Oktettgrenzen:
Zentrale = 10.20.0.0/21 (10.20.0.0-10.20.7.255) bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/22 oder noch kleiner; z.B. 8x /24)
Betriebsstätte 1 = 10.20.8.0/21 (10.20.8.0-10.20.15.255) bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/22 oder noch kleiner; z.B. 8x /24)
Betriebsstätte x = 10.20.x.0/21 bestehend aus einer entsprechend den Anforderungen gewählten Anzahl von lokalen Teilnetzen (/22 oder noch kleiner; z.B. 8x /24)
Dies ist zwar etwas unübersichtlicher, aber sparsamer hinsichtlich des Adressraumes. Unter voller Nutzung des Blocks 10.20.0.0/16 könntest Du so z.B. bis zu 32 Lokationen mit je 8x lokalen /24-Teilnetzen versorgen. Ideal für Dein Szenario!
Vorteil dieses routingoptimierten Adressierungsschemas ist, dass Du auch bei ausschließlich policy-based arbeitenden IPSec-Gateways (ZW35 usw) lediglich einen IPSec-Tunnel pro Aussenstelle benötigst.
Nachteilig ist dieses Adressierungsschema allerdings dann, wenn man in einem zentralen Firewallregelwerk (z.B. am Hub/VPN-Konzentrator) vom Securitylevel her gleichartige Netze aller Außenstellen mit möglichst wenig Aufwand einheitlich beregeln will. Nehmen wir z.B. an, in jeder Außenstelle gibt es jeweils ein Gäste-WLAN, welches durch den Tunnel in der Zentrale nur auf eine ganz bestimmte IP-Adresse zugreifen darf und die Gäste-WLANs sind jeweils das letze lokale /24-Teilnetz. Also z.B. 10.20.15.0/24, 10.20.23.0/24, 10.20.31.0/24 usw.). Wie willst Du diese Netze möglichst einfach zu einem Adressobjekt zusammenfassen? Es gibt Firewalls, die können mit Verneinungen, mit Wildcards oder invertierten Masken arbeiten. Dann geht das. Die Zywalls und viele andere können es hingegen nicht!
Folglich kann es sinnvoll sein, das Pferd von der anderen Seite her aufzuzäumen und die inhaltliche Unterscheidung des Netzes vor die Standortunterscheidung zu ziehen.
Beispiel analog Deiner bisherigen Planungen:
LAN Zentrale = 10.20.20.0/24
VPN-Clients Zentrale =10.21.20/24
Gäste-WLAN Zentrale = 10.22.20.0/24
LAN Betriebsstätte x = 10.20.2x.0/24
VPN-Clients Betriebsstätte x =10.21.2x/24
Gäste-WLAN Betriebsstätte x = 10.22.2x.0/24
Jetzt könntest Du im zentralen Firewallregelwerk alle Gäste-WLANs durch das Netz 10.22.0.0/16 beschreiben!
Dieses Adressschema hat zwar routingtechnische Nachteile, diese sind beim Einsatz eines route-based arbeitenden IPSec-Gateways wie einer Zywall USG aber problemlos lösbar.
Mein Vorschlag:
1) Du nutzt eine Hub-and-Spoke-VPN-Konfiguration
2) Die Internetanbindung am Hub/VPN-Konzentrator wird so gut es geht und finanziell vertretbar hinsichtlich Upload(!) und Ausfallsicherheit aufgebohrt. Dies kann z.B. ein vergleichsweise billiger Business-Kabel-Anschluß und ein DSL-Anschluß als Backup sein (MultiWAN-Konfig mit VPN-Failover).
3) Du lässt Dein Adressierungsschema wie es ist.
4) Du erweiterst das Adressierungsschema mit Blick auf das zentrale Firewall-Regelwerk. Hierfür siehst Du im 2. Oktett einfach pauschal 10 unterschiedliche Netze/Securtitylevel vor. Also die Range 10.20.xx.yy bis 10.29.xx.yy. (xx=Lokation; yy=Hosts).
5) Die L2TP-Client-Einwahl erfolgt zunächst nur in der Zentrale. Von dort aus kann auf die Aussenstellen zugegriffen werden. Wenn sich dies aufgrund der verfügbaren Bandbreite oder aus anderen Gründen als unpraktikabel erweist, kannst Du später immer noch eine Direkteinwahl an den Außenstellen implementieren. Hierfür müssen ohnehin die noch vorhandenen ZyNOS-Gateways in den Betriebsstätten ausgetauscht werden. Wenn Du hierfür USGs nimmst, gibt es hierbei auch keine Probleme hinschtlich des VPN-Routings. Im Zweifel muss halt der Traffic "mit Gewalt" per Policyroute in den Tunnel geschoben werden.
Konfigurationsanweisung hierfür:
- L2TP-IP-Pool jeweils = 10.21.xx.yy (xx = Lokation)
- IPSec-Phase2 Policy in der jeweiligen Außenstelle zur Zentrale:
lokales Netz = 10.20.xx.0/24
Remotenetz = Range 10.20.0.0 bis 10.29.255.255 --> Dadurch werden alle Netze der Zentrale und der Außenstellen erfasst!
Achtung: Wenn Du diese Einstellung auf einem ZyNOS-Gateways vornimmst, musst Du darauf achten, dass Du die Einstellung "Local and Remote IP Address Conflict Resolution" auf "The Local Network" stellst, sonst ziehst Du Dir selbst die Beine weg! Siehe http://www.zyxeltech.de/previews/zyw35w403wz0/IPSec_Cfg.html
- IPSec-Phase2 Policy von der Zentrale zur jeweiligen Außenstelle: spiegelverkehrt wie oben
- Wenn jetzt der Fall eintritt, dass Du an einer Betriebsstätte weitere Netze einrichten willst und diese durch den Tunnel adressierbar sein sollen, dann musst Du entweder
a) zwischen Betriebsstätte und Zentrale einen zusätzlichen Tunnel einrichten (zwingend bei ZyNOS-Gateways, da ausschließlich policy-based arbeitend!)
oder
b) den Traffic beiderseits per Policy-Route "mit Gewalt" in den bereits vorhandenen Tunnel schieben (erfordert bei Zyxel eine Linux-basierende Firewall)
Variante b) wird interessant (weil administrativ dann einfacher), wenn es in den Betriebsstätten mehr als 2 lokale Netze gibt.
Gruß
Steffen
1
