14.11.2017, aktualisiert um 08:32:04 Uhr

5950

IPSec VPN zwischen pfSense und Zyxel USG

Guten Tag

Grundsätzlich sollten die pfSense und die Zyxel USG für den Verbindungsaufbau eines IPSec VPN Tunnels kompatibel sein. Trotz unzähligen Versuchen mit vielen verschiedenen Parametern (Main Mode / Aggressive Mode, usw.), klappt Verbindung nicht. Es war angedacht den Tunnel über PSK aufzubauen. Auch bei der Recherche in den einschlägigen Foren konnte nicht die Lösung gefunden werden.

Konfiguration:
pfSense mit statischer IP - USG20W über LTE mit dynamischer IP

Hardware:
pfSense: Netgate SG-8860 1U - Firmware 2.3.4-RELEASE-p1
Zyxel: USG20W - Firmware 3.30(BDR.9)C0

Hat jemand einen funktionierenden Verbindungsaufbau zwischen den beiden Geräten?

Vielen Dank für die Mithilfe
tr00p3r

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 354757

Url: https://administrator.de/forum/ipsec-vpn-zwischen-pfsense-und-zyxel-usg-354757.html

Ausgedruckt am: 10.04.2025 um 17:04 Uhr

24 Kommentare

Neuester Kommentar

Grundsätzlich sollten die pfSense und die Zyxel USG für den Verbindungsaufbau eines IPSec VPN Tunnels kompatibel sein.

Nicht nur "sollte" sondern das ist sie auch wie das hiesige Forums Tutorial zu dem Thema ja klar zeigt:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Das Tutorial hast du gelesen ??
Main Mode solltest du niemals verwenden. Wenn überhaupt dann nur Agressive Mode wie immer zw. herstellerfremden Geräten.

Du hast es ja leider NICHT geschafft hier einmal einen Log Auszug zu posten was auf beiden Seiten passiert beim Tunnelaufbau

Ganz zu schweigen vom aktuellen Design, ob z.B. VOR der pfSense noch ein kaskadierter NAT Router steht (Thema Port Forwarding) oder ob die mit einem NUR Modem direkt im Internet ist usw. usw.
Anhand der Logs von pfSense und Zyxel kann man meist sofort sehen wo es kneift.

Es liegt auf der Hand das du einen Konfig Fehler gemacht hast aber wegen der fehlenden Troubleshooting Infos und der recht oberflächlichen Beschreibung ist eine zielführende Hilfe nicht gerade sehr einfach. Leuchtet dir vermutlich auch ein, oder ?
Fazit: Ein paar Konfig Screenshots und insbesondere die Logs der beiden Systeme beim Verbindungsaufbau würden uns massiv helfen das Szenario zum Fliegen zu bringen für dich !!

Hallo,

USG20W über LTE mit dynamischer IP

Und das ist auch ein Business LTE Vertrag, denn ansonsten wird es dort mit VPN nicht so gut funktionieren!
Dort sind dann meist ein Provider NAT mit privaten IP Adressen davor und die verhindern den VPN Aufbau.

Hat jemand einen funktionierenden Verbindungsaufbau zwischen den beiden Geräten?

An den Geräten sollte es nicht liegen! Schau lieber einmal nach dem LTE Vertrag!

Gruß
Dobby

Zitat von @aqui:
Main Mode solltest du niemals verwenden. Wenn überhaupt dann nur Agressive Mode wie immer zw. herstellerfremden Geräten.

Gewagte Aussage.
Zum Einen sehe ich den Kausalzusammenhang mit dem Umstand, dass die VPN-Endpunkte von unterschiedlichen Herstellern sind, in meiner langjähjrigen Berufspraxis nicht bestätigt und zum Anderen sollte man nicht unerwähnt lassen, dass der Agressive Mode in Verbindung mit einer PSK-Authentifizierung leicht zu einer bösen Schwachstelle werden kann, wenn der PSK nicht hinreichend komplex und zufällig ist.

Gruß
sk

USG20W über LTE mit dynamischer IP

Ich frage mich immer wieder, woher das kommt. Der dynamische LTE-Client ist der Client ist der Client ist der Client. Hat so ziemlich jede Firma irgendwo im Einsatz. Heute ist mir die LTE-Karte im Laptop andauernd abgeschmiert, WLAN-Hotspot übers Handy mit Consumer-Vertrag und weiter gings. Den Business-LTE mit öffentlicher IP brauchst du nur beim Server.

Der dynamische LTE-Client ist der Client ist der Client ist der Client.

Bahnhof ? Ägypten ? Was soll und dieser kryptische Satz sagen ??

Bei LTE besteht immer die Gefahr das dort sog. Carrier Grade NAT gemacht wird. Die meisten Mobilfunkprovider haben keine freinen IPv4 Kontingente mehr und adressieren ihre LTE Netze mit RFC 1918 IP Adressen und müssen dann zwangsweise CGN machen. CGN ist dann der Todesstoß für VPN oder zumindest die meisten VPN Verfahren.
Eine simple Binsenweisheit und ob man davon betroffen ist kann man immer an der LTE Port IP Adressierung erkennen:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche

Der dynamische LTE-Client ist der Client ist der Client ist der Client.

Wenn Dir jemand, zum Beispiel Dein mobile Provider, eine 192.168.5.200 vergibt, dann wird diese IP nicht im Internet
geroutet, also kann man damit gar kein VPN aufmachen oder ermöglichen! Und das ist bei allen mobilen IPSs und
Ihren Privatkundeverträgen zur Zeit auf jeden Fall so.

Heute ist mir die LTE-Karte im Laptop andauernd abgeschmiert, WLAN-Hotspot übers Handy mit
Consumer-Vertrag und weiter gings. Den Business-LTE mit öffentlicher IP brauchst du nur beim Server.

Aber nicht via VPN!

Gruß
Dobby

Keinerlei Feedback vom TO

Hat vermutlich das Interesse an einer zielführenden Hilfe verloren...?!

Hallo aqui

Nein dem ist nicht so! Leider hatte ich in der Zwischenzeit keine Möglichkeit die Logs und Screenshots nachzuliefern. Werde dies bis morgen Abend noch nachreichen.

Bezüglich dem LTE Vertag kann gesagt werden, dass es sich hierbei um einen Business Vertrag handelt. Es ist zudem die Option CAA Corporate Access aktiv und kann so z.B. über DynDNS aufgerufen werden.

Gruss
Tr00p3r

Bezüglich dem LTE Vertag kann gesagt werden, dass es sich hierbei um einen Business Vertrag handelt.
Es ist zudem die Option CAA Corporate Access aktiv und kann so z.B. über DynDNS aufgerufen werden.

Cool! Dann sollte es doch irgend wie möglich sein ein vernünftiges VPN aufzubauen.

Gruß
Dobby

Werde dies bis morgen Abend noch nachreichen.

Perfekt...wir sind gespannt !

LTE Vertag kann gesagt werden, dass es sich hierbei um einen Business Vertrag handelt

Sinnvoller wäre am LTE Interface mal nachzusehen WAS dort für eine IP ausgehandelt wurde.
It es eine öffentliche, ist alles OK. Wenn's eine RFC 1918 IP ist dann ists aus mit dem VPN. In sofern wäre DIESE Info sinnvoller und sicherer für uns.
Bedenke immer: Vertrauen ist gut, Kontrolle ist besser

Zitat von @108012:

Der dynamische LTE-Client ist der Client ist der Client ist der Client.

WENN der LTE-nutzende Endpunkt der Server ist gebe ich dir Recht

Heute ist mir die LTE-Karte im Laptop andauernd abgeschmiert, WLAN-Hotspot übers Handy mit
Consumer-Vertrag und weiter gings. Den Business-LTE mit öffentlicher IP brauchst du nur beim Server.

Aber nicht via VPN!

Gruß
Dobby

Und aber sicher doch via VPN. Mit WLAN vom Privathandy. Ganz sicher mit Consumer-Vertrag. Und sogar ganz sicher mit einer 10er IP ;) selbst mein Arbeitshandy hat zwar einen Business-Vertrag, aber trotzdem CGN aktiv. Zweitkarte davon ist im Laptop. Damit arbeite ich täglich ohne Probleme. Wie ich sagte: nur beim Server von Relevanz. Zumindest bei T-Mobile. Ob das auf Yodafone, E- und Luft sowie die vielen MVNO auch zutrifft kann ich mangels Karte derer nicht sagen.

WENN der LTE-nutzende Endpunkt der Server ist gebe ich dir Recht

Nein, das gilt auch andersrum. Bei allen VPN Protokollen die aus mehreren Komponenten bestehen und wo der Server dann eine Session zum Client aufbaut.
Bei SSL basierten VPN Protokollen ist das richtig da funktioniert es nur dann nicht wenn der Server hinter einem CGN steht.
Bei L2TP, PPTP, IPsec usw. sieht es aber anderes aus, denn dort sind immer mindestens 2 Protokollkomponenten im Spiel. Bei L2TP und IPsec sogar 3.

selbst mein Arbeitshandy hat zwar einen Business-Vertrag, aber trotzdem CGN aktiv

Dann hast du den falschen Vertrag ! Vermutlich bei einem der gruseligen Billigheimer wie O2 oder sowas...
Du brauchst de facto einen öffentliche IP am Mobilfunk Interface. Mit RFC 1918 IP Adressen und CGN klappt es de facto NICHT ! Jedenfalls nicht wenn man Protokolle wie IPsec, L2TP oder PPTP nutzt. Damit ist das nicht möglich.
Mit SSL basierten VPNs hast du einen Chance. Also auf Open VPN umstellen, dann klappt es. Aber dann auch nur in eine Richtung. Niemals beidseitig.
Mit einer Zweitkarte sind Datenverbindungen vermutlich auch nicht oder nur eingeschränkt möglich. Da zählt das Kleingedruckte beim Provider.

Aqui, ich schätze dein Wissen wirklich sehr. Auch die Ausarbeitung deiner Tutorials. Aber hier muss ich dir halt einfach widersprechen.
Ich arbeite Tagein, Tagaus über MoFu und VPN. Gruseliger Anbieter ist in dem Fall die Telekom, ohne passenden APN gibts halt nur RFC1918-Adressen, stört aber nicht. Zweitkarte übrigens MultiSIM, damit vollwertige Zweitkarte mit voller Datennutzung wie auf der Hauptkarte. Beide klingeln, beide gleichzeitig online, alles kein Problem.
Da hilft vielleicht ein Screenshot vom WWAN + VPN. VPN ist IPSec.

Funktioniert übrigens genauso gut vom Privat-Laptop zur Privat-pfsense via IPsec mit der privaten MultiSIM im Laptop.

Bringt dem TO aber nichts, ich tippe bei ihm auf eine unstimmige Phase1/2, bei der nur ein kleines Parameterchen nicht korrekt sitzt. Was das angeht sind mir leider im Laufe meiner Zeit im Cloudsupport die unterschiedlichsten Router unter die Finger gekommen, die gewisse Encryption-Typen verwirrend anders benennen, PFS welches nicht korrekt möchte oder auch nicht kompatible Proposals (Huawei AES256/SHA2-512 mit Sophos UTM AES256/SHA2-512 kommt einfach beim besten Willen nicht hoch..........)

Dem will ich nicht widersprechen das bei vielen Massenfertigern der Teufel im Detail liegt. Was aber technisch nicht geht ist IPsec über CGN mit RFC1918.
Die Proposals sollten auch bei einfachen System anpassbar sein das es da Deckung gibt. Die allseits bekannte Allerweltskombi 3DES und SHA1 kann eigentlich wirklich jeder ohne jetzt mal auf die Sicherheit zu sehen. Wenn das schon scheitert dann ist das eben der geringe Prozentsatz der inkompatibel ist durch Firmwarefehler oder fehlende Optionen das zu customizen in solch einfachen Produkten. Die Protokollparameter von IPsec sind ja hinreichend ausdefiniert. Der Fehler liegt dann an den Herstellern und deren Umsetzung.
Die Tatsache der APNs ist bei allen Mobilfunk Providern so, da hast du zweifelsohne Recht. Allerdings hat man bei der Telekom ja wenigstens noch die Wahloption. Bei anderen gar nicht. Von der Infrastruktur mal gar nicht zu reden.

Sooo endlich habe ich Zeit gefunden um die Logs nachzureichen. Leider ist dies eines von vielen "Baustellen" in der Firma

Vielleicht noch einige Infos zur IST-Situation. Momentan haben wir ca. 15 Aussenstellen, welche mittels Zyxel USG20W auf einen zentralen Zyxel USG100-Plus über IPSec VPN verbinden. Teilweise sind die USG20W mittels LTE-Dongle (Business Abo mit CAA, d.h. dynamische von aussen erreichbare IP) am I-Net angebunden.
Die Verbindungsaufbauten funktionieren seit Jahren einwandfrei. Da der USG100-Plus mit der Last langsam aber sicher am Anschlag läuft und zudem kein OpenVPN unterstützt, wurde eine performante Hardware mit pfSense beschafft. Von der Konfiguration bin ich soweit, dass der VPN serverseitig beim pfSense aufgebaut ist, beim Zyxel hingegen beim Aufgau (NOTIFY:INFALID_ID_INFORMATION) abbricht. Leider besteht beim USG bei der ID nur die Möglichkeite eine IP, Mail oder DNS anzugeben.
Beim pfSense kommt die Fehlermeldung "no matching CHILD_SA config found"

Konfiguration pfSense
Phase 1

Phase 2

Log pfSense

Nov 21 16:47:17 	charon: 14[NET] <5> received packet: from 138.188.xx.xxx[500] to 83.144.xxx.xx[500] (404 bytes)
Nov 21 16:47:17 	charon: 14[ENC] <5> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V ]
Nov 21 16:47:17 	charon: 14[ENC] <5> received unknown vendor ID: f7:58:f2:26:68:75:0f:03:b0:8d:f6:eb:e1:d0:04:03
Nov 21 16:47:17 	charon: 14[ENC] <5> received unknown vendor ID: af:ca:d7:13:68:a1:f1:c9:6b:86:96:fc:77:57
Nov 21 16:47:17 	charon: 14[IKE] <5> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Nov 21 16:47:17 	charon: 14[IKE] <5> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Nov 21 16:47:17 	charon: 14[IKE] <5> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Nov 21 16:47:17 	charon: 14[IKE] <5> received NAT-T (RFC 3947) vendor ID
Nov 21 16:47:17 	charon: 14[IKE] <5> received DPD vendor ID
Nov 21 16:47:17 	charon: 14[ENC] <5> received unknown vendor ID: af:ca:d7:13:68:a1:f1:c9:6b:86:96:fc:77:57
Nov 21 16:47:17 	charon: 14[IKE] <5> 138.188.xx.xxx is initiating a Aggressive Mode IKE_SA
Nov 21 16:47:17 	charon: 14[CFG] <5> looking for pre-shared key peer configs matching 83.144.xxx.xx...138.188.xx.xxx[10.10.4.0]
Nov 21 16:47:17 	charon: 14[CFG] <5> selected peer config "con1"  
Nov 21 16:47:17 	charon: 14[ENC] <con1|5> generating AGGRESSIVE response 0 [ SA KE No ID V V V NAT-D NAT-D HASH ]
Nov 21 16:47:17 	charon: 14[NET] <con1|5> sending packet: from 83.144.xxx.xx[500] to 138.188.xx.xxx[500] (388 bytes)
Nov 21 16:47:17 	charon: 14[NET] <con1|5> received packet: from 138.188.xx.xxx[4500] to 83.144.xxx.xx[4500] (108 bytes)
Nov 21 16:47:17 	charon: 14[ENC] <con1|5> parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
Nov 21 16:47:17 	charon: 14[IKE] <con1|5> IKE_SA con1[5] established between 83.144.xxx.xx[83.144.xxx.xx]...138.188.xx.xxx[10.10.4.0]
Nov 21 16:47:17 	charon: 14[IKE] <con1|5> scheduling reauthentication in 2662s
Nov 21 16:47:17 	charon: 14[IKE] <con1|5> maximum IKE_SA lifetime 3202s
Nov 21 16:47:17 	charon: 14[IKE] <con1|5> faking NAT situation to enforce UDP encapsulation
Nov 21 16:47:17 	charon: 11[NET] <con1|5> received packet: from 138.188.xx.xxx[4500] to 83.144.xxx.xx[4500] (236 bytes)
Nov 21 16:47:17 	charon: 11[ENC] <con1|5> parsed QUICK_MODE request 2093321109 [ HASH SA No ID ID ]
Nov 21 16:47:17 	charon: 11[IKE] <con1|5> no matching CHILD_SA config found
Nov 21 16:47:17 	charon: 11[ENC] <con1|5> generating INFORMATIONAL_V1 request 461532534 [ HASH N(INVAL_ID) ]
Nov 21 16:47:17 	charon: 11[NET] <con1|5> sending packet: from 83.144.xxx.xx[4500] to 138.188.xx.xxx[4500] (76 bytes)
Nov 21 16:47:21 	charon: 11[IKE] <con1|4> sending DPD request
Nov 21 16:47:21 	charon: 11[ENC] <con1|4> generating INFORMATIONAL_V1 request 1401779365 [ HASH N(DPD) ]
Nov 21 16:47:21 	charon: 11[NET] <con1|4> sending packet: from 83.144.xxx.xx[4500] to 138.188.xx.xxx[4500] (92 bytes)

Konfiguration USG20W
Phase 1

Phase 2

Log Zyxel USG20W

# Zeit Priorität Kategorie Meldung Quelle Quellenschnittstelle Ziel Zielschnittstelle Protokoll Hinweis 
2017-11-21 16:24:59 info IKE [COOKIE] Invalid cookie, no sa found 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:59 info IKE The cookie pair is : 0x0b1dd61651df079c / 0xd5b4d9f37bc8324a 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:59 info IKE ISAKMP SA [pf_GW] is disconnected 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:59 info IKE The cookie pair is : 0x0b1dd61651df079c / 0xec06147078a77020 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:59 info IKE Recv:[NOTIFY:AUTHENTICATION_FAILED] 83.144.xxx.xx:500   138.188.xx.xxx:500     IKE_LOG 
2017-11-21 16:24:59 info IKE The cookie pair is : 0xec06147078a77020 / 0x0b1dd61651df079c 83.144.xxx.xx:500   138.188.xx.xxx:500     IKE_LOG 
2017-11-21 16:24:58 info IKE Send:[SA][KE][NONCE][ID][VID][VID][VID][VID][VID][VID][VID][VID][VID] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:58 info IKE Send Aggressive Mode request to [83.144.xxx.xx] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:58 info IKE Tunnel [pf] Sending IKE request 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:58 info IKE The cookie pair is : 0x0b1dd61651df079c / 0x0000000000000000 [count=3] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:48 info IKE The cookie pair is : 0x3d7d6f0dcff94aea / 0x593c355cbd87efe2 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:48 info IKE The cookie pair is : 0x593c355cbd87efe2 / 0x3d7d6f0dcff94aea 83.144.xxx.xx:500   138.188.xx.xxx:500     IKE_LOG 
2017-11-21 16:24:48 info IKE The cookie pair is : 0x3d7d6f0dcff94aea / 0x0000000000000000 [count=3] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE ISAKMP SA [pf_GW] is disconnected [count=2] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE The cookie pair is : 0xee975f45e7b55b78 / 0xefd26180a2b3ccfd 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE Recv:[NOTIFY:AUTHENTICATION_FAILED] [count=2] 83.144.xxx.xx:500   138.188.xx.xxx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE The cookie pair is : 0xefd26180a2b3ccfd / 0xee975f45e7b55b78 83.144.xxx.xx:500   138.188.xx.xxx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE Send:[SA][KE][NONCE][ID][VID][VID][VID][VID][VID][VID][VID][VID][VID] [count=2] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE Send Aggressive Mode request to [83.144.xxx.xx] [count=2] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE Tunnel [pf] Sending IKE request [count=2] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 
2017-11-21 16:24:43 info IKE The cookie pair is : 0xee975f45e7b55b78 / 0x0000000000000000 [count=3] 138.188.xx.xxx:500   83.144.xxx.xx:500     IKE_LOG 

Hoffentlich könnt ihr mit dieser Info etwas anfangen

Besten Dank
tr00p3r

Leider besteht beim USG bei der ID nur die Möglichkeite eine IP, Mail oder DNS anzugeben.

Dann solltest du Email wählen wenn du mit dynamsichen IPs arbeitest oder arbeiten musst. Aussnahme wäre dann mit DynDNS was bei 15 remoten Standorten aber recht umständlich ist. Besser dann beidseitig einen festen String definieren (was die Email ja ist).
Zur Phase 1:

Die USGs machen auch alle IKEv1 ??
Supporten die USGs DPD ? Sonst erstmal auslassen und später aktivieren falls der Tunnel hochkommt.
Besser in der Phase 2 mal 3DES mit anhaken in den Proposals und zusätzlich SHA256. bei vielen ist das Default.
Stelle das "Auto" bei AES besser fest auf 256Bit ein !
Die Phase 2 der USG hat einen gravierenden Konfig Fehler. Du machst ja eine Site zu Site Kopplung also Netzwerk zu Netzwerk. Eingestellt hast du aber "Remote Zugriff" also einen Client Zugriff mit einem remoten Client. Das geht dann natürlich logischerweise in die Hose.

Laut Log kommt der Aufbau schon recht weit. (IKE_SA con1[5] established) Scheitert dann aber auf dem letzten Meter weil vermutlich es ein Problem mit der Profil Zuweisung gibt. Vermutlich resultiert das aus dem falsch konfiguriertem Mode in der USG.
Hast du die USG auf die aktuellste 4.25C0 Firmware geflasht ! Wichtig weil da mehere IPsec Bugs gefixt sind was das SA Establishment anbetrifft. (Siehe Release Notes dazu !)

Zitat von @aqui:
Hast du die USG auf die aktuellste 4.25C0 Firmware geflasht ! Wichtig weil da mehere IPsec Bugs gefixt sind was das SA Establishment anbetrifft. (Siehe Release Notes dazu !)

Die USG20W ist seit längerem aus dem offiziellen Support raus. ZLD 3.30(BDR.9)C0 ist das letzte offizielle Release. Darüber hinaus gibt es nur noch Hotfixes, die man mit einem konkreten Problem beim Support durchaus noch kostenfrei erhalten kann. Am wirklichen Ende des Supportzeitraumes gibt es dann gewöhnlicher Weise zum Abschied noch einen frei verfügbaren "Sammelpatch" als letzte "Stable". Aber der 4er Entwicklungszweig der Firmware wird für diese Geräte definitiv nicht mehr adaptiert.

Gruß
sk

Das Zyxel Firmware Portal sagt da aber was ganz anderes in puncto 4er Firmware:

Release Notes:

Anderes Produkt, aqui. Das ist das Nachfolgemodell. Was auch immer die Taiwanesen da wieder geraucht haben, als es um die Namensfindung ging. USG21 oder USG30 wäre wohl zu phantasielos gewesen...

Für welches Gerät eine Firmware ist, erkennt man am einkodierten Produktcode innerhalb der Klammern.

BDQ = die alte USG20 (ohne WLAN)
BDR = die alte USG20W (mit WLAN)
ABAQ = die aktuelle USG20-VPN (ohne WLAN)
ABAR = die aktuelle USG20W-VPN (mit WLAN)

Früher - in der guten alten Zeit - waren die Produktcodes mal zweistellig...

Gruß
sk

Die haben echt was geraucht wenn das stimmt. Das ist ja pure Salami Taktik und führt den Benutzer ja massiv aufs Glatteis.
OK, ich bekomme eine USG20 geliehen zum Ende der Woche und mache mal einen Labor Aufbau dazu.
Bin mal gespannt ob das dann eine BDx oder oder ne ABAx ist ???

Appropos wie kommt man denn an die latest BDx Version ?? Das Download Portal zeigt zur USG20 rein nur die 4er ABAx Version. Oder werden Benutzer der alten Hardware dann im Regen stehen gelassen...?

<edit> Habs grade gefunden. Die sind auf dem Zyxel FTP Server

</edit>

Hallo Aqui

Das ist in der Tat so, dass Zyxel ein neues Produkt mit dem Suffix "VPN" (USG20W-VPN) lanciert. Diese neuen Geräte unterstützen die 4er Firmware. Mein alten Geräte, USG20W, haben mit dem BDR.9 den letzten Stand erreicht. Diese Firmware wurde am 06.12.2016 veröffentlicht.

Die Namensgebung der Zyxel Firewalls ist in der Tat sehr speziell

Gruselig...

Ich werde übers Wochenende einen Laboraufbau machen und hier berichten.

Zitat von @aqui:
Ich werde übers Wochenende einen Laboraufbau machen und hier berichten.

Wenn man sich das erste Mal mit diesen Geräten beschäftigt, sollte man insbesondere in Hinblick auf den Paketflow sowie die Routing- und NAT-Priorities folgendes gelesen haben: ftp://ftp.zyxel.com/ZyWALL_USG_20/support_note/
Insbesondere das erste Dokument behandelt grundlegende Designänderungen von ZLD2.1x nach ZLD2.20.

Beachte auch, dass die USG20 das absolut untere Ende einer seit längerem abgelösten Produktgeneration darstellte. Das betrifft nicht nur Hardwaredesign und Performance, sondern vorallem auch das Featureset.

Gruß
sk