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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 218382
Url: https://administrator.de/contentid/218382
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
21 Kommentare
Neuester Kommentar
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..?!
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 @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!
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 @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
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!
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
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