UniFi LAN-/WLAN-Infrastruktur mit FRITZ!Box ohne „Doppeltes NAT“

Nachdem die UniFi-Infrastruktur inzwischen seit etwa einem halben Jahr erfolgreich das WLAN bei mir zuhause aufspannt, habe ich mich dazu entschlossen, meine komplette LAN-Infrastruktur hinter das UniFi Security Gateway zu hängen. Da das Security Gateway über kein DSL-Modem verfügt, stand ich vor der Wahl entweder meine FRITZ!Box 7490 als Router zwischen “das Internet” und mein Security Gateway zu hängen oder ein dediziertes DSL-Modem zu verwenden. Beide Varianten haben Vor- und Nachteile. Je nachdem wie weit man bereit ist, sich mit den technischen Herausforderungen auseinanderzusetzen, lassen sich die jeweiligen Nachteile jedoch beseitigen.

tl;dr

Die Nachteile haben in der Regel mit der Network Address Translation (NAT) zu tun. In den meisten Artikeln, die ich im Internet zu dem Thema gefunden habe, wird eine Lösung bevorzugt, bei der das UniFi Security Gateway über ein DSL-Modem oder einen Router, der als DSL-Modem konfiguriert wird, “direkt” mit dem Internet verbunden wird. Vorteil dieses Lösungsansatz ist, dass kein “Doppeltes NAT” – einmal durch den Internet-Router und einmal vom Gateway – durchgeführt wird, sondern es nur einmal vom Security Gateway erledigt wird. Dies ist zum Beispiel dann wichtig, wenn man mit einer Playstation 4, einer anderen Konsole oder einem PC online spielen möchte. Da hier oft direkter Datenaustausch zwischen den Teilnehmer erfolgt oder spezielle Ports freigegeben werden, ist das Spielen mit mehrfacher NAT nur eingeschränkt möglich. Dadurch, dass private IP Adressen, wie sie normalerweise in privaten Netzwerken genutzt werden, nicht im Internet weitergereicht werden, ist NAT am ersten Übergang vom Internet ins eigene LAN notwendig. Die per Default auf dem Security Gateway aktive NAT, lässt sich über die Oberfläche des UniFi Controllers leider nicht deaktivieren. Durch den Einsatz eines DSL-Modems findet NAT nur noch auf dem Security Gateway statt. Zusätzlich wird in einigen Artikeln die höhere Geschwindigkeit von bestimmten DSL-Modems gegenüber der FRITZ !Box aufgeführt. Persönlich hatte ich bisher in noch keinem Fall Probleme damit, dass eine FRITZ!Box aufgrund technischer Unzulänglichkeiten der Engpass bei einer Internetverbindung war. Trotzdem habe ich mich im ersten Versuch dafür entscheiden auf die FRITZ!Box zu verzichten und den DrayTek Vigor130 im (V)DSL-Modem-Modus zum Aufbau der Internetverbindung für mein Security Gateway zu verwenden.

Versuch 1: Security Gateway und Vigor130

Beim Konfigurieren des DrayTek Vigor130 bin ich nach der Anleitung DrayTek Vigor130 als VDSL-Modem einrichten von idomix.de vorgegangen. Er beschreibt ausführlich und gut verständlich die Schritte, die notwendig sind, um den Vigor130 als DSL-Modem für das Security Gateway einzurichten. Ein Teil der Einstellungen ist vom jeweiligen Internetanbieter abhängig. Da ich bei keinem der großen Anbieter bin, konnte ich zum Beispiel zu den VLAN-Einstellungen meines Providers nichts offizielles finden und durfte ausprobieren. Da ich mit fortschreitendem Alter nicht mehr jede Kleinigkeit selbst konfigurieren und ausprobieren möchte, hat mir das weniger gut gefallen…

Was (Sicherheits)updates und Stabilität angeht, habe ich bei AVM ein besseres Gefühl als bei DrayTek. Das ist jedoch nur ein Bauchgefühl, das sich darauf begründet, dass ich mit einer FRITZ!Card meinen ersten Linux-PC zusammengebaut hatte, um über die ISDN Verbindung meiner Eltern mit mehreren Freunden Ultima Online zu spielen. Daher ist die Marke FRITZ! positiv vorbelastet – ein qualifiziertes Auswahlkriterium ist das natürlich nicht.

Versuch 2: UniFi Security Gateway und FRITZ!Box 7490

Bei meinen Test mit dem DrayTek Vigor 130 ist mir wieder bewusst geworden, dass ich meine FRITZ!Box auch als Telefonanlage, Zeitserver, Fax, VPN-Endpoint und Strato-DynDNS-Client verwende. Also hätte ich die Box oder eine entsprechende Alternative zusätzlich zum Vigor130 immer noch hinter oder neben meinem Security Gateway benötigt. Außerdem legt mein Provider im Störfall sehr viel Wert darauf, dass die von ihm vermietete FRITZ!Box mit der richtigen Seriennummer angeschlossen ist. So habe ich mich damit auseinandergesetzt, wie NAT auf dem UniFi Security Gateway deaktiviert werden kann. Überraschender Weise ist es nicht sonderlich kompliziert. Auf dem Dateisystem des UniFi Controller ist hierfür eine Konfigurationsdatei anzulegen, in der FRITZ!Box sind statische Routen zu definieren und nach der manuellen Provisionierung des Security Gateways läuft alles wie erwartet.

config.gateway.json vorbereiten

Der UniFi Controller bietet über eine JSON-Datei die Möglichkeit das Security Gateway über das, was mit der grafischen Oberfläche einstellbar ist, hinaus zu konfigurieren. Hierzu muss die speziell vorbereitete Datei auf dem UniFi Controller unter <unifi_base>/data/sites/site_ID agelegt werden. Bei meinem UniFi Cloud Key habe ich hierfür per SSH im Verzeichnis /srv/unifi/data/sites/default die Datei config.gateway.json mit folgendem Inhalt angelegt:

{
	"service": {
		"nat": {                                       
			"rule": {                   
				"5999": {                        
					"exclude": "''",        
					"outbound-interface": "eth0",
					"type": "masquerade"
				}
			}
		}
	}
}

config.gateway.json Herunterladen

Die genaue Formatierung der Datei ist wichtig, daher hier als Download.

Die Konfigurationsdatei setzt vor die bereits vorhandenen NAT-Regeln eine zusätzliche Regel, die NAT auf dem WAN-Port (eth0) des Security Gateways deaktiviert.

Eine detaillierte englische Beschreibung wie mit config.gateway.json umzugehen ist und welche weiteren Möglichkeiten die Datei bietet, gibt es hier: https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json.
Die von mir verwendete JSON-Datei habe ich aus dieser Diskussion entnommen: https://community.ubnt.com/t5/UniFi-Routing-Switching/Guide-to-disabling-NAT-on-USG/td-p/2012460.

Nachdem die Datei angepasst wurde, muss die Provisionierung des
Security Gateways im UniFi Controller manuell gestartet werden.

Statische Routen in der FRITZ!Box konfigurieren

Hierzu gibt es eine gute deutsche Beschreibung auf der Seite des Herstellers: Statische IP-Route in FRITZ!Box 7490 einrichten (AVM). Für jedes Subnet, das von der FRITZ!Box aus gesehen “hinter” dem UniFi Security Gateway liegt, muss eine eigene statische Route definiert werden.

Update 11.01.2020: Viele Rückfragen und Kommentare beziehen sich auf Probleme mit den statischen Routen. Wenn, wie in meinem Beispiel:

die Fritz!Box die interne IP-Adresse 192.168.0.1/24 hat und
das USG die 192.168.0.250/24 (statisch oder per DHCP “fest”).

Muss, um auf das Netz 192.168.1.0/24 “hinter” dem UniFi Security Gateway zugreifen zu können, die statische Route wie folgt in der Fritz!Box konfiguriert werden:

Netzwerk: 192.168.1.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.0.250

192.168.0.0/24 meint: Das Subnetz 192.168.0.0 mit der Subnetzmaske 255.255.255.0 (24 Bit), der Broadcast Adresse 192.168.0.255 und 254 Adressen für Endgeräte von 192.168.0.1 bis 192.168.0.254.

Als Wert für den Parameter “Netzwerk” in der statischen Route wird oft versehentlich nicht die Netzadresse, sondern eine Endgeräte IP-Adresse eingetragen. Bei Problemen lohnt es sich daher hier doppelt zu prüfen. Im Idealfall durch das Erstellen einer Dokumentation mit der die Konfiguration abgeglichen werden kann. Ein sehr schönen Beispiel dafür hat der Leser Thomas zur Verfügung gestellt (siehe mein Kommentar vom 05. Januar 2020, 22:07 Uhr).

Aktivieren der Änderungen im UniFi Security Gateway

Nachdem somit alles vorbereitet ist, können die Änderungen auf das Security Gateway übertragen werden. Hierzu ist in der Weboberfläche des UniFi Controllers ein manuelles Provisionieren für das Security Gateway auszulösen. Das dauert eine Weile und ist mit einem Neustart des Security Gateways verbunden. Sobald das Security Gateway wieder online und in der Weboberfläche des UniFi Controllers integriert ist, ist es geschafft. Das Security Gateway führt keine NAT mehr durch. Der Test mit der PS4 zeigt an, dass die Verbindung zum Internet über ein “Typ-2 NAT” erfolgt. Typ-2 bedeutet für die Playstation 4, dass nur an einer einzigen Stelle zwischen dem Playstation Network und der Konsole NAT durchgeführt wird (von der FRITZ!Box beim Übergang von einem öffentlichen IP-Netz zu meinem privaten).

Zugriff vom FRITZ!Box Subnet durch das Security Gateway in die anderen Subnets freigeben

Die Kommunikation von den durch das Security Gateway geschützten Netzen über die FRITZ!Box ins Internet und auch der direkte Zugriff auf die FRITZ!Box funktioniert problemlos. Jeder Verkehr, der nicht von einem Netz hinter dem Security Gateway initiert wird, wird von der Firewall des Security Gateways blockiert. Da ich im Subnet der FRITZ!Box (192.168.0.0) keine Endgeräte habe, ist dies auf den ersten Blick kein Problem. Natürlich gibt es immer einen Anwendungsfall, der die Ausnahme bildet. In meinem Fall ist es die VPN-Verbindung, die ich nutze, wenn ich unterwegs bin. Die Verbindung terminiert auf der FRITZ!Box und bekommt die interne IP-Adresse 192.168.0.201. Wenn ich mich per VPN einwähle, möchte ich auf mein komplettes LAN zugreifen, als ob ich zuhause wäre. Dafür habe ich im UniFi Controller unter “Einstellungen->Routing&Firewall->Firewall->IPv4 Regeln->WAN-Eingehend” eine neue Regel definiert:

Name: VPN Zugang über fritz.box
Aktiviert: EIN
Positionierung: vor den vordefinierten Regeln
Aktion: Akzeptieren
IPv4-Protokoll: Alle
Quell-Typ: IP-Adresse (im Beispiel 192.168.0.201, IP ist auf den Wert, den die FRITZ!Box für den jeweiligen VPN-Benutzer anzeigt anzupassen)
Ziel-Typ: Netzwerk (im Beispiel das im Gateway definierte “normale” LAN , in der Praxis könnte eine weniger großzügige Freigabe besser sein)

So klappt’s auch wieder mit dem Nachhausetelefonieren.

Persönliches Fazit

Die knapp 100 EUR für den Vigor130 waren im Nachhinein betrachtet für mich eine Fehlinvestition. Die Kombination FRITZ!Box 7490 und UniFi Security Gateway läuft mit wenig Aufwand ohne “Doppeltes NAT” zusammen und die FRITZ!Box bietet mit ihren vielen Features für mich einen deutlichen Mehrwert. Das meiste Kopfzerbrechen hatte mir der SSH-Zugriff auf den UniFi Controller bereitet, der bei mir auf einem UniFi Cloud Key läuft. Hier wird weder der UniFi-Controller-User noch der SSH-Account verwendet, der den direkte Zugriff auf die UniFi WLAN-ACs und LAN-Switche erlaubt. Um das Passwort dieses Benutzers (ubnt) zurück zu setzen, musste ich:

Ein aktuelles Backup meines UniFi Controllers erzeugen,
meinen UniFi Cloud Key auf den Werkszustand zurück setzen,
den Cloud Key neu konfigurieren,
das Passwort für den Benutzer ubnt setzen & merken und
das Anfangs erstellte Backup wieder einspielen.

Zumindest konnte ich so testen, was im Desaster Recovery Fall zu tun wäre – eigentlich gar nicht so schlimm, ich muss zukünftig nur noch zusehen, dass die automatischen Backups nicht mehr ausschließlich auf dem Cloud Key lagern.

too long; didn’t read

Das UniFi Security Gateway lässt sich problemlos ohne zusätzliche Hardware und ohne NAT-Funktion in ein bestehendes Netzwerk integrieren. Hierfür wird (Details siehe oben):

die Datei config.gateway.json vorbereitet,
config.gateway.json im Dateisystem des UniFi Controllers abgelegt,
die statische(n) Route(n) vom dem Security Gateway vorgelagerten Router/Gateway auf die durch das Security Gateway geschützten Netze eingerichtet,
das Security Gateway provisioniert und
optional die Firewall des Security Gateway so eingestellt, dass (spezielle) Anfragen aus dem vorgelagerten Netz in den geschützten Bereich zugelassen werden.

UPDATE 31.01.2021: Auch nach über zwei Jahren bekomme ich per Mail und über den Blog noch regelmäßig Anfragen zu diesem Beitrag. In letzter Zeit bin ich leider nicht mehr dazu gekommen, die Anfragen zeitnah zu bearbeiten. Ich werde die Anfragen weiterhin beantworten, Priorität haben jedoch meine Familie und meine “bezahlte Arbeit”. Seid daher bitte nicht all zu enttäuscht, wenn die Antwort länger dauert. Wenn es dringende Probleme sind, bin ich auch per Mail oder Telefon erreichbar – das würde dann aber nicht mehr unter die Kategorie “Hobby” sondern “bezahlte Arbeit” fallen. Da ich immer wieder danach gefragt werde, hier die relevanten Produkte zu dem Artikel als Amazon-Affiliate-Links:

364 Gedanken zu „UniFi LAN-/WLAN-Infrastruktur mit FRITZ!Box ohne „Doppeltes NAT““

Marco sagt:

7. April 2019 um 14:25 Uhr

Vielen Dank, für den ausführlichen Beitrag. Genau das, was ich gesucht habe und seitdem ich es bei mir eingerichtet habe, läuft mein Netzwerk wunderbar.
Gruß Marco

Antworten
1. Markus sagt:
  
  14. Februar 2020 um 3:53 Uhr
  
  Hallo Marko
  Wie hast du das geschafft, ich kriege das nicht gebacken.
  Kanst du mir helfen
  Grüß Markus
  
  Antworten
Michael Bernius sagt:

15. April 2019 um 14:32 Uhr

Herzlichen Dank… super tolle Anleitung!

Kurze Rückfrage:
Wie verhält es sich mit Portfreigaben?
z.B. Benötigt die Diskstation die Ports 5000 und 5001. Diese waren bisher in der Fritzbox geforwarded… reicht das aus und funktioniert es eine Subnetz-IP aus dem USG-LAN in der Fritzbox einzutragen?

Danke.

VG
Michael

Antworten
1. Martin Ziegler sagt:
  
  17. April 2019 um 8:16 Uhr
  
  Hallo Michael,
  um eine Anfrage vom Internet auf ein internes Gerät einzurichten, reicht es in der Fritzbox das Portforwarding zu konfigurieren. Mögliche Probleme: Die Route in der FritzBox ins das Subnet hinter dem USG ist nicht richtig gesetzt; die Firewall im USG verbietet den Aufbau von deinem Fritzbox Netz in das Netz hinter dem USG.
  Ich habe eine ähnliche Konfiguration. Allerdings gebe ich nicht den Port meiner Diskstation ins Internet frei, sondern verwende die VPN Funktionalität der FritzBox um von außen in das FritzBox Subnet zu kommen und dann auf die Geräte hinter der Firewall des USG zuzugreifen.
  
  Eine weitere Fehlerursache: Manche Internetprovider weisen nur noch private IPv4 Adressen zu. Dann kommst du von “außen” auch nicht an deine FritzBox.
  
  Hilft dir das weiter?
  
  Gruß Martin
  
  Antworten
2. Detlef Meyer sagt:
  
  14. Dezember 2019 um 15:38 Uhr
  
  Super genial.
  Nach dieser Lösung suche ich seit Monaten.
  Seit dem Wechsel auf FTTH habe ich zwar eine phantastiache Internetgeschwindigkeit, aber weil ich den externen Zugriff auf mein Nas über IPV6 mit dem USG nicht hinbekommen habe, klappt es nun mit dieser Lösung und endlich kann ich die features vom USG wieder Nutzen
  
  LG Detlef
  
  Antworten
  1. Detlef Meyer sagt:
    
    1. Februar 2020 um 23:49 Uhr
    
    Hallo Manfred,
    leider war die Freude nur von kurzer Dauer, weil ich es nicht hinbekommen habe das meien Geräte auch per DHCP IPV6 Adressen bekommen. Meine Synology konnte ich deswegen nicht mehr von außen ansprechen.
    Das würde ich gerne nochmal angehen. Mein USG liegt jetzt schon 6 Monate brach. Ich würde es gerne wieder aktivieren.
    Kannst Du mir helfen um IPV6 DHCP zu aktivieren.
    
    LG
    Detlef Meyer
    
    Antworten
Georg sagt:

28. April 2019 um 17:03 Uhr

Hallo Martin,

endlich bin ich auf einen tollen Artikel gestossen der genau das gelöst zu haben scheint was ich gern möchte, dafür erstmal Vielen Dank für den Artikel.
Ich hätte aber eine Frage dazu , was für mich ganz wichtig ist bevor ich das ganze umbaue wie du es beschreibst, wie verhält es sich mit dem VPN Tunnel zur Fritzbox , du schreibst man muss die IP Adresse des VP Clients (user) (Quell-Typ: IP-Adresse (im Beispiel 192.168.0.201, IP ist auf den Wert, den die FRITZ!Box für den jeweiligen VPN-Benutzer anzeigt anzupassen)

Diese Ip Adresse wird ja mit jeder VPN Verbindungsaufbau neu vergeben bzw sobald die Fritzbox eine neue IP Adresse vom Provider bekommt wenn ja wie hast du das Problem gelöst das die Ip Adresse wechseln, ich wüsste nicht wie ich das handeln sollte wenn ich ständig die die Route anpassen müsste auf dem USG

Vielen Dank

Gruss

Georg

Antworten
1. Martin Ziegler sagt:
  
  28. April 2019 um 18:57 Uhr
  
  Hallo Georg,
  es freut mich, wenn dir der Artikel weitergeholfen hat. Zu deiner Frage: Ja, sobald eine VPN-Verbindung neu aufgebaut wird (zum Beispiel, weil dein Client sich absichtlich getrennt hat oder dein Provider deine Internetverbindung beendet hat) bekommt der jeweilige VPN Client von der FritzBox eine neue interne IP-Adresse zugeordnet. Der erste sich verbindende Client bekommt bei mir immer die 192.168.0.201 (das Subnet kann bei dir abweichen). Im USG musst du für diesen Fall nicht das Routing anpassen sondern eine eingehende Firewall-Regel definieren. Das solltest du im Idealfall nur bei der Inbetriebnahme machen müssen.
  
  Das Vergeben der VPN-IP-Adressen der FritzBox ist unabhängig von der UniFi-Infrastruktur. Wenn du bereits eine FritzBox im Einsatz hast, kannst du vor der Anschaffung/Installation deiner UniFi-Infrastruktur in Ruhe beobachten, welche IP-Adressen die FritzBox deinen VPN-Clients vergibt (im Idealfall lässt du alle in Frage kommenden VPN-Clients sich auf einmal anmelden). Basierend auf diesen IP-Adressen kannst du später die Firewallregel im USG erstellen.
  
  Sollte es dir zu umständlich sein, kannst du die Regel aus dem Beitrag auch so anpassen, dass anstelle einer definierten IP (z. B. 192.168.0.201) das komplette Subnet (z. B. 192.168.0.0) zugelassen wird. Abhängig davon wie dein Netzwerk aufgebaut ist, kann das in Ordnung oder ein Sicherheitsproblem sein.
  
  Nur um sicher zu gehen: Die IP-Adresse des VPN-Clients (im Beispiel 192.168.0.201) ist nicht die externe IP-Adresse, die vom Provider zugewiesen wird. Der VPN-Client spricht die externe IP-Adresse (vom Provider) über einen DynDNS Dienst an und bekommt, im so aufgebauten Tunnel, die interne VPN-IP-Adresse mit der er für das USG sichtbar ist.
  
  Ich hoffe, ich habe deine Fragen richtig interpretiert – wenn nicht, einfach melden.
  
  Gruß Martin
  
  Antworten
Georg sagt:

30. April 2019 um 11:02 Uhr

Hallo Martin

Aktuell ist meine fritzbox dhcp Server und verteilt im Range 192.168.1…. die Adressen, wer würden dann dhcp Server spielen für das interne Netzwerk ? Und könnte ich nur die ip Adresse der fritzbox änderen auf 192.168.0… so das meine interne ip Adressen weiterhin in 192.168.1 laufen ?
Und noch eine Frage 🙂 was passiert mit dem Fritz Telefon ? Wird das direkt dann an die fritzbox angeschlossen und wandert in das neue Netz der fritzbox ?

Vielen Dank

Gruß
Georg

Antworten
1. Martin Ziegler sagt:
  
  30. April 2019 um 13:32 Uhr
  Hallo Georg,
  wenn du eine Infrastruktur wie im Artikel beschrieben aufbaust, hast du zwei interne Subnetze. Eines, für das deine FritzBox zuständig ist und eines, für das das USG zuständig ist.
  Für diese zwei Netze kannst – bzw. musst – du Adressen aus zwei verschiedenen (privaten) Netzen verwenden. Zum Beispiel:
  - Die FritzBox verwaltet das Netz 192.168.1.0/24 (IP von 1-254; 0=Netz; 255=Broadcast)
  - Das UniFi Security Gateway verwaltet das Netz 192.168.34.0/24 (IP von 1-254; 0=Netz; 255=Broadcast)
  Alle Clients im Netz der FritzBox bekommen so Adressen aus dem Netz 192.168.1.0 – auch das USG auf seinem WAN Port. Das USG vergibt an alle Geräte, die in seinem Netz hängen, Adressen aus dem Netz 192.168.34.0. In der FritzBox konfigurierst du eine statische Route in das 34er Netz (über die WAN-IP des USG aus dem 1er Netz). Die USG hat bereits eine Route ins 1er Netz, daher können alle Clients aus dem 34er Netz, über das USG auf das von der FritzBox verwalte Netz zugreifen (die Clients im 34er Netz bekommen vom USG die 34er Adresse des USG als Default-Route mitgeteilt).
  
  Etwas konkreter zu deinen Fragen:
  Wenn das “Fritz Telefon” per DECT, ISDN oder analog an der FritzBox hängt, musst du nichts machen. Wenn du ein VoIP basiertes Telefon oder die Fritz!Fon-App nutzt, können diese Geräte aus beiden internen Netzen auf die FritzBox zugreifen. Ich habe meine an der FritzBox angemeldeten VoIP Telefone im Netz “hinter” dem USG, du kannst sie aber auch direkt ins Netz der FritzBox hängen.
  
  IP-Adresse der FritzBox ändern: Wenn ich dich richtig verstehe, willst du die IP deiner FritzBox von 192.168.1.1 auf 192.168.0.1 ändern, dann das USG so einstellen, dass es Adressen aus dem Netz 192.168.1.0 verteilt, damit du deine Clients nicht anpassen musst. Ja, kannst du machen. Wenn deine Clients Ihre Adressen per DHCP bekommen, musst du die Reihenfolge, wann du was umstellst sehr genau überlegen – sonst hast du Durcheinander. Wenn du bisher nur feste IPs für deine Clients verwendet hast, ist es weniger “aufwändig”. Wenn du es bei dir zuhause umstellst, kann es helfen alle Geräte abzuschalten, die Infrastruktur aufzubauen, zu testen und dann jedes Gerät einzubinden und zu prüfen.
  
  Anmerkung zu privaten IP-Adressen. Die FritzBox verwendet 192.168.178.0 als Gäste Netzwerk, dass solltest du nicht im USG definieren. Wenn du VPNs zwischen verschiedenen Standorten aufbauen möchtest, solltest du auch drauf achten, dass sich die Subnetze unterscheiden.
  
  Ich hoffe, es ist nicht zu umständlich beschrieben. Wenn doch, einfach fragen.
  
  Gruß Martin
  Antworten
  1. Jakob sagt:
    
    4. Mai 2019 um 23:24 Uhr
    
    Hallo Martin,
    
    Ich habe die gleiche Infrastruktur (Fritzbox -> USG -> Switch -> APs) und ein Problem mit VOIP:
    
    Ich habe die Fritz!Fon-App auf meinem Handy eingerichtet und auf einem PC eine weitere VOIP-Software. Raustelefonieren funktioniert problemlos, aber sobald ein Anruf hereinkommt, klingeln lediglich die an meiner Fritzbox angeschlossenen Analogtelefone, aber am Handy und PC tut sich nichts. Wenn ich die beiden Geräte direkt mit der Fritzbox verbinde, funktioniert alles problemlos. Das NAT auf meinem USG ist deaktiviert. Mit den Portfreigaben habe ich auch schon experimentiert, leider ohne Erfolg.
    
    Gibt es irgendwelche Einstellungen, die man tätigen muss, um das zum Laufen zu bringen?
    
    Vielen Dank.
    
    Gruß Jakob
    
    Antworten
    1. Martin Ziegler sagt:
      
      6. Mai 2019 um 10:43 Uhr
      
      Hallo Jakob,
      
      das eingehende Anrufe bei deinen analogen Telefonen signalisiert werden, ist schon mal ein gutes Zeichen – so bist du zur Lösung nicht auf deinen Telefonieanbieter angewiesen.
      Ich habe bei meiner Installation – neben direkt an der FritzBox angemeldeten DECT-Telefonen – diese VoIP Geräte/Software im Einsatz:
      
      Fritz!Fon-App (iOS),
      
      Siemens Gigaset Maxwell 3 und
      
      media5-fone (iOS, Hinweis vom Hersteller: Media5 wird Sommer 2018 eingestellt).
      
      In deiner Frage hast du die statische Route von der FritzBox in das Netz “hinter” dem USG nicht erwähnt. Hast du eine konfiguriert?
      
      Für jedes VoIP-Telefon habe ich auf der FritzBox ein eigenes Telefoniegerät angelegt, in der FritzBox eingestellt, auf welche eingehenden Nummern das Telefoniegerät reagieren soll und mit welcher Nummer ausgehende Gespräche von dem jeweiligen Gerät geführt werden sollen. Der Benutzer für die Fritz!Fon-App (iOS) wurde von der App angelegt. Firewallregeln oder Portweiterleitungen auf der USG habe ich für VoIP keine konfiguriert.
      
      Eingehende Anrufe werden auf den konfigurierten Endgeräten signalisiert. Die Software auf iOS muss laufen, damit die Anrufe signalisiert werden. Bei der Fritz!Fon-App gibt es bei den Einstellungen die Option “Auf Anrufe reagieren”, die Option muss aktiv sein. Sowohl die Soft- als auch das Hardware VoIP Telefon sind bei mir in IP-Netzten “hinter” dem USG.
      
      Vielleicht ist eine der Optionen ja für dich die richtige.
      
      Gruß
      
      Martin
      
      Antworten
      1. Jakob sagt:
        
        8. Mai 2019 um 22:49 Uhr
        
        Hallo Martin,
        
        ich habe für das IP-Netzwerk, das hinter dem USG liegt, eine statische Route in der Fritzbox eingerichtet. Dann habe ich am USG eine Route in das IP-Netzwerk der Fritzbox eingerichtet.
        Das hat aber noch nicht genügt. Ich musste noch eine Portfreigabe für den lokalen SIP Port, der in den Einstellungen der VOIP-Software auf meinem Rechner angezeigt wird, einrichten. Nun klingelt auch bei einkommenden Anrufen das Telefon.
        Allerdings stehe ich jetzt vor einem weiteren Problem: Man hört keinen Ton.
        Die Telefoniegeräte sind in der Fritzbox korrekt eingerichtet und funktionieren auch einwandfrei, solange sie sich nicht in einem Netz hinter dem USG befinden. Ich muss wohl die nötigen Ports am USG freischalten. Allerdings weiß ich nicht, welche das sind.
        
        Vielen Dank.
        
        Gruß Jakob
        
        Antworten
        
        Martin Ziegler sagt:
        
        11. Mai 2019 um 17:12 Uhr
        
        Hallo Jakob,
        das klingt für mich als wäre NAT auf dem USG noch aktiv. Auf dem USG brauchst du, nachdem NAT deaktiviert ist, keine statische Route in das Netz der FritzBox zu konfigurieren (die USG hat eine Route in das Netz, da es eine IP-Adresse aus diesem Netz auf dem WAN-Interface hat). Wenn NAT deaktiviert ist, musst du auch keine Ports am USG freischalten/weiterleiten.
        Nachdem du auf dem UniFi Cloud Key im Verzeichnis /srv/unifi/data/sites/default die Datei config.gateway.json angepasst hast, muss du eine Provisionierung des USG manuell auslösen, damit die Firewallregel zum deaktivieren des NAT aktiv wird – eventuell fehlt dieser Schritt? Ich werde ihn im Artikel ergänzen.
        
        Gruß Martin
        
        Antworten
Maik sagt:

22. Mai 2019 um 17:53 Uhr

Hallo Martin,

Erstmal Danke für die ausführliche Beschreibung.
Ich bin in Sachen Unifi noch ein Anfänger.
In meiner Konstellation funktioniert der Internetzugriff über die FB leider nicht.
Hänge ich die FB hinter das USG dann funktioniert alles. ( das USG wird ja quasi umgangen)
Meine FB hat die IP 192.168.1.2/24 DHCP ist eingeschaltet. Das USG hat ja Standard 192.168.1.1 dies lässt sich ja nicht abändern, soviel ich weiß. Wenn ich alles richtig verstanden habe, dann hat der WAN am USG ja auch eine andere IP und zwar die zugewiesene von der FB. Welche Route muss ich nun in der FB eintragen?

Antworten
1. Martin Ziegler sagt:
  
  22. Mai 2019 um 21:56 Uhr
  Hallo Maik,
  ich fürchte, ich habe nicht nur Antworten für dich.
  
  Erst mal zu den Antworten.
  Deine FritzBox hat “die IP 192.168.1.2/24 DHCP ist eingeschaltet”, bezieht sich auf die “LAN” Ports. Am “WAN” (DSL) Port hast du die IP deines Providers. Bzw., wenn du den WAN/DSL-Port deiner FritzBox mit dem USG verbunden hast bekommst du eine IP aus dem DHCP Range des USG. Das ist aus meiner Sicht auch schon die erste Stelle, die du anpassen solltest. Du solltest entweder deine FritzBox oder dein USG für ein anderes IP-Subnetz konfigurieren. Sowohl die IP der FritzBox als auch des USG lassen sich in andere Subnetze konfigurieren. Warum ist das wichtig: Wenn das USG mit seinem WAN-Port an einem LAN-Port der FritzBox (192.168.1.0/24) hängt und “alle deine Clients” hinter dem USG an dessen LAN-Port (192.168.1.0/24) hängen, steht das USG vor einem Dilemma. Wenn es Pakte in das Subnetz (192.168.1.0/24) schicken will, weiß es nicht auf welchem Interface (LAN oder WAN) die Pakete raus sollen. Als “Router” verbinden das USG und auch die FritzBox jeweils verschiedene Subnetze. Wenn du gleiche Subnetze verbinden wolltest, würdest du einen Switch/Hub verwenden.
  
  Was mir nicht ganz klar ist, ist wie “alles funktioniert”, wenn die FritzBox “hinter” dem USG ist. Ich stelle mir das so vor: DLS -> WAN PORT USG (kein internes Modem, sollte nicht gehen) -> LAN Port USG -> DSL/WAN-Port FritzBox (gleiches SubNetz am DSL/WAN-Port & LAN-Port der FritzBox; kein Routing möglich). Hier muss ich dich entweder falsch verstanden haben oder ich übersehe ein Detail. Wenn du das USG “vor” der FriitzBox installierst, brauchst du zusätzlich ein Modem (DSL, Kabel, …).
  
  Zum Abschluss noch eine Antwort.
  Welche Route muss du in die FritzBox eintragen: Wenn USG & FritzBox in verschiedenen Subnetzen sind und NAT auf dem USG deaktiviert ist, musst du in der FritzBox eine Route in das Netz hinter dem USG mit der IP, die das USG im SubNetz der FritzBox hat konfigurieren.
  Zum Beispiel:
  - FritzBox LAN-IP: 192.168.34.1
  - FritzBox LAN-Subnet: 192.168.34.0/24
  - USG WAN-IP: 192.168.34.250 (von der FritzBox bekommen oder fest eingestellt)
  - USG WAN-Subnet: 192.168.34.0/24 (Netz der FritzBox)
  - USG LAN-IP: 192.168.1.1
  - USG LAN-Subnet: 192.168.1.0/24
  - Route auf der Fritzbox: Alle Pakete für das Netz “192.168.1.0/24” (USG LAN-Subnet) an die IP “192.168.34.250” (USG WAN-IP) schicken.
  Wenn USG & FritzBox in verschiedenen Subnetzen sind und NAT auf dem USG aktiviert ist, musst du in der FritzBox keine Route eintragen. Hast dann aber “Doppeltes NAT”.
  
  Entschuldige die umständliche Beschreibung, ich hoffe du kannst etwas für dich darin finden.
  
  Gruß
  Martin
  Antworten
Markus Adam sagt:

27. Mai 2019 um 16:21 Uhr

Hallo

danke für die Erklärung. Noch eine kurze Frage zur Verkablung. Du hast am WAN der Fritzbox das DSL dran und an einem LAN Port das USG. Das USG hängt am WAN port mit der Fritzbox zusammen und am LAN Port hängt der Uplink zu den Clients dahinter. Richtig?

Vg
Markus

Antworten
1. Martin Ziegler sagt:
  
  27. Mai 2019 um 17:11 Uhr
  Hallo Markus,
  ja.
  
  Hier die genauen Bezeichnungen der Ports:
  - FritzBox 7490 “DSL/TEL” -> TAE Dose/DSL-Anschluss
  - FritzBox 7490 “LAN 1” -> USG “WAN 1”
  - USG “WAN 1” -> FritzBox 7490 “LAN 1”
  - USG “LAN 1” -> Switch (UniFi Switch 24 POE-250W) mit restlicher Infrastrukur, mehrere VLANs…
  Gruß
  Martin
  Antworten
  1. Mario sagt:
    
    12. Januar 2020 um 22:34 Uhr
    
    Hallo,
    
    Darf ich bei deiner Antwort kurz noch eine Frage ergänzen, weil ich diesen Artikel mit der Diskussion super hilfreich und interessant finde.
    
    Wenn, wie von Dir beschrieben, das USG mit mehreren vlans hinter der fritzbox hängt, muss ich dann in der fritzbox auch statische routen in die IP Bereiche der Vlans einrichten?
    
    ZB habe ich 3x vlans hinter dem USG. Und einen Server hinter dem USG, auf den alle vlans und auch clients, die direkt an der FB hängen zugreifen müssen…
    
    Im USG muss ich wahrscheinlich die IP des servers für alle vlans freigeben (wie genau muss ich noch herausfinden) aber
    Von der fritzbox würde ich auch gerne Zugang auf die IP Bereiche inkl. Server haben..
    
    Ich hoffe du hast einen kurzen Rat für mich.
    
    Beste Grüße,
    Mario
    
    Antworten
    1. Martin Ziegler sagt:
      
      13. Januar 2020 um 22:26 Uhr
      
      Hallo Mario,
      für die VLANs (mit je eigenen IPv4 Netzen) hinter deinem USG brauchst du, wie du bereits geschrieben hast, jeweils eine eigene statische Route in der Fritz!Box. Die Daten vom Netz der Fritz!Box zu Netzen hinter dem USG lassen sich über “WAN eingehend” bei den Firewallregeln des USG filtern/freigeben. Wenn der Server in einem Netz hinter dem USG hängt (untagged?) musst du für den Zugriff aus den VLANs “hinter” dem USG in der Regel nichts konfigurieren, da per default nichts blockiert wird – ansonsten wäre die Regel bei “LAN eingehend” gut aufgehoben.
      
      Hoffe das hilft dir weiter.
      
      Gruß
      Martin
      
      Antworten
      1. Mario sagt:
        
        13. Januar 2020 um 23:14 Uhr
        
        Besten Dank! Das hat mir auf jeden Fall geholfen und ich werde es einmal durchspielen!
        
        Beste Grüße!
        
        Mario
        
        Antworten
Tim sagt:

29. Mai 2019 um 15:03 Uhr

Ich habe eine ähnliche Situation. Ich möchte demnächst mal Lösung 3 ausprobieren: https://community.ubnt.com/t5/UniFi-Routing-Switching-Feature/USG-passthrough-monitor-mode/idi-p/1537588/page/35

Vorteil wäre ein Subnetz. Hoffe der Durchsatz ist noch ausreichend beim USG.

Antworten
Lukas sagt:

31. Mai 2019 um 22:29 Uhr

Hallo Herr Ziegler, vielen Dank für die ausführliche Anleitung! Ich habe einen Unitymedia Anschluss, den ich genau wie beschrieben betreiben möchte. Allerdings möchte ich am WAN Port 2 einen Vodafone DSL Anschluss parallel betreiben, einmal zur Bündelung aber auch als gegenseitiges Backup, falls eine Verbindung mal ausfällt. Ich nehme an, in diese, Fall muss das Gateway NAT übernehmen, oder? Vielen Dank für Ihre Antwort!

Antworten
1. Martin Ziegler sagt:
  
  2. Juni 2019 um 21:25 Uhr
  Hallo,
  
  das ist eine spannende Frage. Da ich selbst nur einen DSL Anschluss habe, kann ich es nicht direkt testen. Vom Vorgehen her, würde ich in den Einstellungen des UniFi Controllers unter “Netzwerk” ein “Neues Netzwerk erstellen” und so konfigurieren:
  - Verwendung: WAN
  - Netzwerk Gruppe: WAN2
  - Lastverteilung: Nur Failover
  - Statusänderung der Schnittstelle melden: Ja
  In der Grundkonfiguration würde ich erwarten, dass das USG einen Ping auf einen Server im Internet über WAN1 laufen hat, schlägt dieser fehl, schaltet es automatisch auf WAN2 um (und auch wieder zurück). Wenn diese Konfiguration erfolgreich läuft, würde ich im nächsten Schritt versuchen NAT zu deaktivieren (wenn Sie das benötigen). Sollte auch das funktionieren, würde ich versuchen, die Einstellung für die Lastverteilung auf “Gewichtetes Load-Balancing” zu ändern.
  
  Bevor Sie einen DSL-Vertrag abschließen, könnten Sie einen UMTS/LTE Router (mit LAN Port) mit Ihrer Handykarte zum Testen verwenden.
  
  Leider alles ohne Gewähr, aufgrund mangelnder Möglichkeit zum Testen (habe kein UMTS/LTE Modem mit LAN Anschluss greifbar). Wenn Sie den Test wagen, wäre ich sehr am Ergebnis interessiert.
  
  Gruß
  
  Martin Ziegler
  Antworten
  1. Lukas Bergmann sagt:
    
    4. Juni 2019 um 16:11 Uhr
    
    Vielen Dank auch für die Antwort! Vodafone wird am 26.06.2019 geschaltet, danach kann und werde ich alle Möglichkeiten testen und gerne nochmal antworten.
    
    Antworten
Tobias sagt:

20. Juni 2019 um 19:51 Uhr

Hallo Martin,
genau eine solche Lösung habe ich gesucht, vielen Dank!!

Kurze Frage: Wie verhält es sich bei einem Software/Firmware Update? Müssen die Modifikationen der Config Datei dann wiederholt werden, oder wird diese bei einem Update nicht überschrieben?

Solltest du das schon geschrieben und ich überlesen haben, bitte ich um Entschuldigung 😉

Danke, beste Grüße
Tobi

Antworten
1. Martin Ziegler sagt:
  
  21. Juni 2019 um 8:10 Uhr
  
  Hallo Tobias,
  die Lösung übersteht Updates an der Geräte-Firmware des UniFi Security Gateway und Updates des UniFi Controller ohne manuelle Nacharbeiten. Die editierte Datei config.gateway.jso ist Bestandteil der “normalen” Konfiguration des UniFi Controllers. Nur die geänderten Optionen sind (noch) nicht über das Webinterface änderbar.
  
  Gruß
  
  Martin
  
  Antworten
Christian sagt:

23. Juni 2019 um 15:49 Uhr

Hallo Martin,
vielen Dank für die Anleitung, doch leider weiß ich nicht, ob das mit der Datei geklappt hat. Hier wäre auch mein erster Hinweis, denn die Datei wird als*.txt gespeichert sobald man diese runterläd. Somit muss diese dann noch an die Dateiendung angepasst werden.

Gibt es eine Möglichkeit die Funktionalität zu testen? Ich bin mir nicht sicher ob alles geklappt hat. Wenn ich bei meiner Xbox one X den Nat Typ feststellen möchte springt dieser immer zwischen “moderat” und “offen” hin und her. Übrigens ist dies unabhängig ob die josn Datei sich auf dem Cloud Key befindet oder eben nicht.
Weiterhin ist mir aufgefallen das ich keine Möglichkeit mehr habe meinen Vorwerk VR 200 Staubsaugroboter ans Wlan zu bringen (hier wird ein AddHoc WLAN zur Konfiguration aufgemacht und anschließend versucht die Verbindung mit dem “richtigen” Wlan aufzubauen).

Kurz um, ich weiß nicht ob die Datei auf dem Cloud Key und die anschließende Provisierung überhaupt ein Effekt hat…

Auch der versuch in der CMD mit “tracert 8.8.8.8” zeigt mir zuerst die IP meiner Firtz Box (192.168.5.1) und anschließend die IP des USG (192.168.1.1). Somit ist dies ja eigentlch schon falsch da der zweite Sprung schon die WAN Adresse sein sollte, oder?

Viele Grüße und vielleicht hast du ein Tipp für mich,
Chrisitan

Antworten
1. Martin Ziegler sagt:
  
  23. Juni 2019 um 20:45 Uhr
  Hallo Christian,
  
  vielen Dank für deine Anmerkungen und Fragen.
  
  Json wird als TXT gespeichert: Per Default ist der Upload von json-Dateien bei WordPress nicht erlaubt. Als ich den Artikel geschrieben habe, war ich wohl etwas faul und habe die Datei in *.txt umbenannt. Ich habe die Datei erneut mit der richtigen Endung hochgeladen. Danke für den Hinweis.
  
  Dein tracert-Ergebnis deutet darauf hin, dass etwas nicht stimmt. So sieht’s bei mir aus:
  tracert 8.8.8.8 Routenverfolgung zu dns.google [8.8.8.8] über maximal 30 Hops: 1 1 ms 1 ms 1 ms UnifiGateway [192.168.1.1] 2 1 ms 1 ms 1 ms fritz.box [192.168.0.1] 3 8 ms 9 ms 9 ms #anderer Hop 4 8 ms 8 ms 8 ms #anderer Hop 5 10 ms 8 ms 9 ms #anderer Hop 6 9 ms 8 ms 8 ms #anderer Hop 7 9 ms 8 ms 8 ms #anderer Hop 8 8 ms 8 ms 8 ms #anderer Hop 9 8 ms 8 ms 8 ms dns.google [8.8.8.8]
  Erst kommt das USG, dann die FritzBox. Wie hast du deine Installation verkabelt?
  - FritzBox 7490 “DSL/TEL” -> TAE Dose/DSL-Anschluss
  - FritzBox 7490 “LAN 1” -> USG “WAN 1”
  - USG “WAN 1” -> FritzBox 7490 “LAN 1”
  - USG “LAN 1” -> Deine restliche Infrastruktur
  Wichtig ist, dass die FritzBox nicht zusätzlich an dem Switch “hinter” deinem USG hängt und das die FritzBox kein eigenes WLAN aufspannt (wenn du alles über UniFi Accesspoints machst). Alle Endgeräte bekommen IPs aus Subnetzen des USG (nicht von der FritzBox).
  
  Wenn du prüfen willst, ob die Regel 5999 aus der json-Datei auf dem USG aktiv ist, kannst du dich per SSH am USG anmelden und mit diesem Befehl den Status von iptables anschauen:
  sudo iptables -t nat -L -n -v
  Beim Output sollte eine Zeile mit NAT-5999 dabei sein:
  ... Chain POSTROUTING (policy ACCEPT 808K packets, 62M bytes) pkts bytes target prot opt in out source destination 808K 62M UBNT_VPN_IPSEC_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 808K 62M MINIUPNPD-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0 808K 62M UBNT_PFOR_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 739K 57M RETURN all -- * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set corporate_network src /* NAT-6001 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set remote_user_vpn_network src /* NAT-6002 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set guest_network src /* NAT-6003 */ 69080 4630K VYATTA_PRE_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 ...
  
  Das dein Staubsauger aktuell die Arbeit verweigert, stufe ich als Folgeproblem ein.
  
  Ich hoffe, es ist etwas dabei, was dir weiterhilft. Ansonsten einfach nachfragen.
  
  Gruß
  
  Martin
  Antworten
  1. Christian sagt:
    
    23. Juni 2019 um 23:20 Uhr
    
    Hallo Martin,
    danke für deine ausführliche Antwort. Bei mein tracert-Ergebnis sind die beiden ersten Punkte wie deine, hatte dies nur fälschlicherweise anders rum geschrieben. Ich dachte es dürfte erst gar keinen zweiten “Sprung” im eigenen Netz geben, weil dies unweigerlich zu einem doppelten NAT führt. Zumindest habe ich es in einem Forum so gelesen.
    
    Auch die Regel für Port 5999 ist bei mir via SSH Aufruf ersichtlich:
    
    314 22755 RETURN all — * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set corporate_network src /* NAT-6001 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set remote_user_vpn_network src /* NAT-6002 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set guest_network src /* NAT-6003 */
    65 4175 VYATTA_PRE_SNAT_HOOK all — * * 0.0.0.0/0 0 .0.0.0/0
    
    Wieso mein Roboter dann noch Probleme hat muss dann an etwas anderem liegen.
    
    Grüße
    Christian
    
    Antworten
    1. Martin Ziegler sagt:
      
      24. Juni 2019 um 22:37 Uhr
      
      Hallo Christian,
      jeder “Sprung” zeigt an, dass du in ein neues IP-Netz kommst. NAT/Masquerading kann genutzt werden um alle IP-Adressen eines Netzes hinter einer einzigen “zu verstecken”. Wenn du zum Beispiel eine FritzBox (oder irgendeinen anderen Router) verwendest, um ins Internet zu gehen, “maskiert” dieser sämtliche Anfragen aus deinem privaten Netz mit der öffentlichen IP Adresse am “DSL-Port” deiner FritzBox. Egal ob dein Staubsauger oder deine Xbox eine Anfrage ins Internet stellt, es sieht dort immer so aus, als würde die Anfrage von der IP deiner FritzBox kommen.
      Wenn dein USG auch NAT macht passiert folgendes:
      Wenn die FritzBox IPs aus dem Subnetz 192.168.5.0 vergibt und dein USG aus dem Subnetz 192.168.1.0 (auf dem LAN-Port) und die IP 192.168.5.200 (per DHPC von der FritzBox auf dem WAN Port des USG) bekommt, hat deine XBOX “hinter” dem USG zum Beispiel die Adresse 192.168.1.23. Da das USG NAT aktiv hat, kommen Anfragen von der XBOX bei der Fritzbox mit der IP des USG im Netz der FritzBox an (192.168.5.200) – ohne NAT auf dem USG würde die FritzBox die echte IP Adresse 192.168.1.23 der XBOX sehen. Da private IP Adressen nicht im Internet geroutet werden dürfen, muss der Router an der Schnittstelle von deinem privaten zum öffentlichen Netz NAT/Masquerading durchführen. Alle Router zwischen deinen privaten Netzen (zum Beispiel dein USG) können normal zwischen den Netzen routen und brauchen kein NAT/Masquerading.
      Einige Provider oder Anschlüsse mit DSL-Light vergeben auch am WAN-Port deines Routers (FritzBox) IPv4 Adressen aus privaten, nicht im Internet gerouteten Bereichen. Hier hättest du schon 2x NAT (Provider, FritzBox) und bekommst eventuell noch eine dritte Stufe (USG) dazu. An DSL-Light Anschlüssen kannst du, soweit ich weiß, nichts dagegen machen. Manche Provider (zum Beispiel Inexio) bieten “echte IPv4-Adressen” gegen einen monatlichen Aufpreis an.
      
      Ich hoffe das ist ohne Bild einigermaßen vorstellbar…
      
      Ist der NAT-Status deiner XBOX inzwischen stabil? Hast du neben IPv4 auch IPv6 aktiv? Dort hast du die Routing-Probleme normalerweise nicht. Hast du UPnP-Portfreigaben für die IP deiner XBOX auf der FritzBox erlaubt?
      
      Gruß
      
      Martin
      
      Antworten
      1. Christian sagt:
        
        25. Juni 2019 um 9:45 Uhr
        
        Hallo Martin,
        danke für deine ausführliche Erklärung. Der Nat Status meiner Xbox ist für mich die einzige Möglichkeit um die Funktionalität des json Datei zu testen, unabhängig von der Abfrage via SSH. Wenn die Sprünge via tracert bei dir genau so sind wie bei mir und die Regel 5999 auf dem USG auftaucht wird es wohl funktionieren.
        
        Bezüglich UPnP:
        Ich habe auf der FritzBox aktuell nur einen Teilnehmer, nämlich den USG. Somit kann ich doch nur für diesen Teilnehmer (was letztendlich dann meinem kompletten nachgelagerten LAN entspricht) die UPnP Freigabe erteilen, oder sehe ich das flasch?
        
        Generell müsste ich dann doch zusätzlich noch eine Freigabe auf dem USG definieren, da diese ja nur als Firewall dient oder liege ich hier abermals falsch?
        
        Viele Grüße und besten Dank.
        Christian
        
        Antworten
        
        Martin Ziegler sagt:
        
        26. Juni 2019 um 20:53 Uhr
        
        Hallo Christian,
        in der Fritzbox werden bei den Freigaben leider nur die Geräte angezeigt, die direkt im IP-Netz der FritzBox sind. Du kannst aber durchaus mit “IP-Adresse manuell eingeben…” auch IPs “hinter” dem USG konfigurieren (solange NAT im USG deaktiviert ist). So kannst du es deiner XBox One erlauben Portfreigaben in der FritzBox einzurichten. Dafür sollte deine Xbox vom USG immer die selbe IP-Adresse bekommen.
        Zusätzlich darf die Firewall in deinem USG, wie du richtig angemerkt hast, eingehenden Verkehr zum Netz hinter dem USG natürlich nicht filtern – bzw. du muss es mit einer “WAN eingehend” Regel aktiv erlauben (allen eingehenden Verkehr zur IP deiner Xbox erlauben; optional mit Einschränkung auf bestimmte Ports).
        
        Gruß
        
        Martin
        
        Antworten
      2. Christian sagt:
        
        25. Juni 2019 um 12:26 Uhr
        
        Hallo Martin,
        kleiner Nachtrag:
        Aktuell habe ich nur eine statische Route von der FirtzBox auf das USG eingetragen:
        Netzwerk Subnetzmaske Gateway
        192.168.1.0 255.255.255.0 192.168.5.21
        
        Auf dem USG habe ich nur eine Firewallregel für VPN hinterlegt. Muss hier auch eine statische Route eingetragen werden Richtung FritzBox und wenn ja, wie?
        
        Grüße
        
        Antworten
        
        Martin Ziegler sagt:
        
        26. Juni 2019 um 20:59 Uhr
        
        Hallo Christian,
        du brauchst für das Fritz-Box VPN im USG keine Route “zurück” einzurichten. VPN-Clients bekommen von der FritzBox IP-Adressen “nach” deinem DHCP Bereich. Zum Beispiel: Deine FritzBox vergibt per DHCP die IP Adressen 192.168.5.20-192.168.5.200, dann bekommt dein erster VPN-Client die 192.168.5.201. Da dein USG am WAN-Interface eine IP-Adresse aus dem Subnetz 192.168.5.0 hat, kennt es dadurch auch eine “Route” in dieses Netz.
        
        In der Firewall des USG muss du nur, wie du bereits beschrieben hast, eingehenden Verkehr für “WAN eingehend” von deiner VPN-IP auf bestimmte Server oder alle Netzte hinter deinem USG erlauben.
        
        Gruß
        
        Martin
        
        Antworten
Rainer sagt:

27. Juni 2019 um 13:15 Uhr

Hallo Martin,

vielen Dank für die tolle Anleitung.

Ich würde das NAT auf der USG auch gerne ausschalten und verschiedene Szenarien ausprobieren. Mein UniFi-Controller läuft allerdings auf Windows, da ich keinen Cloud-Key habe. Alternativ könnte ich die Controller-Software auch auf meiner Synology im Docker laufen lassen.

Könntest Du vielleicht bei der Pfad-Angabe behilflich sein, wo die “config.gateway.json” bei Windows und/oder Docker hingehört? Oder geht das Abschalten über den Weg nur in Verbindung mit einem Cloud-Key?

Danke und Gruß
Rainer

Antworten
1. Martin Ziegler sagt:
  
  28. Juni 2019 um 7:27 Uhr
  
  Hallo Rainer,
  der CloudKey ist keine Voraussetzung für die Änderungen. Unter Windows findest du deinen unifi_base-Pfad indem du %userprofile%/Ubiquiti UniFi in die Adressleiste deines Windows-Datei-Explorers kopierst. Wenn du unter Linux unsicher bist, kannst du schauen ob es ein Verzeichnis /srv/unifi oder /lib/unifi gibt. Alternativ kannst du dein ganzes Dateisystem durchsuchen
  find / -name unifi.
  
  Hier die englische Hilfe-Seite von Ubiquiti : UniFi – Where is <unifi_base>?
  
  Gruß
  Martin
  
  P.S. Der CloudKey (Gen 1) ist “nur” ein kleiner Server mit ARMv7 Processor und 2 GB RAM auf Basis Debian 8 (jessie) – alle Features für das UniFi Netzwerk werden über die Manager-Software gesteuert.
  
  Antworten
Rainer sagt:

28. Juni 2019 um 10:42 Uhr

Hallo Martin,

vielen Dank für Deine Hilfe.

Ich habe die “config.gateway.json” in das Verzeichnis

%userprofile%\Ubiquiti UniFi\data\sites\site_ID

eingefügt und in der Controler-Software über

Geräte-USG-Konfiguraton-Geräte verwalten-Provisionierung erzwingen

die Provisionierung manuell durchgeführt. Den letzten Ordner “site_ID” musste ich händisch anlegen.

Als Ergebnis eines tracert erhalte ich folgendes Ergebnis:

Routenverfolgung zu dns.google [8.8.4.4]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms USG [192.168.1.1]
2 1 ms 1 ms 1 ms fritz.box [192.168.6.1]
3 23 ms 22 ms 22 ms #anderer Hop
4 22 ms 22 ms 32 ms #anderer Hop
5 29 ms 30 ms 29 ms #anderer Hop
6 30 ms 30 ms 29 ms #anderer Hop
7 29 ms 29 ms 30 ms #anderer Hop
8 31 ms 31 ms 31 ms #anderer Hop
9 31 ms 30 ms 30 ms dns.google [8.8.4.4]

Das Ergebnis sieht für mich erstmal gut aus. Ist damit auch schon sicher das NAT in der USG deaktiviert oder gibt es dafür noch einen andere Testmöglichkeit?

Danke und Gruß
Rainer

Antworten
1. Martin Ziegler sagt:
  
  28. Juni 2019 um 20:42 Uhr
  
  Hallo Rainer,
  
  ich bin mir nicht sicher, ob ich dich richtig verstehe. site_ID ist als Platzhalter für die Bezeichnung deiner Site/Zone zu verstehen. Die erste Site/Zone heißt default, weitere haben kryptische Namen. Wenn es in deinem Ordner sites keine Unterordner gibt und du selbst einen neuen manuell angelegt hast, bist du an der falschen Stelle gelandet.
  
  Wenn du prüfen willst, ob die Regel 5999 aus der json-Datei auf dem USG aktiv ist, kannst du dich per SSH am USG anmelden und mit diesem Befehl den Status von iptables anschauen:
  sudo iptables -t nat -L -n -v
  Beim Output sollte eine Zeile mit NAT-5999 dabei sein:
  ... Chain POSTROUTING (policy ACCEPT 808K packets, 62M bytes) pkts bytes target prot opt in out source destination 808K 62M UBNT_VPN_IPSEC_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 808K 62M MINIUPNPD-POSTROUTING all -- * * 0.0.0.0/0 0.0.0.0/0 808K 62M UBNT_PFOR_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 739K 57M RETURN all -- * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set corporate_network src /* NAT-6001 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set remote_user_vpn_network src /* NAT-6002 */ 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 match-set guest_network src /* NAT-6003 */ 69080 4630K VYATTA_PRE_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0 ...
  
  Gruß
  
  Martin
  
  Antworten
Hardy sagt:

28. Juni 2019 um 10:57 Uhr

Wieso habt ihr nicht einfach in der Fritzbox PPPoE-Passthrough aktiviert und die PPPOE Einwahl von der USG machen lassen…kein Doppeltes NAT und die Security Features sowie die volle Firewall Leistung der USG bleiben erhalten. Des weiteren funktioniert die Telefonie an der FB weiterhin. Ist nur ein Knopfdruck in der FritzBox und fertig 🙂 Wozu kauft man sich denn ein SecurityGateway wenn man doch bei der schnöden FritzBox bleibt? Da kann die USG auch gleich weg bleiben…ich betreibe meine FB nur als Modem und für die Telefonie…die pppoe Einwahl erfolgt über die USG-4-Pro. Somit bleiben alle Funktionen wie VPN / IPS usw. erhalten…die Routing-Tabellen im Netz funktionieren problemlos. Selbst IPTV ist mittels VLAN Tagging via WAN2 möglich.

Wer hier noch weiter gehen will kann ein 2. LAN Kabel aus dem Unifi Subnet zurück zur FB führen und versuchen sie als SIP Trunk einzurichten, dann könnte man den EDU SIP in der USG aktivieren und seine Telefone auch ins Netz der USG hauen…Vorausgesetzt man hat richtige VoIP Geräte und keine DECT Telefone.

Sollte die FB aufgrund der neuen Firmware kein PPPoE-Passthrough mehr unterstützen, hilft nur eine alte Firmware oder wieder der DrayTek als Modem und die FB hinter die USG. Einwahl dann auf DHCP stellen und ein Portforwarding ggf. mittels VLAN Tagging in der USG den weg für die SIP Einwahl der FB einrichten damit die TelefonAnlage weiterhin läuft. (nur Theorie habe ich selbst noch nicht versucht sollte aber funktionieren schließlich hat die USG ja 2 WAN Ports und das Modem meist ebenfalls mehr als einen falls ein eigenes VLAN für die Einwahl benötigt wird. Einige Provider machen das ja auch über öffentliche SIP Server die auch hinter einem NAT von der Fritzbox erreicht werden können)

Gruß

Hardy

Ubiquiti Enterprise Admin

Antworten
1. Martin Ziegler sagt:
  
  28. Juni 2019 um 21:04 Uhr
  
  Hallo Hardy,
  PPPoE ist auch eine gute Option. Das schöne bei IT ist, dass es verschiedene Ansätze gibt. Ich persönlich finde es einfacher jedes Gerät für sich zu betrachten und ganz “normal” zwischen den Netzen zu routen (deaktiviertes NAT auf dem USG). Auch hier stehen alle Vorteile der USG zum Schutz der Netze “hinter” der USG und zur Analyse der Daten zur Verfügung. Nur weil ich es einfacher finde, sagt das natürlich noch nichts darüber aus, ob es für andere auch die richtige Lösung ist.
  
  Eine alte Firmware für die FritzBox würde ich generell nicht empfehlen. Da die Option Angeschlossene Netzwerkgeräte dürfen zusätzlich ihre eigene Internetverbindung aufbauen (nicht empfohlen) bei der FritzBox 7490 v7.11 zur Auswahl steht, gibt es dafür – Stand heute – keinen Grund. Das Risiko sehe ich eher beim Provider: Telekom: Parallele Verbindungen am DSL-Anschluss.
  
  Mit welchen Provider hast du bisher mit der PPPoE-Lösung gute Erfahrung sammeln können? Eventuell hilft das dem einen oder anderen zu entscheiden welche Lösung die passende ist.
  
  Gruß
  
  Martin
  
  Antworten
  1. Hardy sagt:
    
    28. Juni 2019 um 21:20 Uhr
    
    Hi Martin,
    
    Ich finde ja nicht schlecht was ihr da macht. Wenn man damit aber täglich zu tun hat und auch mit Endkunden Erfahrungen sammelt, sind die einfachen Wege meist die besseren.
    
    Die Firmware der fritzbox spielt in meinem Beispiel keine Rolle da sie physisch nicht mit dem Internet verbunden ist. Die dhcp Funktion und auch die pppoe Einwahl der fritzbox sind deaktiviert. Nur die USG ist eingewählt.
    
    Mir stellt sich hier nur die Frage, wieso will ich denn zwischen beiden Netzen sauber Routen? Was hängt denn an der fritzbox denn dran? Oder was muss ich dort noch erreichen? Sie ist ja faktisch gesehen, nur noch ein modem mit tk Anlage. Wenn dein provider aber unbedingt eine internet Verbindung für die Telefonie braucht, kann sie auch hinter der usg hängen. Dann einfach die Einwahl von pppoe auf dhcp stellen und die notwendigen ports für die Telefonie für die fritzbox weiterleiten.
    
    Weil einfach, einfach, einfach ist 🙂
    
    Somit richte ich nur noch eine Freigabe für ein Gerät ein und muss nicht das gesamte NAT für alle clients umstricken.
    
    Ftth macht es möglich. Gute Erfahrungen habe ich mit 1&1 Versatel VDSL sowie Ftth der TCOM.
    
    Antworten
    1. Udo sagt:
      
      11. September 2019 um 16:30 Uhr
      
      Hi,
      
      bin noch ein bischen verwirrt, ob es nun besser ist die Fritzbox so zu lassen und NAT auf dem USG zu deaktivieren oder umgekehrt.
      Auf der Fritzbox nutze ich Telefonie, VPN und der DynDNS Service für die Fritzbox. Wen ich die Box jetzt auf PPoE passthrough setze, kann ich sie weiterhin für Telefonie nutzen (Dect) und die Softphone app auf den Smartphones sowie VPN?
      Die Box soll gleichzeitig Modem sein für die USG aber auch VPN und Telefonie zur Verfügung stellen. Für Fritz Dyndns, das ja so nicht mehr funktioniert, müsste ich mir eine andere Lösung einfallen lassen. D.h. aber auch das die Fritzbox eine IP aus dem lokalen Netz braucht. Wie funktioniert hier die Verkabelung? Muss ich vom Switch nochmal ein Kabel zurück zur Box legen?
      
      DHCP übernimmt im meinem Netz ein SBS2011, nutze allerdings nur die Mailfunktionalität des Servers. Trotzdem muss der Server als DHCP laufen. Deswegen sollen auch alle clients im selben IP Bereich des Servers stehen.
      
      DSL-> Fritzbox (Wan) -> Fritzbox Lan 1 -> USG Wan1 ->?
      
      Hintergrund für den Aufwand, ich will ein paar IoT Geräte einbinden in ein eigenes VLAN das eben durch die USG abgesichert ist (Wlan Geräte und Hardwired).
      
      Wen ich das so löse wie eben hier im Beitrag vorgeschlagen, bekommt die USG eine normale IP aus dem Bereich in dem die FritzBox liegt und spannt dahinter eigene Netze auf (in dem Fall ersteinmal nur für die IoT devices.
      
      Vom Gefühl her tendiere ich eher für die Lösung mit der Fritzbox als Modem und die USG erledigt die PPoE Einwahl (und bekommt damit die IP vom Provider). Damit könnte die USG sowohl das eigentliche Heimnetz als auch weitere VLAN schützen.
      
      Physisch gesehen hängt damit die Fritzbox sehr wohl im Internet (Wan ist mit der Gegenstelle der Telekom verbunden) nur die Einwahl wird nun von der USG erledigt.
      
      Antworten
      1. Martin Ziegler sagt:
        
        11. September 2019 um 22:46 Uhr
        
        Hallo Udo,
        zur Frage ob es “besser” ist
        
        “die Fritzbox so zu lassen und NAT auf dem USG zu deaktivieren” oder
        
        “NAT auf der FritzBox zu deaktivieren und das USG so zu lassen”
        
        Deine zweite Option funktioniert so nicht, außer du meintest mit “umgekehrt”, dass du PPPoE passthrough auf der Fritzbox aktivierst (oder ich habe dich komplett falsch verstanden). Du hast noch die Option NAT sowohl auf der FritzBox als auch im USG aktiviert zu lassen. Ob das Deaktivieren von NAT für dich einen Vorteil bringt, hängt davon ab, ob du hinter dem USG Geräte hast, die mit doppeltem NAT Probleme haben oder ob du aus dem Subnetz der Fritzbox auf Netze/Clients hinter dem USG direkt zugreifen möchtest (ohne Portforwarding). Da der Artikel nicht die PPPoE-Lösung beschreibt, möchte ich nicht allzu sehr darauf eingehen, um nicht zu weit vom Thema des Artikels abzuweichen. Vielleicht noch ein paar Anmerkungen zum DHCP: Du musst nicht alle Clients/IoT-Geräte im selben IP-Bereich haben (was du auch nicht vorhast?). SBS2011 kann die IPs im Subnetz der Fritzbox vergeben, wenn nötig. Das USG kann für weiter Netze/VLANs als DHCP Server agieren oder den SBS2011 als DHCP Relay nutzen. Der SBS kann auch in einem Netz hinter dem USG hängen und dort als DHCP aktiv sein.
        Wie schon in anderen Post geschrieben tendiere ich gefühlsmäßig nicht zur PPPoE-Lösung, was aber nichts über die Qualität der verschiedenen Lösungen aussagt. Wichtig ist, dass sie deine Anforderungen erfüllt und du dich im Störfall damit zurechtfindest. Ich habe bei mir die FritzBox “normal” am Laufen, damit ich alle Dienste der Box, wie zum Beispiel VPN, Telefonanalage, FAX, wireshark Netzwerktrace oder DynDNS nutzen kann. Im Netz der Fritzbox hängt nur das USG mit deaktiviertem NAT und aktiver Firewall. Hinter dem USG habe ich verschiedene Subnetzte/VLAN für verschiedene Anwendungszwecke, die untereinander und nach “außen” durch das USG abgesichert sind.
        
        Vom USG unterstützte DynDNS Dienste: afraid, dnspark, dslreports, dyndns, easydns, namecheap, noip, sitelutions und zoneedit.
        
        Hinweise von AVM zu PPPoE-Passthrough: https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/3232_PPPoE-Passthrough-in-FRITZ-Box-einrichten/
        
        Ich hoffe du kannst mit der Antwort etwas anfangen. Wenn ich einen dir wichtigen Aspekt übersehen habe oder dich nicht richtig verstanden habe, bitte nachfragen.
        
        Gruß Martin
        
        Antworten
      2. Hardy sagt:
        
        12. September 2019 um 11:56 Uhr
        
        Hi Udo,
        
        “Physisch gesehen hängt damit die Fritzbox sehr wohl im Internet (Wan ist mit der Gegenstelle der Telekom verbunden) nur die Einwahl wird nun von der USG erledigt.”
        
        Das ist schlichtweg Falsch, da die FB nur mit dem DSL Port des Anbieters verbunden ist. Es besteht keine WAN Verbindung / TCP/IP Verbindung in irgendeine Richtung. Nur die Modulation der Verbindungsrate wird ausgehandelt und aufgebaut. Die Geräte sprechen also nicht miteinander. Dafür sind die OSI-Layer und PVC Lines zuständig, solange also über z.B. PVC 1/32 keine Einwahldaten gesendet werden findet auch keine Kommunikation mit irgendeinem Server statt und die FritzBox ist über keine IP der Welt erreichbar, nicht einmal von der DSL Port Management Karte…die zeigt ggf eine Vendor ID die ausgelesen werden kann.
        
        Antworten
      3. Udo sagt:
        
        13. September 2019 um 16:39 Uhr
        
        Hi Martin,
        
        anscheinend ist die “Antwort” Funktion abhängig von der tiefe der Antworten, ich kann auf Deinen und Hardys Beitrag nicht mehr antworten.
        
        Deswegen nochmal auf diesem Weg.
        
        Mit Option 2 meinte ich tatsächlich PPoE auf die USG durchleiten und die USG übernimmt die Einwahl.
        
        Vorteil deiner im Artikel beschriebenen Lösung:
        
        + FritzBox bleibt Modem, Telefonanlage, übernimmt VPN und MyFritz (Dyndns)
        + Das Hauptnetz so wie es im Augenblick konfiguriert ist kann (fast) bleiben wie es ist.
        
        Neutral (nenne es mal nicht Nachteil)
        
        – ich verliere die Möglichkeit die FritzBox selber als AP zu nutzen, da ich in dem von der FB ausgeleuchteten Bereich auch IoT Geräte liegen (eigener IP Bereich eigene VLAN ID).
        – die USG kümmert sich lediglich um die Netze hinter der USG (und da bin ich mir nicht sicher auch wegen der Verkabelung ).
        
        So hast du verkabelt:
        FritzBox 7490 “DSL/TEL” -> TAE Dose/DSL-Anschluss
        FritzBox 7490 “LAN 1” -> USG “WAN 1”
        USG “LAN 1” -> Deine restliche Infrastruktur
        
        Würde ich jetzt auch so verkabeln.
        
        Als Infrastruktur nutze ich noch einen 24Port Unifi Switch an dem praktisch alle Geräte und AP hängen.
        
        Im Augenlick habe ich ein Hauptnetz 192.168.10.x (der gesamte Park an netzwerkfähigen Geräten) und ein Gast WLAN (Ip Adressbereich kenne ich im Augenlick nicht auswendig, auf jeden Fall mit VLAN 100 tag).
        
        Ziel wäre die IoT Geräte in ein eigenes Netz zu sperren ohne Zugang zum Internet:
        192.168.10.x weiterhin Hauptnetz
        Ip Adressbereich unbekannt -> weiterhin Gastzugang VLAN 100
        192.168.30.x -> nur für IoT ohne Internet Zugang eigener VLAN tag
        event. ein weiteres Netz für Streaming Boxen (will die nicht wirklich mit den IoT Geräten mischen da sie auch Internetzugang benötigen und in meinem Hauptnetz brauch ich sie auch nicht wirklich (streame nur aus dem Internet, habe keinen lokalen Content den ich über diese Boxen abrufen will).
        
        Die zweite Lösung mit PPoE durchreichen:
        
        Vorteil:
        
        – die komplette Netzwerkverwaltung liegt hinter der USG und kann damit gesichert werden auch das Hauptnetz (inklusive Monitoring).
        
        Neutral:
        
        – die Fritzbox verkommt zum Modem
        – kann Telefonie im vollem Umfang genutzt werden (Fax, Phone App)??
        – My Fritz geht nicht mehr -> Alternativen hast du bereits genannt.
        – VPN geht nicht, bin mir nicht sicher ob man VPN aus der USG weiterleiten kann (oder soll) oder direkt einen neuen Zugang auf der USG konfiguriert.
        – ich verliere die Möglichkeit die FritzBox selber als AP zu nutzen, da ich in dem von der FB ausgeleuchteten Bereich auch IoT Geräte liegen (eigener IP Bereich eigene VLAN ID).
        
        Für beide Scenarien muss ich mir noch einen weiteren UnifiAP anschaffen um den AP Funktion der FB zu ersetzen.
        
        Wie erwähnt kann mich nicht wirklich entscheiden was die einfachere Lösung ist (Konfiguration und Zukunftsicherheit).
        
        Btw, vielen Dank für diesen Beitrag -> toller Blog!
        
        @Hardy
        du hast natürlich Recht, mit “physisch” meinte ich natürlich auch physische Geräte.
        
        Gruß
        Udo
        
        Antworten
        
        Martin Ziegler sagt:
        
        13. September 2019 um 20:46 Uhr
        
        Hallo Udo,
        danke für den Hinweis mit den Kommentaren und die positive Rückmeldung zum Beitrag. Ich habe die erlaubten Ebenen für Antworten von 5 auf 10 angepasst, hoffe das hilft.
        
        Du hast die Lösungen schön gegenübergestellt. Bei Lösung 1, kannst du dein “Hauptnetz” auch hinter das USG hängen. Die FritzBox würde dann zu Beispiel 192.168.38.0 verwalten und hätte nur das USG als Gerät im eigenen Netz. Im USG würdest du ein VLAN (ohne TAG) für 192.168.10.0 auf die relevanten Ports der Switchs und das relevante WLAN konfigurieren. So sollte sich für deine Clients fast nichts ändern.
        
        Deine Anmerkung, dass das WLAN der FritzBox idealerweise deaktiviert wird, sehe ich auch so. Da ich zuerst mein Haus mit UniFi APs versorgt habe und mir später das USG zugelegt habe, hatte ich diesen Aspekt bisher nicht bedacht. Hier habe ich persönlich die Erfahrung gemacht, dass mehr UniFi Geräte mit “schwachen” Sendewerten im Haus besser sind als wenige mit “starken”. Die AVM WLAN Hardware, die ich vorher im Einsatz hatte, war da weniger problematisch.
        
        Ich vermute, die Entscheidung ist so “schwer” da alle drei Lösungen
        
        FritzBox als Router, USG mit aktivem NAT
        
        FritzBox als Router, USG ohne NAT als Router
        
        FritzBox als “Modem”, PPPoE, USG mit aktivem NAT
        
        ans Ziel führen. Ich hatte mit Lösung 1 gestartet und nachdem NAT bei mir Probleme gemacht hatte, auf Lösung 2 erweitert. Auf Lösung 3 bin ich erst durch Hardy aufmerksam geworden.
        
        Im Prinzip kannst du nichts falsch machen 😉
        
        Viel Erfolg
        
        Martin
        
        Antworten
        
        Carbonide sagt:
        
        13. September 2019 um 22:03 Uhr
        
        Da ich ja “neu” bin, habe ich mich für Lösung 3 entschieden, da sie mir am einfachsten zu implementieren schien.
        
        Worüber ich erstaunt bin bei dieser Lösung, ist der Umstand, dass meine VPN Konfiguration von der Fritzbox immer noch funktioniert. Ich werde aber später auch dies über das USG erledigen. Auch die DynDNS Konfiguration der Fritzbox benutze ich immer noch, da der USG es nicht erlaubt, einen beliebigen Anbieter zu konfigurieren.
        
        Danke für deinen Blog-Beitrag Martin, der mir den Impuls gab, die USG (die schon seit Wochen unbenutzt Staub ansammelte) endlich in Betrieb zu nehmen.
        
        Ist nett, wenn alles funktioniert 🙂
        
        Antworten
        
        Martin Ziegler sagt:
        
        14. September 2019 um 17:12 Uhr
        
        Hallo Carbonide,
        es freut mich, dass Harys Lösung für dich funktioniert. Mich erstaunt allerdings auch, dass das VPN der FritzBox noch funktioniert. Bei Lösung 3 sollte, soweit ich die Diskussion verstanden habe, die Fritzbox keine IP vom Provider mehr zugewiesen bekommen (durch falsch hinterlegte Zugangsdaten) und von daher auch nicht direkt vom Internet aus zu erreichen sein. Bist du dir sicher, dass deine Fritzbox keine eigene Verbindung parallel zum USG aufbaut? Technisch wäre das nicht wirklich schlimm. Abhängig vom Vertrag mit deinem Provider besteht jedoch die Möglichkeit, dass das zu zusätzlichen Kosten führen könnte.
        
        DynDNS mit der Fritzbox könnte auch bei Lösung 3 funktionieren. Sie bekommt eine IP aus einem Subnetz des USG und stellt über dieses als Default-Route die Aktualisierungsanfrage. Der DynDNS Dienst sieht die IP, die das USG vom Provider bekommen hat (und hinter der deine Netzte durch NAT versteckt sind) und aktualisiert den Eintrag. Zumindest in der Theorie – wie bereits erwähnt: Lösung 3 habe ich nicht im Einsatz..
        
        Gruß
        
        Martin
        
        Antworten
        
        Carbonide sagt:
        
        14. September 2019 um 17:31 Uhr
        
        Dass DynDNS funktioniert ist klar, der Service könnte ja auf einem beliebigen Gerät im internen Netz laufen (vor vielen, vielen Jahren hat das Mal ein Programm auf meinem Desktop-Rechner erledigt).
        
        Die Geschichte mit dem VPN hat mich daran erinnert, das man auch auf einigen NAS einen VPN-Dienst einrichten kann (so z. B. auf meiner Synology), ich habe das aber nie probiert, da ich von Anfang an die Fritzbox dazu benutzt habe. Schleierhaft ist mir aber auch hier, wie das funktionieren kann. Ich dachte, das müsste immer über den Router/Gateway (das 1. Gerät in der Kette) geregelt werden.
        
        Antworten
        
        Udo sagt:
        
        18. September 2019 um 14:07 Uhr
        
        Hi Martin,
        
        ich habe das jetzt mal so umgesetzt wie im Artikel beschrieben. Allerdings hat es einige Stunden gebraucht bis alles so funktioniert hat. Kleiner Verbesserungsvorschlage für deinen Artikel, schreib die Pfade in den Artikel und verlinke zu https://help.ubnt.com/hc/en-us/articles/115004872967.
        
        Nachdem das gelöst ware habe ich auch ein bischen gebraucht bis ich WinSCP daszu übereden konnte das file in dem entsprechenden Verzeichnis abzulgen. Da mein Controller auf einem Raspi läuft und ich normalerweise kein Rechte auf das Unifi Verzeichnis habe. Der Link hier hat mir weitergeholfen: https://www.serverraumgeschichten.de/2016/03/winscp-mit-sudo-nutzen/.
        
        Den Exchange Server konnte ich soweit mit doppelter Portweiterleitung auch wieder
        erreichbar machen (FritzBox zu USG und weiter zum Server).
        
        Auch VPN funktioniert, zumindest z.T. Vielleicht kannst du mir noch einen Tipp geben. Die VPN user landen jetzt im DHCP Bereich der Fritzbox und der USG (192.168.38.x). Ich komm von dort aber nicht mehr weiter auf das Hauptnetz 192.168.10.x. um dort Fernwartung zu machen. Mache ich hier einen Denkfehler?
        
        Gruß
        Udo
        
        Antworten
        
        Udo sagt:
        
        18. September 2019 um 14:22 Uhr
        
        Hi Martin,
        
        die Antwort steht im letzten Abschnitt deines Artikels, hab ich tatsächlich übersehen. Sorry. Kasst du auch einen IP Bereich freigeben der für die VPN user genutzt wird anstelle einer einzelnen IP? Ich kann vermutlich nicht sicherstellen das der gerade eingewählte User immer die selbe IP zugewiesen bekommt. Das funktionierte mal über das Fernzugangstool der FritzBox, da war es möglich jedem user seine eigene IP zuzuweisen. Über die Konfig der Fritz Oberfläche geht das aber nicht mehr und ich musst den DHCP dafür auf der Fritzbox wieder einschalten.
        
        Gruß
        Udo
        
        Antworten
        
        Martin Ziegler sagt:
        
        24. September 2019 um 7:21 Uhr
        
        Hallo Udo,
        habe die zweite Antwort übersehen. Du könntest dem ganzen Subnetz der Fritzbox den Zugriff in der USG Firewall erlauben (erleichtert auch die Portforwardings). Nach meiner Erfahrung bekommt jeder VPN-Nutzer immer die gleiche IP Adresse aus der Fritzbox – auch wenn er über die Oberfläche angelegt wurde.
        
        Gruß Martin
        
        Antworten
        
        Martin Ziegler sagt:
        
        24. September 2019 um 7:18 Uhr
        
        Hallo Udo,
        du musst, um vom VPN aus in dein Hauptnetz zu kommen, die Firewall im USG für die IP-Adressen der VPN Nutzer freischalten. Wenn du die Lösung aus dem Artikel nimmst, solltest du auch kein doppeltes Portforwarding benötigen. Nur eines von der Fritzbox hinter das USG und eine Firewallfreischaltung im USG. Das habe ich versucht im Abschitt “Zugriff vom FRITZ!Box Subnet durch das Security Gateway in die anderen Subnets freigeben” zu beschreiben. Passt das zu deinem Problem?
        
        Vielen Dank für den Artikel mit dem sudo-Tipp für WinSCP. Das habe ich bisher umständlicher gelöst. Werde ich gleich mal ausprobieren.
        
        Gruß
        
        Martin
        
        Antworten
2. Carbonide sagt:
  
  9. September 2019 um 0:01 Uhr
  
  Genügt es wirklich nur einfach diese eine Checkbox zu aktivieren und das war’s?
  
  Denn dann verstehe ich nicht den Aufwand der mit Methode 1 und 2 betrieben wird, wenn man genau die gleichen Vorteile mit Methode 3 hat.
  
  Welche IP müsste dann die Fritzbox haben?
  
  Antworten
  1. Martin Ziegler sagt:
    
    11. September 2019 um 22:04 Uhr
    
    Hallo Carbonide,
    auf welche Checkbox beziehst du dich? Da in den verschiedenen Posts, abhängig von der konkreten Frage, verschiedene Methoden vorgestellt wurden, gelingt es mir leider nicht, deine Frage zuzuordnen.
    
    Kannst du deine Frage mit Beispielen konkretisieren?
    
    Gruß Martin
    
    Antworten
    1. Carbonide sagt:
      
      12. September 2019 um 10:52 Uhr
      
      Ich beziehe mich auf Hardy’s Post vom 28. Juni 2019 (“Ist nur ein Knopfdruck in der FritzBox und fertig”).
      
      Da ich sehr zufrieden bin mit meinem aktuellen Setup bestehend aus diversen Ubiquiti UniFi Switches, APs und Kameras, möchte ich jetzt die Fritzbox so weit es geht zu einem simplen Modem degradieren und alle anderen Aufgaben durch ein USG Pro 4 ersetzen. Die Funktionen der Fritzbox, die ich aktuell noch benutze sind:
      
      – VPN Server
      – DynDNS Aktualisierung
      – DHCP Server
      – Telefoniefunktionen
      
      Die ersten beiden Funktionen sind wesentlich, die 3. wohl kein Problem für USG, und die letzte von weniger Bedeutung.
      
      Am liebsten würde ich alle Dienste durch das USG erledigen wollen, wenn eine sehr einfache Lösung aber die vorgenannten Dienste auf der Fritzbox lässt, könnte ich damit leben.
      
      Antworten
      1. Hardy sagt:
        
        12. September 2019 um 12:02 Uhr
        
        Hi Carbonide,
        
        korrekt! In der Fritzbox wird mit einem Knopfdruck die Interneteinwahl deaktiviert.
        Bitte darauf achten das die FB keine Zugangsdaten mehr gespeichert hat, da in den meisten fällen nur eine PPPoE Verbindung pro Anschluss aufgebaut werden kann.
        
        “https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/3232_PPPoE-Passthrough-in-FRITZ-Box-einrichten/”
        
        Danach in der USG in den WAN Settings die PPPoE Einrichtung durchführen.
        – VPN Server -> muss dann zwingen in der USG eingerichtet werden (was kein Problem ist, bei mir läuft ein Client VPN Netzwerk sowie 3 IKeV2 Dynamic Verbindungen in Microsoft Azure)
        – DynDNS Aktualisierung -> Einrichtung muss dann ebenfalls in der USG vorgenommen werden, da die Fritzbox dann keine Öffentliche IP mehr bekommt, da sie nur noch die DSL Verbindung aufbaut.
        – DHCP übernimmt dann? klar die USG dafür ist sie ja da!
        
        – Telefoniefunktionen -> hier kommt es jetzt wirklich auf den Anbieter an.
        Einige Anbieter setzen eine Internet Verbindung für den aufbau der VoIP Session voraus, da nur so der VoIP Server des
        Providers erreichbar ist (Resale Anschlüsse, dein Provider mietet einen Port bei der Tcom, somit kein Management des DSL Ports
        möglich und keine eigenen Routen zum VoIP Server realisierbar), andere nutzen dafür unterschiedliche VLAN’s (z.B. FTTH Tcom),
        dann gibt es noch die Bereitstellung über den DSLAM des Providers, ähnlich wie bei PPPoE entscheidet der Benutzername und die PVC Line welchen
        Weg die Session am DSLAM des Providers geht und das schlimmste kommt zum schluss “NGN ” die VoIP Session wird vom Provider
        via MAC Adresse der Bereitgestellten Hardware aufgebaut (Router baut Verbindung zum Server auf und Authentifiziert sich über
        die Hardware ID)
        
        Gruß
        
        Hardy
        
        Antworten
      2. Carbonide sagt:
        
        12. September 2019 um 13:48 Uhr
        
        Ich antworte hier, da ich komischerweise keinen Antworten-Knopf bei Hardys untenstehendem Post finden kann.
        
        Wie gesagt ist mir die Telefonie jetzt mal zweitrangig, die 3 mir wichtigen Funktionen scheinen ja keine Probleme zu bereiten.
        
        Aber was mir noch nicht klar ist, in deinem Link von AVM steht von zusätzlicher PPPoE Einwahl, ich will ja aber die der Fritzbox ganz abschalten und die USG dies erledigen lassen.
        
        Ausserdem hat die Fritzbox bei mir aktuell die IP 192.168.1.1, die, soweit ich weiss, zwingenderweise die USG haben muss. Welche IP sollte die Fritzbox denn jetzt bekommen? Muss man nicht auch unter Heimnetz > Netzwerk > Netzwerkeinstellungen [x] Client IP einstellen (ich weiss leider nicht ob auf deutsch da auch Client IP steht, da ich meine Fritzbox eben von französisch auf deutsch umgestellt habe, komischerweise aber auf dieser Seite die Texte der beiden Optionen immer noch auf französisch erscheinen, wahrscheinloch soll es Bridge Mode sein).
        
        Antworten
      3. Carbonide sagt:
        
        12. September 2019 um 13:49 Uhr
        
        Mit Fritzbox ganz abschalten, meine ich natürlich die Fritzbox-Einwahl.
        
        Antworten
      4. Hardy sagt:
        
        12. September 2019 um 14:01 Uhr
        
        Wenn du Passthrough in de FB aktivierst kann die USG eine einwahl durchführen, wenn du jetzt zusätlich in den FB Internet Settings die Daten löschst und oder einstellst dass sie keine Verbindung aufbauen sollst, haben wir was wir brauchen….
        
        USG kann sich einwählen
        FB versucht nicht sich einzuwählen 🙂
        
        Check?
        
        Antworten
      5. Hardy sagt:
        
        12. September 2019 um 14:02 Uhr
        
        sollst = soll
        
        Antworten
      6. Hardy sagt:
        
        12. September 2019 um 14:15 Uhr
        
        “Ausserdem hat die Fritzbox bei mir aktuell die IP 192.168.1.1, die, soweit ich weiss, zwingenderweise die USG haben muss. Welche IP sollte die Fritzbox denn jetzt bekommen? Muss man nicht auch unter Heimnetz > Netzwerk > Netzwerkeinstellungen [x] Client IP einstellen (ich weiss leider nicht ob auf deutsch da auch Client IP steht, da ich meine Fritzbox eben von französisch auf deutsch umgestellt habe, komischerweise aber auf dieser Seite die Texte der beiden Optionen immer noch auf französisch erscheinen, wahrscheinloch soll es Bridge Mode sein).”
        
        Die USG und die FB können auch die gleiche IP haben. Die USG interessiert das netz davor nicht, da sie eine PPPoE Anfrage schickt und eine Öffentliche IP bekommt.
        
        Du kannst auch gerne in der FB den DHCP Server deaktivieren und sie komplett in den BridgedMode befördern. Der USG ist das egal da eine Wan PPPoE einwahl nicht auf TCPIP eben erfolgt. Wenn die USG eine PPPoE Einwahl macht, kommst du auch nicht mehr in das Subnet der FB, dass geht nur im DHCP mode, dann müssen die Subnetze aber auch zwingend unterschiedlich sein.
        
        Antworten
      7. Carbonide sagt:
        
        12. September 2019 um 14:44 Uhr
        
        Ich dachte bisher immer, dass 2 identische IP Adressen in einem Netz nicht möglich wären, oder nur Probleme bereiten würden.
        
        Sind folgende Schritte korrekt, um die USG in mein Heimnetz einzubinden:
        
        1. Fritzbox LAN Kabel auf USG WAN1
        2. USG WAN1 auf Switch anstelle der Fritzbox
        3. PPPoE Passthrough auf der Fritzbox aktivieren
        4. PPPoE Einwahl in der USG einrichten (eventuell in der Fritzbox ganz abschalten, was passiert wenn beide Geräte sich gleichzeitig einwählen?)
        
        und das war’s schon um wieder einen funktionierenden Internetzugang zu haben ohne doppeltes NAT? Den Rest (VPN, DHCP, DynDNS, Telefonie) würde zu einem späteren Zeitpunkt erfolgen.
        
        Ich entschuldige mich für meine langtatmige Fragerei, aber dies ist alles neu für mich.
        
        Antworten
      8. Hardy sagt:
        
        12. September 2019 um 14:53 Uhr
        
        Fritzbox LAN1 auf USG WAN1 -> USG LAN1 auf Switch…fertig
        
        Für die Änderungen in der FB musst du dann den Rechner an der FB an LAN2/3/4 anschließen.
        Änderungen im Unifi Netz gehen dann nur am UnifiSwitch
        
        “PPPoE Einwahl in der USG einrichten (eventuell in der Fritzbox ganz abschalten, was passiert wenn beide Geräte sich gleichzeitig einwählen?)”
        wird nicht funktionieren, da der Provider meist nur eine Einwahl zulässt..demnach bekommt das gerät eine IP welches am schnellsten versucht hat die Verbindung herzustellen
        
        Und ja das reicht, da es kein doppel NAT geben kann. Es gibt dann 2 von einander getrennte netze.
        
        Antworten
      9. Carbonide sagt:
        
        12. September 2019 um 15:03 Uhr
        
        Ah, das ist also der Nachteil dieser Lösung: möchte ich auf die Fritzbox zugreifen (da diese hin und wieder mal die DSL Synchronisation verliert und ich nachschauen möchte, ob dies der Grund für den ausgefallenen Internetzugang ist) muss ich umstöpseln.
        
        Ich muss mir überlegen welche Lösung mir lieber ist.
        
        Vielen Dank für deine Hilfe!
        
        Antworten
      10. Hardy sagt:
        
        12. September 2019 um 16:25 Uhr
        
        Na ja, es geht auch anders…^^
        Verkabelung so lassen…DHCP in FB deaktivieren…ihr eine Feste IP im gleichen Netz wie der USG geben (bitte darauf achten das sie nicht schon von einem anderen Gerät verwendet wird)…dann ein kabel von FB LAN2 auf Unifi Switch…und schon ist die FB über die Fest eingetragene IP auch im Unifi Netz erreichbar, wie jeder andere client auch…aber wir schweifen hier gerade etwas ab oder?
        
        Alternativ kann man ja auch nen Debug WLAN der Fb laufen lassen…dann kann man mal auf die FB wechseln und gucken was los ist…
        
        Vllt ist es aber auch besser die Synchronisierung’s Probleme zu beheben ^^
        
        Antworten
        
        Tobias sagt:
        
        13. Oktober 2019 um 23:01 Uhr
        
        Guten Abend,
        
        dieses Setup ist genau das, was ich im Kopf hatte.
        
        FB -> USG -> Switch wobei in der FB PPPoE einwahl für anderen Geräte erlaubt ist
        
        FB Lan2 auf Switch
        
        Würde hier auch ein Telefon funktionieren was an einem TAE Anschluss der FB hängt?
        
        Grüße Tobias
        
        Antworten
        
        Martin Ziegler sagt:
        
        15. Oktober 2019 um 7:32 Uhr
        
        Hallo Tobias,
        
        ich habe bei mir die Lösung ohne PPPoE im Einsatz. Hier funktioniert die Telefonanlage in der FritzBox wie gewohnt. Bei einer Lösung, in der die FritzBox die Internetverbindung über PPPoE weitergibt und gleichzeitig als IP-Client “hinter” dem USG (das die Interneteinwahl macht) hängt, liegen die theoretischen Probleme aber “nur” darin den VoIP Client der FritzBox (und eventuell NAT/Portforwarding in dem USG) so zu konfigurieren, dass er eine stabile Verbindung zu deinem Provider aufbaut und eingehende Anrufe entgegen nimmt. Wenn das klapp, funktionieren auch alle analogen, ISDN oder DECT Telefone wie gewohnt.
        Etwas anderes wäre es, wenn du noch einen klassischen Telefonanschluss ohne VoIP (also analog oder ISDN hättest). Das wäre komplett unabhängig von der PPPoE Konfiguration.
        
        Gruß
        
        Martin
        
        Antworten
      11. Carbonide sagt:
        
        13. September 2019 um 17:19 Uhr
        
        Da waren noch so einige Hürden zu nehmen, aber irgendwie hab ich’s geschafft 🙂 es funktioniert, besten Dank nochmals!
        
        Antworten
3. Siegmar sagt:
  
  9. Januar 2020 um 19:00 Uhr
  
  Hallo Hardy,
  
  Deine Lösung gefällt mir sehr gut, habe jedoch einige Schwierigkeiten bei der Umsetzung.
  Mein Szenario:
  
  FB 6490 Cable (Vodafone) mit fester öffentlicher IP (wird aber auch über DHCP zugewiesen)
  Seit einem der letzten Firmware Updates seitens Vodafone gibt es die Möglichkeit, die LAN-Ports 2-4 zu bridgen. Ich habe dies testweise auf LAN2 durchgeführt mit dem Ergebnis, dass ich an diesem Port die gleiche öffentliche IP wie die FB selbst erhalten habe. Logischerweise bin ich dann an diesem Port nicht ins Internet gekommen. Habe hierzu heute mit dem Business Support von Vodafone telefoniert und einen ziemlich arroganten MA erwischt. Dieser sagte mir klip und klar, dass das Bridging nicht supportet wird. Ist mir nur unklar, warum dann diese Funktion bereitgestellt wird.
  Kann es sein, dass dies mit meiner Option “Feste IP-Adresse” zusammenhängt und ich deshalb keine 2te virtuelle IP zugewiesen bekomme?
  Ich kann leider auch nicht auf die Telefoniefunktionen der FB verzichten und ein zusätzliches Modem möchte ich auch nicht installieren. Allerdings begeistern mich die UNIFI-Geräte und speziell das USG.
  Muss ich jetzt doch auf die alternativen Lösungen (NAT deaktivieren, Exposed Host) zurückgreifen?
  
  Viele Grüße
  Siegmar
  
  Antworten
Rainer sagt:

29. Juni 2019 um 9:35 Uhr

Hallo Martin,

ich dachte fälschlicherweise, dass „site_ID“ ein erforderliches Verzeichnis ist und hatte es daher manuell erstellt. Das Verzeichnis „default“ (bei mir derzeit einzige Site) existiert natürlich.

Die “config.gateway.json” in „default“ – provisioniert – und NAT ist bei mir deaktiviert.
Iptables mit SSH geprüft und die Zeile mit NAT-5999 ist vorhanden. Funktioniert wunderbar.
Gegenprobe durchgeführt “config.gateway.json” aus default-Verzeichnis gelöscht – provisioniert – und NAT ist wieder aktiv, keine NAT-5999 Zeile mehr in den iptables vorhanden.

Sorry für die doppelte Frage nach Funktionstest – hattest Du schon ein paar Kommentare weiter oben erklärt.

Gruß
Rainer

Antworten
1. Martin Ziegler sagt:
  
  29. Juni 2019 um 20:42 Uhr
  
  Hallo Rainer,
  
  kein Problem, du kannst gerne Fragen. Aufgrund der verschiedenen Kommentare kann es recht schwer sein, die passende Antwort zu finden. Da die meisten Kommentare recht aktuell sind, erinnere ich mich noch an das was ich geschrieben habe und durch das Wiederholen von hilfreichen Antworten, finden andere Leser hoffentlich schneller was sie benötigen.
  
  Noch eine Anmerkung zum Test mit tracert: hier habe ich mit Christian getestet, ob die Reihenfolge der Hops stimmt. Aus dem Test kannst du jedoch nicht schließen ob NAT deaktiviert ist. Dafür müsstest du aus dem Netz deiner FritzBox auf einen Rechner “hinter” der USG pingen/prüfen. Das funktioniert jedoch erst, wenn du die Firewall im USG entsprechend öffnest. Da hier zwei potentielle Fehlerquellen dazu führen können, dass es unter Umständen nicht wie erwartet funktioniert (NAT ist noch aktiv oder die USG Firewall blockiert), teste ich lieber mit iptables auf dem USG.
  
  Gruß
  
  Martin
  
  Antworten
Rainer sagt:

2. Juli 2019 um 8:52 Uhr

Hallo Martin,

danke für die Erklärungen.

Ich teste gerade verschiedene Wege ein klassisches Heimnetzwerk (eine FB 7490 mit ein paar Clients, Drucker und WLAN, DECT) auf Komponenten von UniFi/Draytek umzustellen, beziehungsweise zu erweitern.

Dabei ist mir der Weg mit Draytek Vigor 165, Unifi USG, UniFi-Switch, UniFi AP in den Sinn gekommen. Grundsätzlich funktioniert das auch, aber nicht gerade trivial. Bei ein paar Punkten bin ich auch nicht glücklich. Dazu zählen DDNS, hier kann man im UniFi-Controller nur aus wenigen Providern auswählen und keine benutzerdefinierten Eingaben vornehmen. Dann Probleme bei VPN. Ich möchte eine dauerhafte VPN-Verbindung zwischen zwei Netzwerken (Standorte) einrichten, die bisher über Fritz-Boxen realisiert wird. Das habe ich nicht hinbekommen. Das Thema Port-Weiterleitung habe ich erst gar nicht mehr ausprobiert.

Aufgrund der genannten Probleme habe ich mir überlegt, die FB vorgeschaltet zu lassen und dahinter nur die UniFi-Komponenten einzurichten. So bin ich bei der Suche, wie man das NAT auf der USG deaktivieren kann, auf Deine Seite gestoßen… 🙂

Gruß
Rainer

Antworten
1. Marcel sagt:
  
  20. August 2019 um 11:54 Uhr
  
  Genau das versuche ich auch gerade , bis zum Externen Interface der gegenseite kann ich pingen , zur Fritzbox jedoh nicht . auch nicht mit den Einstellungen hier .
  
  Antworten
  1. Martin Ziegler sagt:
    
    20. August 2019 um 21:40 Uhr
    
    Hallo,
    wenn du deinen Aufbau (welche Subnetze hast du konfiguriert? welche Komponenten setz du ein? hat es schon mal funktioniert? wenn ja, nach welcher Änderung hat es aufgehört zu laufen?) genauer beschreibst, kann ich versuchen dir bei der Fehlersuche zu helfen. Manchmal ist es nur eine Kleinigkeit in der Konfiguration, die nicht passt.
    
    Gruß
    Martin
    
    Antworten
Jochen sagt:

23. August 2019 um 9:24 Uhr

Hallo zusammen,

zuerst mal vielen Dank für diese top Anleitung und die Mühe die Du Dir gemacht hast.
Ich muss aber trotzdem noch eine Frage stellen, vielleicht habe ich es auch einfach falsch verstanden.

Ich habe alles nach Anleitung umgesetzt. Auch wird NAT-5999 angezeigt (heißt, doppeltes NAT ist deaktiviert, richtig?). Dennoch muss ich jede Portforwarding Regel die ich in der FB erstellt habe im USG ebenfalls erstellen, da ich ansonsten nicht auf meine NAS zugreifen kann.

Habe ich nun einen Knoten im Kopf und schmeiße unterschiedliche Dinge zusammen, oder funktioniert es bei mir nicht richtig?

Vielen Dank und Grüße
Jochen

Antworten
1. Martin Ziegler sagt:
  
  23. August 2019 um 17:01 Uhr
  
  Hallo Jochen,
  vielen Dank für deine Rückmeldung. Zu deinen Fragen:
  wenn die Regel 5999 auf deinem USG angezeigt wird, führt das USG kein NAT mehr durch. Die nächste Stelle auf dem Weg ins Internet, an dem wieder NAT passieren könnte, ist die FritzBox. Wenn du Pech hast (oder einen DSL-Light-Tarif) führt dein Provider in seinem Netz nochmal NAT durch, wenn er sparsam mit öffentlichen IP-Adressen umgehen möchte. Im Prinzip macht es das was du willst, also ein “ja” auch deine Frage.
  Das du zusätzliche Regeln im USG anlegen musst, ist ungewöhnlich.
  Ein Netzwerkgerät hat in der Regel (Ausnahmen gibt es immer, gehen wir aber mal davon aus, dass es stimmt) für jedes Netzwerkinterface eine Regel, die besagt, dass Pakete, die an Zieladressen im Subnetz des Interface gehen, über dieses Interface das Gerät verlassen. Zusätzlich gibt es noch eine “default” Route, an die alle IP-Pakete gehen, die in Netze sollen, die nicht direkt an dem jeweiligen Netzwerkgerät hängen.
  Das ist alles schwer ohne Bild zu beschreiben, ich versuche schon einige Zeit ein aussagekräftiges zu erstellen, aber bisher leider ohne Erfolg. Vielleicht hilft dir das hier weiter:
  
  Achtung: Das Bild ist ein Rohentwurf und kann Fehler enthalten.
  
  Was zur Beantwortung deiner Frage noch wichtig ist: In welchem Netz hängt dein NAS und welche IP hat es?
  
  Hoff es hilft dir weiter.
  
  Gruß
  
  Martin
  
  Antworten
  1. Jochen Voß sagt:
    
    23. August 2019 um 17:43 Uhr
    
    Hallo Martin,
    vielen Dank. Ich glaube ich habe verstanden. Meine Konfig sieht wie folgt aus:
    
    unitymedia zur Fritzbox
    Netz: 10.10.10.0
    
    Fritzbox zum USG
    Netz: 10.10.10.0 auf 192.168.1.0
    
    NAS im Netz 192.168.1.0 an einem managed switch (akt. keine konfigurierten Regeln)
    
    Auf der FB sind Regeln angelegt um die NAS über gewisse Ports aus dem Internet erreichbar zu machen.
    
    Diese Regeln musste ich nun auf dem USG ebenfalls anlegen. D.h. 1x existieren die forwarding Regeln auf der FB und ebenfalls auf dem USG.
    
    -5999 wird dennoch angezeigt.
    
    Muss ich vielleicht auf dem USG separate fw Regeln anlegen?
    
    Ich dachte das mit dem ausschalten des NAT die Regeln nicht doppelt angelegt werden müssen.
    
    Grüße Jochen
    
    Antworten
    1. Martin Ziegler sagt:
      
      23. August 2019 um 18:25 Uhr
      
      Hi,
      wenn ich dich richtig verstehe:
      
      FritzBox verwaltet 10.10.10.0/24
      
      USG verwaltet 192.168.1.0/24
      
      NAS hängt an Switch hinter der USG im Netz 192.168.1.0/24
      
      Wenn du vom Netz 10.10.10.0 (zum Beispiel per VPN oder eben per FritzBox Port-Forwarding) auf dein NAS hinter dem USG zugreifen willst, musst du im USG die Firewall anpassen. Ohne Anpassungen lässt sie nur Pakete zu Verbindungen zu, die initial aus dem Netz 192.168.1.0/24 (in deiner Konfiguration) kommen.
      Das Unifi Security Gateway schützt alle Netze “hinter” sich (aus Sicht Internet). Du musst den Zugriff gezielt erlauben. Routen muss du keine setzen. Ich habe das im Abschnitt Zugriff vom FRITZ!Box Subnet durch das Security Gateway in die anderen Subnets freigeben versucht zu beschreiben.
      
      Gruß
      Martin
      
      Antworten
      1. Jochen Voß sagt:
        
        23. August 2019 um 18:38 Uhr
        
        Hallo Martin,
        alles klar, verstanden. Vielen Dank. Dann liegt es sicher daran, dass ich die FW durch die Portforwarding Regeln umgehe.
        Ich suche mir Deinen threat gleich mal raus und richte die fw ein.
        Gibt es eigentlich Nachteile dadurch das wir nat auf dem USG ausgeschaltet haben?
        
        Liebe Grüße
        -Jochen
        
        Antworten
        
        Martin Ziegler sagt:
        
        24. August 2019 um 10:25 Uhr
        
        Hallo Jochen,
        wenn du die Firewall des USG durch Portforwarding umgehst, terminiert das Forwarding von der FritzBox auf dem USG anstelle deines NAS? Da die FritzBox dein NAS nicht direkt “sieht”, steht es dir im Portforwarding der Fritzbox nicht als Ziel zur Auswahl und du musst die IP-Adresse des Ziels (in deinem Fall dein NAS, nicht das USG) für die Weiterleitung (nicht das Routing) manuell in der FritzBox eingeben.
        
        Für deinen Anwendungsfall (Zugriff aus dem Internet auf ein Gerät in deinem LAN) hast du durch deaktivieren des NAT keinen direkten Vorteil. Du kannst es entweder durch Portforwarding, Routing und Firewallfreigaben ohne NAT oder mit mehrfachem Portforwarding mit NAT lösen. Der Vorteil entsteht beim Zugriff von deinem LAN ins Internet mit Geräten/Diensten, die bei doppeltem NAT nicht in vollem Umfang oder nicht optimal zur Verfügung stehen (zum Beispiel Spielkonsolen). Ein Nachteil ist, dass du in deiner UniFi Infrastruktur “manuelle” Änderungen vornimmst. Sie könnten durch ein Update oder eine Anpassung der verwendeten Komponenten irgendwann nicht mehr unterstützt sein. Zusätzlich musst du dich zur Konfiguration etwas mit “Netzwerken” beschäftigen – ob das ein Vor- oder Nachteil ist, sieht jeder etwas verschieden…
        
        Anstelle einer direkten Freigabe deines NAS, steht dir auch die Möglichkeit offen, eine VPN Verbindung zu deiner FritzBox zu nutzen um auf dein NAS mobil zuzugreifen – das reduziert deine “Angriffsfläche” etwas. Erschwert jedoch den eventuell gewünschten Zugriff von dritten auf dein NAS.
        
        Gruß
        
        Martin
        
        Antworten
Marc sagt:

23. September 2019 um 18:38 Uhr

Hallo Martin,
erstmal vielen Dank für die tolle Anleitung!

Ich bin aktuell etwas verzweifelt da ich den korrekten Pfad nicht finden kann. Ich habe einen Raspberry mit dem Controller laufen. Auf der Seite https://help.ubnt.com/hc/en-us/articles/115004872967 wird ja für Debian/Ubuntu Linux folgender Pfad zur angegeben: /usr/lib/unifi . Sowohl unter dem Pfad /var/lib/unifi/ (hier gibt es kein data) als auch /usr/lib/unifi/data gibt es bei mir keine Sites… .

Grundsätzlich scheint es mit den Rechten auf dem Raspi etwas schwieriger zu sein, hierzu habe ich folgenden Artikel gefunden: https://www.agmedia.de/index.php/de/technik-ecke/zugriff-auf-modem-hinter-usg-router

“”Beim Raspberry PI als Controller einfach mit WIN-SCP die angepasste config.gateway.json ins Homeverzeichnis (/home/pi/) kopieren und dann mit Putty auf dem PI einloggen. Mit den folgenden Schritten wird die Datei dann ins richtige Verzeichins kopiert. Das Unifi-Verzeichnis ist gesperrt, also als Superuser arbeiten.””

Wohin nun mit der config.gateway.json ??

Vielen Dank für eure Hilfe!
Marc

Antworten
1. Martin Ziegler sagt:
  
  24. September 2019 um 7:32 Uhr
  
  Hallo Marc,
  /usr/lib/unifi/data könnte ein symbolischer Link nach /srv/unifi/data sein. Wenn du ganz sicher gehen willst, kannst du dich als “root” mit SSH an deinem Server anmelden (oder per sudo werden) und mit dem Befehl “find / -name firmware.json” nach einer Datei suchen, die im data-Verzeichnis liegen sollte. Hier sollte dann ein Ordner sites existieren in dem dann normalerweise default der richtige Ordner für config.gateway.json ist.
  
  Gruß Martin
  
  Antworten
  1. Marc sagt:
    
    24. September 2019 um 9:28 Uhr
    
    Hallo Martin,
    danke für die schnelle Antwort. Ich habe mich als pi mit sudo su angemeldet, eine firmware.json finde ich nur unter /var/lib/unifi/ . In diesem Ordner gibt es allerdings nur die Ordner backup, db, keystore und die Dateien firmware.json, system.properties und system.properties.bk.
    
    Der einzige Ort wo ich /data/defaults/ finden kann ist unter /usr/lib/unifi/webapps/ROOT/app-unifi/data/defaults. In diesem Ordner befinden sich 2 Dateien: dashboard-common-modules.json und dashboard-default-modules.json. Aber ich denke hier bin ich wohl auch nicht richtig 🙁
    
    Ich habe den Controller mit der Version 5.11.39.0 nach dieser Anleitung mit dem Skript ohne pi-hole installiert: https://community.ui.com/questions/Step-By-Step-Tutorial-Guide-Raspberry-Pi-with-UniFi-Controller-and-Pi-hole-from-scratch-headless/e8a24143-bfb8-4a61-973d-0b55320101dc
    
    Bin relativer Linux Neuling aber lernfähig, danke für die Geduld und ich freue mich über weitere Unterstützung!
    
    Viele Grüße
    Marc
    
    Antworten
    1. Martin Ziegler sagt:
      
      26. September 2019 um 21:29 Uhr
      
      Hallo Marc,
      warst du schon am UniFi Controller angemeldet und hast eine Site/Zone konfiguriert?
      
      Beim Cloud Key liegt die Konfiguration hier: /usr/lib/unifi/data/sites/default
      Der Ordner “default” ohne “s” und nicht unter “data” sondern unter “sites”.
      
      Gruß Martin
      
      Antworten
      1. Marc sagt:
        
        28. September 2019 um 9:30 Uhr
        
        Hallo Martin,
        das “s” bei default ist mir rausgerutscht, natürlich default 🙂 Aber wie gesagt, der einzige Ort an dem ich als pi user mit sudo su eine firmware.json finde ist /var/lib/unifi und hier gibt es außer backup, db und keystore keine weiteren Ordner.
        
        Eine Site mit 5 Vlan´s ist konfiguriert, 3AP´s, USG und ein Unifi 24Port Switch sind soweit eingerichtet und funktionieren klaglos.
        
        Bin ich denn der einzige User der den Controller auf einem Raspi laufen hat? Vieleicht sollte ich doch das Geld für den Cloud Kex investieren… 🙁
        
        Viele Grüße
        Marc
        
        Antworten
        
        Martin Ziegler sagt:
        
        29. September 2019 um 12:21 Uhr
        
        Hallo Marc,
        der CloudKey (Gen 1) ist auch “nur” ein kleiner Server mit ARMv7 Processor und 2 GB RAM auf Basis Debian 8.11 (jessie). Der Ordner “/usr/lib/unifi” ist der richtige -Ordner (UniFi – Where is ?). Die Ordner backup, db und keystore sollten jedoch nicht direkt in diesem Ordner liegen, sondern in einem Unterordner data (eventuell ein symbolischer Link auf einen anderen Ordner, wie zum Beispiel /srv/unifi/data). Parallel zu diesen Ordnern sollte in data der sites Ordner liegen.
        root@UniFi-CloudKey:/usr/lib/unifi/data# ls -al total 160 drwxr-x--- 8 unifi unifi 4096 Sep 26 21:44 . drwxr-xr-x 5 root root 4096 Dec 21 2018 .. drwxr-x--- 3 unifi unifi 4096 Sep 28 21:47 backup drwxr-x--- 7 unifi unifi 4096 Sep 28 21:55 db drwxr-x--- 3 unifi unifi 4096 Jun 15 08:11 firmware -rw-r----- 1 unifi unifi 120353 Sep 28 21:46 firmware.json lrwxrwxrwx 1 unifi unifi 35 Dec 21 2018 keystore -> /etc/ssl/private/unifi.keystore.jks drwxr-x--- 4 unifi unifi 4096 Jun 21 22:31 sites -rw-r----- 1 unifi unifi 0 Dec 21 2018 system.configured -rw-r----- 1 unifi unifi 1383 Sep 26 21:44 system.properties -rw-r----- 1 unifi unifi 1383 Sep 26 21:44 system.properties.bk drwxr-x--- 3 unifi unifi 4096 Sep 26 21:44 tmp drwxr-x--- 3 unifi unifi 4096 Dec 21 2018 webrtc
        
        Gruß Martin
        
        Antworten
        
        Roland sagt:
        
        25. November 2019 um 12:37 Uhr
        
        Hallo, auch ich nutze seit paar Wochen Unifi. Mein Controller läuft auch auf einem pi. Auch ich finde das Verzeichnis Sites nicht. Ich habe es halt manuell angelegt, aber die config Datei wird wohl nicht beachtet. Habe parallel auf Ubuntu den Controller installiert. Auch dort finde ich das Verzeichnis sites nicht. Ich nutze die aktuellste Version des Controllers…. ich hoffe ich finde in dem Forum Hilfe….
        
        Grüße
        
        Antworten
        
        Martin Ziegler sagt:
        
        26. November 2019 um 20:31 Uhr
        
        Hallo Roland,
        ich habe den Controller zum Testen auf einem Ubuntu Server installiert und kann bestätigen, dass das “sites”-Verzeichnis mit seinen individuellen Unterverzeichnissen pro Site nicht angelegt ist. Wenn du die Verzeichnisse nicht manuell anlegen willst, kannst du alternativ für jede deiner Sites bei den Einstellungen unter Gaststeuerung die Optionen Gastportal aktivieren und Vorlagen mit eigenen Anpassungen überschreiben anklicken und die Änderungen übernehmen. Dadurch werden die Verzeichnisse angelegt und bleiben auch bestehen, wenn du die Optionen wieder deaktivierst. Das manuelle Anlegen sollte auch funktionieren, du kannst die automatisch erstellten Verzeichnisse mit deinen vergleichen – eventuell fällt dir eine Abweichung auf.
        
        Ich hoffe das hilft dir weiter.
        
        Grüße
        Martin
        
        Antworten
        
        Roland sagt:
        
        27. November 2019 um 7:32 Uhr
        
        Hallo Martin,
        vielen Dank! die Seiten wurden tatsächlich angelegt. Ich werde versuchen die Config Datei entsprechend abzulegen und dann den Gastportal wieder deaktivieren. Wie ist es denn auf den anderen Systemen (Windows, Mac) wird dort das Verzeichnis automatisch angelegt oder muss auch die Option Gastportal aktiviert werden?
        
        Grüße
        Roland
        
        Antworten
        
        Martin Ziegler sagt:
        
        29. November 2019 um 7:27 Uhr
        
        Hallo Roland,
        freut mich, dass es klappt. Bisher bin ich davon ausgegangen, dass das Verzeichnis immer da sei, da es bei mir noch nie gefehlt hatte. Ich habe mir meine Installationen nochmal angeschaut. In allen Unterverzeichnissen für die jeweiligen Sites liegt bei mir neben der Datei config.gateway.json ein Verzeichnis map. Da ich NAT bisher immer in bereits bestehenden und etwas gereiften Installationen deaktiviert habe, vermute ich, dass andere Aktionen auch dazu führen, dass die notwendige Verzeichnisstruktur angelegt wird. Je mehr ein Benutzer mit seiner Installation und den möglichen Einstellungen und Übersichtsseiten im UniFi-Controller experimentiert hat, umso größer schätze ich die Chance ein, dass er kein Problem mit nicht vorhandenen Sites-Verzeichnissen hat.
        
        Gruß
        Martin
        
        Antworten
Daniel sagt:

26. September 2019 um 13:24 Uhr

Guten Tag,

wir haben auch eine Fritzbox (Kabel, Unitymedia) und dahinter USG etc. etc. etc.
Mir scheint es manchmal so (Zugriff von außen) sehr langsam zu sein.
Hängt das mit diesen Doppelten NAT zusammen?
Eigentlich hatte ich die Fritzbox (komme aktuell nicht auf die Fritzbox weil komplett andere IP etc, und bisher nicht geschaft mir da das zu routen, drauf) auf Bridge MOdues und Exposed Host gestellt. Ich bekomme auf jedenfall eine öffentliche IP an den USG was eigentlich heißt kein doppel NAT oder?

Danke für den tollen Artikel!

Antworten
1. Martin Ziegler sagt:
  
  26. September 2019 um 21:38 Uhr
  
  Hallo Daniel,
  wenn du eine öffentliche IP an deinem USG hast, sollte nur einmal NAT (auf dem USG) durchgeführt werden. Doppeltes NAT führt zu Problemen, wenn du direkte Verbindungen mit anderen Endgeräten im Internet aufbauen willst (zum Beispiel: Online Spiele mit PC/Konsole). Dass der Zugriff (von außen) manchmal sehr langsam wirkt, ist keine typische Begleiterscheinung von doppeltem NAT. Eher von einer ausgelasteten Verbindung. Hast du den Speedtest auf dem UniFi Controller regelmäßig laufen? Hier solltest du zumindest erkennen können, ob deine Internet Verbindung manchmal “gefühlt” oder “richtig” langsam ist.
  
  Gruß Martin
  
  Antworten
Jürgen sagt:

28. September 2019 um 22:49 Uhr

Hallo Martin,
ich bin Dank Deiner Anleitung einen großen Schritt weitergekommen bei der Umsetzung DSL -> Fritzbox -> USG.
——
RETURN all — * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */
MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set corporate_network src /* NAT-6001 */
MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set remote_user_vpn_network src /* NAT-6002 */
MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set guest_network src /* NAT-6003 */
—–
Die statischen Routen habe ich in der Fritzbox auch eingetragen.
Nur komme ich nicht mehr von den Geräten die über WLAN (UniFi AP-AC-Lite) angebunden sind ins Internet.
Intern funktioniert alles (z.B iPhone -> Synologybox , zwei verschiedene VLANs) . Auch ein “Ping” vom iPhone auf die FritzBox funktioniert.
Hast Du eine Idee wo hier der Fehler ist?
Danke!
Gruß
Jürgen

Antworten
1. Martin Ziegler sagt:
  
  29. September 2019 um 12:28 Uhr
  Hallo Jürgen,
  welche IP-Netze (und Adressen) verwendest du
  - zwischen FritzBox und USG
  - “hinter” dem USG
  und wohin zeigen die Default- und statischen Routen deiner Endgeräte, des USG und der FritzBox?
  
  Die Informationen könnten helfen die Ursache einzugrenzen.
  
  Gruß
  Martin
  Antworten
Jürgen sagt:

29. September 2019 um 20:57 Uhr

Hallo Martin,

Die Adressen “hinter” der USG sind von “LAN” 192.168.1.0/24 bis 192.168.15.0/24 (einzelne VLANs)
Das Netz zwischen FritzBox und der USG hat die 192.168.20.0/24
FritzBox = 192.168.20.1
USG = 192.168.20.2
Routing: z.B. 192.168.2.0 / 255.255.255.0 / 192.168.20.2

Für die FritzBox und der USG selbst habe ich keine Routen eingetragen.

Noch als Hinweis:
Es betrifft ja auch nur die WLAN-Netze, die “kabelgebundenen” Rechner kommen in Internet.

Gruß
Jürgen

Antworten
Jürgen sagt:

5. Oktober 2019 um 19:18 Uhr

Hallo Martin,
mein “Problem” ist gelöst.
Ich habe meine Adressvergabe noch einmal komplett neu aufgesetzt, danach hat es funktioniert.

Danke!

Gruß
Jürgen

Antworten
1. Martin Ziegler sagt:
  
  9. Oktober 2019 um 21:39 Uhr
  
  Hallo Jürgen,
  
  das freut mich – außer einem nicht hilfreichen “eigentlich sollte es funktionieren” hätte ich aus der Ferne wenig beitragen können.
  
  Gruß
  
  Martin
  
  Antworten
2. Markus sagt:
  
  10. Januar 2020 um 17:11 Uhr
  
  Hi,
  
  was genau hast du gemacht…
  Ich habe den gleichen Effekt.
  
  NAT auf USG (192.168.1.1) deaktiviert und Route auf FB (192.168.178.1) eingrichtet.
  192.168.1.0 => 255.255.255.0 => 192.168.178.20 <= IP des USG
  
  IPTables Eintrag ist auch vorhanden.
  4460 422K RETURN all — * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */
  
  Leider haben dann die CLients teilweise keinen connect mehr
  
  Gruß
  Markus
  
  Antworten
3. vitala sagt:
  
  10. Mai 2020 um 22:24 Uhr
  
  Hi,
  
  kannst du evtl. was du mit Adressvergabe neu Aufgesetzt hast meinst?
  
  Ich habe das gleiche Problem, LAN geht, über die APs per WLAN funktioniert es nicht.
  
  Antworten
Thomas sagt:

1. November 2019 um 22:00 Uhr

Hallo,

Vielen Dank für den Bericht und all die Kommentare, dies hat mich schon sehr weiter gebracht.

Mein Setup sieht wie folgt aus: Fritzbox USG Unifi Switch Unifi AP / Cloud Key
Ich habe auf der USG noch ein Port Forwarding eingerichtet (Port 111), die mich auf einen Server (192.168.1.11 Port 80) weiterleitet im hinter dem USG. Das Ziel ist es, dass ich ubnt.fritz.box:111 eingeben kann dann auf dem Server lande.

–>Wenn ich mich zum Wireless von der Fritzbox einwähle, komme ich mit ubnt.fritz.box:111 auf meinen Server.
–>Wenn ich mich nun aber via VPN auf meine Fritzbox einwähle, funktioniert es nicht.

Hat mir jemand einen Tipp, an was dies liegen kann.

Vielen Dank im Voraus für jegliche Hilfe.
Thomas

Antworten
1. Martin Ziegler sagt:
  
  2. November 2019 um 7:29 Uhr
  Hallo Thomas,
  wenn ich dich richtig verstehe, hast du sowohl bei der FritzBox als auch dem USG NAT aktiv?
  Wie verhält sich der VPN Client,
  - wenn du anstelle des DNS Namens (ubnt.fritz.box) die IP-Adresse verwendest (um auszuschließen, dass es ein DNS Problem ist),
  - wenn du per VPN andere Geräte in dem Netz der FritzBox ansprichst?
  Gruß
  Martin
  Antworten
  1. Thomas sagt:
    
    3. November 2019 um 7:56 Uhr
    
    Hi Martin,
    
    Vielen Dank für Dein Feedback.
    
    Nein, ich habe das NAT ausgeschaltet auf dem USG, wie im Blog beschrieben.
    
    Wenn ich im FritzBox Netzt bin, ist es egal ob ich ubnt.fritz.box:111 oder 192.168.10.10:111 verwende, beides funktioniert. Und wenn ich via VPN rein komme, funktioniert beides NICHT. (und vom FritzBox netz, kann ich kein Device ansprechen das hinter der USG ist)
    
    Wenn ich im VPN bin, kann ich auf die FritzBox oberfläche zugreifen via IP oder fritz.box. Sonst hat es keine Devices in diesem Netz ausser der USG.
    
    Gruss
    Thomas
    
    Antworten
    1. Martin Ziegler sagt:
      
      6. November 2019 um 6:42 Uhr
      
      Hallo Thomas,
      wenn das USG kein NAT macht, musst du kein Portforwarding einrichten. Es reicht, wenn du den Zugriff auf den Rechner hinter dem USG in der USG-Firewall freigibst. Ansprechen würdest du den Zielrechner mit seiner normalen Adresse. Deine Variante sollte aber auch gehen. Welche IP Subnetze hast du
      
      hinter der USG,
      
      hinter der FritzBox (192.168.10.0) und
      
      in dem Netz von dem du aus das VPN zur FritzBox aufbaust
      
      verwendet?
      
      Gruß Martin
      
      Antworten
      1. Thomas sagt:
        
        8. November 2019 um 17:03 Uhr
        
        Hi Martin,
        
        Vielen Dank für Dein Feedback.
        Ich konnte das Problem nun Lösen. Es war ein Konfigurationsproblem auf der Fritzbox.
        
        Nochmals vielen Dank für den Blog und den Super Support.
        Gruss
        Thomas
        
        Antworten
Stübi sagt:

5. November 2019 um 19:50 Uhr

Super Und ausführliche Beschreibung! Muss die config.Gateway.joson auf dem UniFi Controller und nicht USG abgelegt werden? Wie führe ich für den UniFi Controller eine Provisionierung durch und wie kann ich sehen, daß der USG die config Datei berücksichtigt. D.h. NAT disabled ist?
VG

Antworten
1. Martin Ziegler sagt:
  
  6. November 2019 um 6:56 Uhr
  Hallo Thorsten,
  - Ja, die config.gateway.json (Schreibweise relevant!) gehört auf den UniFi Controller.
  - Die Provisionierung muss auf dem Controller für das USG gestartet werden (nicht für den Controller).
  - Am UniFi Controller anmelden
  - USG auswählen
  - Konfiguration
  - Gerät verwalten
  - Provisionieren
  - Zum Prüfen, ob NAT deaktiviert wurde, kannst du dich an dem USG per SSH anmelden und mit sudo iptables -t nat -L -n -v nach der Regel NAT-5999 suchen (Details in meiner Antwort vom 28. Juni 2019 um 20:42 Uhr an Rainer).
  Gruß Martin
  Antworten
Sven sagt:

28. November 2019 um 21:56 Uhr

Hallo zusammen,

super Anleitung hier!! Leider verhält sich bei mir irgendwie einiges anders als hier beschrieben.

Zum Setup:
Standard DSL100 von Vodafone
TAE Dose -> Fritzbox 7590 (LAN1) -> USG (WAN)
USG (LAN1) -> Zyxel Switch (managed) -> Unifi APs und div. andere Devices
Alle Endgeräte erhalten ihre IP über DHCP.
USG und APs sind in den Controller sauber eingebunden der auf einem raspberrypi3 läuft.

Netze:
Fritzbox 192.168.178.0/24 – DHCP aktiviert
USG 192.168.1.0/24 – DHCP aktiviert
Stat. Route auf FB eingerichtet damit das Netz 192.168.1.0/24 via VPN erreichbar ist

Das Netz läuft soweit, die Endgeräte können ins Inet und untereinander reden.
Nun möchte ich Doppel-NAT vermeiden, daher habe ich die /usr/lib/unifi/data/sites/default/config.gateway.json erstellt und die USG erneut provisioniert.

Nun, kann ich von den Endgeräten aus nicht mehr ins Internet !?!
root@raspberrypi3:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 USG (192.168.1.1) 0.606 ms * *
2 fritz.box (192.168.178.1) 1.668 ms 2.094 ms 2.439 ms
3 * * *
4 * * *
….

Auf dem USG funktioniert der traceroute interessanterweise weiterhin:
root@USG:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 fritz-nas.box (192.168.178.1) 0.883 ms 0.374 ms 0.329 ms
2 #################.pools.vodafone-ip.de (##########) 5.537 ms 4.915 ms 4.928 ms
…

Sobald ich nun die config.gateway.json nach /tmp schiebe und erneut provisioniere, funktioniert die Kommunikation wieder und die Endgeräte können ins Internet.

Jetzt wirds noch seltsamer:
NAT auf USG ist aktiv, andernfalls würde folgender Befehl eine Zeile ausspucken, richtig?
root@USG:~# iptables -t nat -L -n -v |grep 5999

Netzwerk Check auf der PS4:
NAT Typ-2

Und Typ-2 bedeutet wenn ich das hier richtig lese, dass kein Doppel-NAT vorliegt ….
Ich bin ein wenig ratlos warum bei mir scheinbar Doppel-NAT nicht vorliegt, bzw. warum die Internet Verbindung unterbrochen wird sobald das NATting auf der USG deaktiviert wird.

Ergibt das für die Experten hier einen Sinn?

Viele Grüße, Sven

Antworten
1. Martin Ziegler sagt:
  
  30. November 2019 um 10:57 Uhr
  
  Hallo Sven,
  
  wenn ich dich richtig verstehe, hattest du in der FritzBox bereits eine statische Route definiert, bevor du NAT im USG deaktiviert hattest? Die statische Route dient in der Anleitung nicht für den Zugriff über VPN (das müsste bei Problemen in der Firewall des USG konfiguriert werden), sondern, dass die FritzBox weiß, an welche IP (die des USG im Netz der FritzBox, bei dir 192.168.178.?) es die Pakete der Netze “hinter” dem USG schicken soll (bei dir 192.168.168.1.0/24).
  
  Hast du in der Firewall des USG oder bei der UPnP Konfiguration Änderungen vorgenommen? Wenn die PS4 auch bei doppeltem NAT “zufrieden” ist, deutete es darauf hin, dass die relevanten Ports sauber geforwared werden und “von außen” erreichbar sind.
  
  Zu deiner Frage zu “iptables -t nat -L -n -v |grep 5999” – ja, wenn NAT wie in der Anleitung beschrieben deaktiviert wurde, würde eine Zeile zurück geliefert.
  
  Ich würde als erstes die Routen- und Firewall-Konfigurationen prüfen. Hoffe du findest die Ursache, wenn dir noch etwas merkwürdig vorkommt, einfach fragen.
  
  Gruß
  
  Martin
  
  Antworten
  1. Sven Merten sagt:
    
    30. November 2019 um 14:44 Uhr
    
    Hi Martin,
    
    danke für die Richtigstellung bzgl. der Route auf der FB. Ich hatte die Route bereits erstellt bevor ich mit dem NATting auf dem USG angefangen habe. Die USG hat auf der WAN Seite (eth0) die IP 192.168.178.100 und LAN seitig (eth1) 192.168.1.1.
    Ich habe das Thema i.d. Zwischenzeit etwas runtergebrochen und einen offiziellen Thread dazu aufgemacht, der hier zu finden ist. https://community.ui.com/questions/USG-no-internet-access-when-NAT-is-disabled/2f2602d5-78d6-4d6e-8aa2-033075eb056e
    
    In Kurzform, sobald ich die relevante NAT Regel 6001 deaktiviere wird die Internet Verbindung für die Endgeräte unterbrochen. Interessanterweise kann die USG selbst weiterhin Dienste wie Google DNS etc. erreichen. Sobald ich eine Provisionierung über den Controller forciere wird die USG Config überschrieben und damit ist die Regel 6001 wieder aktiv und alle Endgeräte können wieder ins Internet.
    
    Leider verstehe ich nicht welche Änderungen sich noch implizit ergeben wenn die NAT Regel 6001 deaktiviert wird. Es scheint auf jeden Fall nicht nur die Address-Translation zu sein …
    
    Bin für jeden Tipp dankbar!
    
    Gruss Sven
    Leider bekomme ich das Problem mit meinem bescheidenen Netzwerk Kentnissen nicht in den Griff.
    
    Antworten
    1. Martin Ziegler sagt:
      
      8. Dezember 2019 um 17:52 Uhr
      
      Hallo Sven,
      
      ich habe mir eben den von dir verlinkten Eintrag zum Ubiquiti-Supportforum angeschaut. Da dich gestern jemand wieder auf den Blog hier zurückverwiesen hat, gehe ich davon aus, dass im Supportforum nicht mehr viel ergänzt wird. Eine der Antworten im Supportforum ging um die Frage ob – oder warum – NAT im USG deaktiviert werden soll. Wenn du keine Probleme hast, brauchst du das nicht zu machen. Es gibt aber einige Anwendungen, die doppeltes NAT nicht mögen. Neben doppeltem NAT (“Auslieferzustand”) und der im Blogartikel beschrieben Lösung (“normales routen”), hat Hardy in den Kommentaren einen weiteren Lösungsansatz (“PPPoE passthrough”) beschrieben. Einen “exposed host” brauchst du in keinem der Lösungsansätze.
      
      Was mir nicht ganz klar ist, ist wie du die NAT Regeln “deaktiviert” hast. Hast du, wie hier im Blog beschrieben, mit der Regel 5999 das Netzwerkdevice eth0 generell vom Masquerading ausgenommen oder, wie in deiner Anfrage im Ubiquiti-Supportforum beschrieben nur die NAT-Regel 6001 deaktiviert?
      
      Gruß Martin
      
      Antworten
      1. Sven Merten sagt:
        
        14. Dezember 2019 um 9:33 Uhr
        
        Hi Martin,
        
        über die cli des usg kann man einzelne Regeln deaktivieren/löschen oder sich einfach den Status anschauen.
        
        Für Versuchszwecke hatte ich die rule 6001 gelöscht, nach dem “force provision” ist sie dann wieder vorhanden.
        
        admin@USG:~$ configure
        [edit]
        admin@USG# delete service nat rule 6001
        [edit]
        admin@USG# commit
        [edit]
        admin@USG# save
        Saving configuration to ‘/config/config.boot’…
        Done
        [edit]
        admin@USG# exit
        
        Das eigentliche Problem habe ich bisher dennoch nicht abstellen können, fälschlicherweise dachte ich bereits es mit “exposed host” gelöst zu haben. Also alles zurück auf Anfang. Das Netz wurde i.d.Zwischenzeit um 3 VLAN erweitert.
        
        LAN 192.168.1.0/24 (Corporate – Mgmt)
        VLAN10 10.10.0.0/24 (Corporate – Trusted)
        VLAN10 10.20.0.0/24 (Corporate – IoT)
        VLAN10 10.30.0.0/24 (Corporate – Guest)
        
        Statische Routen wurde auf der FB nachgetragen für die 10er Netze.
        Wenn ich NAT deaktiviere auf der USG (per json File, Regel ist aktiv), dann können Endgeräte im 192.168.1.0 Netz weiterhin 8.8.8.8 anpingen. Endgeräte aus einem der 10er Netze erreichen google nicht mehr. Ein traceroute sieht wie folgt aus:
        
        root@raspberrypi3:~# traceroute 8.8.8.8
        traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
        1 10.10.0.1 (10.10.0.1) 0.577 ms 0.639 ms 0.763 ms
        2 192.168.178.1 (192.168.178.1) 1.965 ms 2.465 ms 2.912 ms
        3 * * *
        …. ab hier kommen nur noch ****
        
        Um das weiter eingrenzen zu können wäre ich Dir dankbar wenn Du mir die ein oder andere Frage beantworten könntest.
        1) Nutzt Du neben dem default LAN auf der USG weitere VLANs (Corporate, oder VLAN only)?
        2) Wenn ja, hast Du auch weitere statische Routen auf der FB dafür eingerichtet?
        3) Wie sehen die bei Dir aus?
        4) Ist es wichtig, wann diese erzeugt werden, also erst NAT deaktivieren und dann statische Route?
        5) Hast Du auf USG Seite irgendwelche extra DNS/DHCP Anpassungen gemacht?
        
        Ich frage mich halt was mit den DNS Requests passiert, wenn ich aus dem 10er Netz ins 192.168.1.0 Netz (also die USG LAN Adresse) hoppe und von dort dann über USG WAN IP und Fritzbox ins Internet. Findet NATting zwischen den 10er und 192.168.1.0 Netzen statt oder wie funktioniert das übersetzen der Adressen intern? Wenn ja, dann könnte das erklären warum ich aus dem 10er Netz nicht weiterkomme, sobald NAT deaktiviert ist ….
        
        Gruss Sven
        Ich habe auf jeden Fall eine steile Lernkurve :).
        
        Gruss Sven
        
        Antworten
        
        Martin Ziegler sagt:
        
        14. Dezember 2019 um 18:21 Uhr
        
        Hallo Sven,
        
        vielen Dank für das Eingrenzen der Fragen 😉
        
        1) Nutzt Du neben dem Default-LAN auf der USG weitere VLANs (Corporate, oder VLAN only)?
        Ja. Alle sind entweder Corporate/Unternehmen oder Guest/Gast. Eines mit aktiver “Präfix-Delegierung” für IPv6.
        2) Wenn ja, hast Du auch weitere statische Routen auf der FB dafür eingerichtet?
        Ja, für jedes Netz eine eigene Route
        3) Wie sehen die bei Dir aus?
        Netzwerk: das jeweilige Netzwerk hinter dem USG. (Bei 24-Bit-Netzmaske ist es die Adresse mit der Null am Ende)
        Subnetzmaske: 255.255.255.0
        Gateway: IP des USG im Netz der FritzBox.
        4) Ist es wichtig, wann diese erzeugt werden, also erst NAT deaktivieren und dann statische Route?
        Nein. Solange du einen Client direkt im Netz der FritzBox hast, kannst du sie auch nachträglich konfigurieren.
        5) Hast Du auf USG Seite irgendwelche extra DNS/DHCP Anpassungen gemacht?
        Ja, ich nutze in einigen der Netze hinter dem USG die erweiterten DHCP-Optionen “DHCP NTP-Server” und “DHCP Netzwerk Boot”. Hat aber nichts mit dem Deaktivieren des doppelten NAT zu tun.
        
        Zum Testen würde ich nicht die Regel 6001 entfernen, sondern die Regel 5999 wie im Artikel beschrieben auf dem USG konfigurieren. Das, in Kombination mit den statischen Routen, sollte das gewünschte Verhalten erreichen. Zur Sicherheit kannst du auch deine FritzBox und dein USG zurücksetzen. Für den Fall, dass du noch Konfigurationen alter Versuche aktiv hast.
        
        Wenn du genau wissen willst, wie deine Pakete aussehen, die über die Fritzbox laufen, lohnt ein Blick auf http://fritz.box/html/capture.html in Verbindung mit Wireshark.
        
        Gruß
        
        Martin
        
        Antworten
Felix sagt:

7. Dezember 2019 um 23:51 Uhr

Guten Abend,

ich bin dieser Anleitung gefolgt und sehr dankbar für diese Möglichkeit. Leider ist es bei mir so, dass sobald ich die Datei hochlade und das USG provisioniere der Zugang zum Internet gekappt wird.
Meine Fritzbox liegt auf 192.168.178.1 und mein USG WAN auf 192.168.178.3. Auf der anderen Seite gibt es das Subnetz mit 192.168.108.1.
Nun habe ich eine statische Route auf der Fritzbox nach der Anletiung eingerichtet und die Datei hochgeladen.
Das interessante ist, dass meine USG weiterhin der Meinung ist sie wäre im Internet. Das steht zumindest dran, wenn ich mich direkt bei 192.168.108.1 anmelde.
Die Fritzbox kann jedoch auch nicht mehr erreicht werden.
Der tracert Befehl schlägt fehl.
Die Fritzbox selbst ist aber online. Über sie kann man ganz normal ins Internet.

Hat jemand eine Idee?

Gruß

Felix

Antworten
1. Martin Ziegler sagt:
  
  8. Dezember 2019 um 18:06 Uhr
  Hallo Felix,
  
  um sicher zu gehen, dass ich dich richtig verstanden habe.
  
  Netzwerkkonfiguration:
  - FritzBox: 192.168.178.1
  - USG WAN: 192.168.178.3
  - USG LAN: 192.168.108.1
  - Subnetz “hinter” der USG: 192.168.108.0/24
  Statische Route in FritzBox:
  - Netzwerk: 192.168.108.0
  - Subnetzmaske: 255.255.255.0
  - Gateway: 192.168.178.3
  Dass deine FritzBox noch ins Internet kommt (und alle Geräte im 192.168.178.0/24 Netz) ist schon mal eine gute Sache. Auch, dass dein USG noch “online” ist, ist zu erwarten, da das USG einen direkten Zugang zum Netz 192.168.178.0/24 über sein WAN-Device hat und die FritzBox (192.168.178.1) seine Default-Route ist. Dass die Geräte im Netz 192.168.108.0/24 nur noch aufs USG kommen, deutet auf ein Problem im Routing hin. Ich vermute, entweder ist die Route von der FritzBox nicht korrekt eingerichtet oder die Endgeräte hinter der USG haben die falsche Default-Route (192.168.0.1). Kannst du die statische Route in der FritzBox nochmal prüfen?
  
  Gruß
  Martin
  Antworten
  1. Felix sagt:
    
    9. Dezember 2019 um 1:44 Uhr
    
    Hallo Martin,
    
    du hast alles richtig verstanden. Und so wie es aussieht hast du mir auch direkt die Lösung präsentiert. Vermutlich werden sich hier jetzt einige an den Kopf fassen aber ich hatte das so:
    
    FritzBox: 192.168.178.2
    USG WAN: 192.168.178.3
    USG LAN: 192.168.108.1
    Subnetz “hinter” der USG: 192.168.108.0/24
    
    Soweit so klar. Nur das Subnetz hinter der USG habe ich bis jetzt immer mit 192.168.108.1/24 angegeben. Also auch in der USG direkt. Mir ist der Unterschied aus Sicht der Fritzbox auch immer noch nicht klar. Es gibt die Adresse 192.168.108.0 doch gar nicht da mein Subnetz 192.168.108.1/24 ist.
    
    Zwar kann ich abschließend nicht wirklich sagen, ob ich das NAT ausgeschaltet habe (* NAT-5999 */ erscheint), aber es funktioniert nun mit der 192.168.108.0 als Route für die Fritzbox. Ich komme ins Internet und an die Fritzbox und das obwohl ich die json hochgeladen habe.
    
    Ich habe einmal mehr hier eine Menge gelernt. Ganz herzlichen Dank für deinen Artikel und auch deine schnelle Hilfe. Ich bin mir sicher, dass diese Seite unabhängig, ob nun die PPPoE Variante oder deine genutzt wird, einigen Leute weitergeholfen hat. Danke für die Mühe die du dir machst dein Wissen zu teilen und sogar noch zu helfen! Auch danke an die anderen Beitragenden, vor allem Harvey, da sie deinen Artikel sinnvoll ergänzen.
    
    Ich mach mich mal weiter ans recherchieren. Nun muss ich verstehen warum ein Windowsrechner eine komplett fremde IP bekommt, wie die Firewall des USGs funktioniert und wie ich meine NAS wieder zum Laufen bringe. Nicht zu vergessen die Überlegung am Ende, ob es das alles wert war ;-).
    Guten Start in die neue Woche.
    
    Grüße
    Felix
    
    Antworten
    1. Martin Ziegler sagt:
      
      9. Dezember 2019 um 20:38 Uhr
      
      Hallo Felix,
      
      es freut mich, dass du einen Schritt weiter gekommen bist. Wenn du die statische Route in der Fritzbox hinterlegt hast, musst du mit der JSON-Datei das NAT deaktivieren (NAT-regel 5999) – passt also alles zusammen.
      Eine kleine Anmerkung zu den Bezeichnungen von IPv4-Adressen und IPv4-Netzen. 192.168.108.1/24 meint so viel wie:
      
      die IP-Adresse 192.168.108.1
      
      mit der Subnetzmaske 255.255.255.255.0 (24 Bit)
      
      [=> 24 Bit für Netze und 8 Bit für Endgeräte, 254 nutzbare IP-Adressen]
      
      aus dem Subnetz 192.168.108.0
      
      mit der Broadcastadresse 192.168.108.255 und
      
      den IP-Adressen 192.168.108.1 bis 192.168.108.254
      
      Ins Blaue geraten: Wenn der Windowsrechner eine IP aus dem Netz 169.254.0.0/16 bekommt, hat er keinen DHCP Server im Netz.
      
      Gruß
      
      Martin
      
      Antworten
      1. Felix sagt:
        
        9. Dezember 2019 um 21:47 Uhr
        
        Hallo Martin,
        
        beides konnte ich auch in Erfahrung bringen. Vermutlich hätte ich einfach auf deine Antwort warten müssen ;-).
        
        Das mit dem fehlenden DHCP-Server war irgendwie auch klar. Nur warum ist mir nicht klar. Problem ist behoben indem ich dem PC eine fixe IP aus dem Subnetz 192.168.108.0 zugewiesen habe. Aber der DHCP-Server in Form der USG war eigentlich die ganze Zeit da. Anschluss erfolgte die ganze Zeit über LAN.
        
        Ich auf der Suche nach der Frage warum eigentlich genau die 169.254.0.0/16 aber auf die Möglichkeit aufmerksam geworden der localdomain einen Namen geben zu können und so per “Namen” auch die Clients anzusprechen zu können.
        Das ist das tolle an dieser Materie: So viele Möglichkeiten, so viel zum Probieren.
        
        Danke nochmal für deine Hilfe.
        
        Viele Grüße
        Felix
        
        Antworten
        
        Felix sagt:
        
        9. Dezember 2019 um 22:51 Uhr
        
        Ich muss doch noch mal eine Frage nachreichen.
        
        Ich habe nun versucht Freigaben in der Fritzbox für die USG zu erstellen. So wie gewohnt gebe ich also zum Beispiel den 5786 für mein NAS frei. Bestätige ich das Ganze bekomme ich dann von der Fritzbox einen komplett anderen Port präsentiert. Wird dieser von der USG vorgegeben oder wie kommt es zu der Portänderung? Und wie kann ich so durch einen DDNS-Dienst meine NAS erreichen?
        Ich meine mich hier gelesen zu haben, dass sich bei der Version das NAT auszuschalten sich Anpassungen an der Firewall des USGs erübrigen und es bei der Fritzbox bleibt. Ist das korrekt oder bin ich auf dem kompletten Holzweg?
        
        Gruß
        Felix
        
        Antworten
        
        Felix sagt:
        
        9. Dezember 2019 um 23:16 Uhr
        
        Ich nochmal.
        
        Der letzte Beitrag war tatsächlich ziemlich, ähm, nennen wir es unqualifiziert.
        Natürlich muss in der USG der Port eingetragen, woher soll sie es wissen?
        Und die komsichen Ports in der Fritzbox kommen, wenn man die alten Freigaben mit den gleichen Ports – so wie ich- nicht richtig löscht. Also löschen und dan nochmal Übernehmen.
        
        Nun gehts, wie es soll.
        Vielleicht willst du, Martin, einfach beide Beiträge löschen :-).
        
        Viele Grüße
        
        Felix
        
        Antworten
        
        Martin Ziegler sagt:
        
        10. Dezember 2019 um 7:36 Uhr
        
        Hallo Felix,
        wenn es dich nicht stört, würde ich deine Frage inklusive deiner Antwort gerne so stehen lassen. Andere hatten bereits das gleiche Problem wie du und hoffentlich hilft deine Erklärung dem einen oder anderen in der Zukunft sein Problem zu analysieren.
        P.S. unqualifiziert finde ich deine Frage nicht. Gerade bei größeren Installationen mit vielen Subnetzen und verschiedenen Firewalls steht man im Fehlerfall öfter vor dem Problem, dass nicht ganz klar ist, wo und warum Pakete verloren gehen. Mir hilft es hier ein Schaubild zu zeichnen (was als Dokumentation eigentlich immer vorliegen sollte). Spätestens wenn du jemand das Bild und den Datenfluss erklärst, findest du in der Regel die Ursache für das unerwartete Verhalten.
        
        Gruß
        Martin
        
        Antworten
        
        Felix sagt:
        
        10. Dezember 2019 um 18:32 Uhr
        
        Hallo Martin,
        
        wenn du glaubst, dass es jemandem hilft kannst du es gerne einfach stehen lassen.
        
        Bei dem Bild muss ich dir Recht geben. Ich habe das nach deiner gestrigen Anmerkung und der Erinnerung sowas hier bereits gesehen zu haben ebenfalls in Angriff genommen und die Dinge werden so tatsächlich etwas verständlicher. Vor allem aber wird das in ein paar Monaten sehr nützlich sein, wenn man nicht mehr in allem komplett drinsteckt.
        
        Grüße
        Felix
        
        Antworten
xsas sagt:

13. Dezember 2019 um 9:06 Uhr

Hallo Martin,

erstmal Danke für die Anleitung – bin mir aber nicht sicher wie ich das bei mir Umsetzen muss:

Hab mir jetzt alles durchgelesen – aber ein paar offene Fragen bleiben:

Mein Setup sieht wie folgt aus:

Telekom Hybrid Router (IP 192.168.100.1) (degradiert als reiner Zugang zum INET – kein DHCP oder sonstiges -> nur DynDNS ist aktiv
[ja leider geht da dann nix mit Modem sonst wäre es ja auch einfach]

>> dahinter sitzt die Fritzbox (192.168.100.2 || IP-Client-Mode ) (diese macht nur VOIP/DECT Telefonanlage)
[diese Kombination ist konfiguriert nach Anleitung von https://lubensky.de/hybrid/ das heißt der Hybrid leitet die SIP/VOIP Ports an die Fritzbox weiter so das sie das Telefonzeug übernehmen kann]

>> dahinter kommt dann alles andere (inkl. Unifi APs / PiHole (192.168.100.4) der DHCP Server macht / VPN Server [dafür gibt es eine Portweiterleitung im Hybrid]

Ich würde jetzt wie folgt vorgehen :

Fritzbox LAN2 >> USG WAN (192.168.100.3)

USG LAN (192.168.200.1) >> Switch

Macht das Sinn oder muss ich´s anders machen ? (double NAT ist hier leider nicht anders Möglich da der Hybrid kein Modem darstellen kann)

Somit muss ich ja an der Konfigurationskombination Hybrid&Fritzbox nichts ändern – Voip/Dect Zeug sollte somit weiter funktionieren.

Aber wo muss ich jetzt welche Portweiterleitung einrichten für mein VPN Server der jetzt hinter dem USG hängt ? Und da PiHole seine IP als DNS verteilt welche IP muss er dann als Gateway fürs Inet verteile- steig noch nicht ganz durch

Oder ist alles murks und ich muss es anders machen oder kann es besser machen ?

Vielen Dank vorab

Antworten
1. Martin Ziegler sagt:
  
  14. Dezember 2019 um 17:51 Uhr
  Hallo xsas,
  
  die Hybrid-Installationen sind leider meinst etwas undankbar. In deinem Fall würde ich das USG nicht “hinter” die Fritbox sondern “daneben” setzen. Ich glaube, dass ist auch das, was du beschrieben hast. Das USG steckt zwar in der FritzBox, du nutzt sie in dem Fall aber nur als Switch. Zur Sicherheit: In dem von dir verlinkten Artikel wird die FritzBox im Routermodus konfiguriert. Du hast geschrieben, dass du den Client-Mode verwendest. Wenn ich dich falsch verstanden habe, bitte korrigier mich.
  
  Vorschlag:
  - Hybrid-Router (DSL&LTE): 192.168.100.1/24 feste IP, kein DHCP, kein DNS, Portweiterleitungen für VoIP zur FritzBox; Statische Route zu den Netzen hinter der USG (192.168.200.0/24, Gästenetz?); Portforwarding VPN Ports auf VPN-Server (192.168.200.y/24, hinter dem USG).
  - FritzBox: 192.168.100.2, feste IP, kein DHCP, kein DNS, kein WLAN, “nur” Telefonanlage
  - USG: WAN<->Hybrid-Router, 192.168.100.3/24, NAT-Regel 5999 aktiv (NAT deaktiviert), “dahinter” PiHole (192.168.200.x/24, UniFi APs und “alles andere”)
  - PiHole: 192.168.200.x/24, DNS-Server, kein DHCP
  - VPN-Server: 192.168.200.y/24, VPN
  Als DHCP Server würde ich das USG für die Netze “hinter” dem USG verwenden, du musst nur als DNS-Server in der DHCP-Konfiguration die IP deines PiHoles verteilen lassen und den DHCP-Server auf dem PiHole deaktivieren. In der USG muss der VPN Port für das Forwarding Hybrid-Router->VPN-Server freigegeben werden. Das Gateway für die Clients in den Netzten “hinter” dem USG ist die jeweilige IP des USG in diesem Netz.
  
  Ich habe versucht, beim Vorschlag möglichst nahe an deiner Lösung zu bleiben. Hoffe es hilft dir weiter.
  
  Gruß
  
  Martin
  Antworten
Eric sagt:

13. Dezember 2019 um 22:46 Uhr

Lieber Martin,
vielen Dank für Deine sehr gute Anleitung! Ich habe alles so eingerichtet wie von Dir beschrieben und in den letzten zwei Monaten lief auch alles ohne Probleme…. bis zum Anfang dieser Woche. Seit Montag morgen hat nur noch mein macbook eine Verbindung ins Netz. Zwei Windows 10 PCs, zwei Iphones und weitere Geräte bauen keine Verbindung mehr auf. Mein Macbook hängt am Wlan, von den Verbindungsproblemen betroffen sind aber sowohl Wlan als auch Lan Geräte. So langsam bin ich mit meinem Latein am Ende und wäre Dir wirklich ausgesprochen dankbar, wenn Du mir eine Einschätzung geben könntest damit ich das Problem eingrenzen kann.

Kurz zu meinem Netzwerk:
ich habe einen Kabelanschluss bei Vodafone über einen DS-lite-Tunnel, am Zugang hängt eine Fritzbox 6490, die von Vodafone eine IPv6 Adresse zugeteilt bekommt und auch einen DNS im IPv6 Format hinterlegt hat. Dahinter dann die USG, zwei 8er Unifi Switches und 3 Unifi APs. Der Controller läuft bei mir auf einem CloudKey der an einem der Switches hängt.

Konfiguriert habe ich alles exakt wie von Dir oben beschrieben… und wie gesagt es lief die ganze Zeit ohne Probleme. Montag Nacht wurde mir dann vom Provider das Update 07.12 auf der Fritzbox eingespielt und ich habe die Vermutung, dass meine Probleme dadurch ausgelöst wurden.

Wie schon geschrieben kommt seitdem, außer meinem Macbook kein anderes Gerät mehr ins Internet. Die statische Route etc. habe ich auf der Fritzbox kontrolliert, hier hat sich nichts geändert. Sowohl die USG, als auch die Fritzbox melden, dass alles OK sei und der Zugang zum Internet bestehe. Eine Traceroute von meinem macbook aus kommt auch zum Ziel und läuft ganz unauffällig über meine USG zur Fritzbox und dann zum Provider.
Zunächst dachte ich mein Problem hätte etwas mit dem DNS Server zu tun, allerdings bekomme ich auch keine Verbindung über die direkte IP Eingabe.
Von meinem Iphone aus sehe ich die anderen Geräte im Netzwerk und kann auch alle, bis auf mein macbook (!) anpingen. Ins Internet raus, kann ich von meinem Heimnetz aus mit dem Iphone allerdings nicht pingen.

Die IPs der einzelnen Geräte sind auch beim alten geblieben und befinden sich im von der USG bereitgestellten (IPv4) Adressraum. Allerdings sehe ich bei einigen Geräten jetzt auch IPv6 Adressen beginnend mit “fe”. Ich weiss jedoch nicht, ob das vorher schon der Fall war.

Ich hoffe ich habe mein Problem trotz meiner Laienhaftigkeit verständlich geschildert. Weiterhin hoffe ich natürlich, dass Du eine Idee hast, wie ich hier vorgehen kann.

LG
Eric

Antworten
1. Martin Ziegler sagt:
  
  14. Dezember 2019 um 18:44 Uhr
  
  Hallo Eric,
  
  bei DSL-Lite findet NAT für IPv4 bereits beim Provider statt. Daher gehe ich davon aus, dass du primär mit IPv6 arbeitest, wenn du Anwendungen nutzt, die mit NAT ein Problem haben? Hast du in der USG bei dem Netz “hinter” der USG unter “IPV6-NETZWERK KONFIGURIEREN” die “Präfix-Delegierung” und “IPv6 Router Advertisement (RA) aktivieren” aktiviert? Die fe80-Adressen sind Adressen für das lokale IPv6 Netz (Verbindungslokale IPv6-Adresse). Ich hatte im IPv6 Umfeld (mit Windows 10) teilweise das Problem, dass die IPv6 Adressen nicht richtig aktualisiert wurden (nach dem Aufwachen aus dem Ruhezustand). Um Sicherzugehen, dass alle Geräte neue Adressen bekommen, kannst du alles ausschalten und in der Reihenfolge FritzBox->USG->Rest (warten bis das jeweilige Gerät verfügbar ist und prüfen ob es eine korrekte IPv6 Adresse hat) wieder anschalten. Ist zwar nicht sehr professionell, wenn’s so klappt, erspart es dir aber viel Analysezeit. Wenn nicht, einfach nochmal melden.
  
  Viel Erfolg
  
  Martin
  
  Antworten
  1. Eric sagt:
    
    29. Dezember 2019 um 21:47 Uhr
    
    Lieber Martin,
    danke für Deine schnelle Antwort. Ich habe die letzten zwei Wochen (auch mit Hilfe Deines Hinweises) versucht mein Problem in den Griff zu bekommen und konnte mich dem Ganzen auch nähern. Heute habe ich allerdings erst mal aufgegeben und die statische Route in der Fritzbox deaktiviert und die USG komplett aus meinem Netzwerk genommen . Jetzt haben zumindest alle Geräte wieder Zugriff auf das Internet.
    Ich bin mir immer noch nicht sicher, ob ich mein Problem exakt lokalisieren konnte. Nach Deinem Hinweis habe ich herausgefunden, dass (fast) alle Geräte die während des Neustarts der Fritzbox bereits mit dem Unifi Netzwerk verbunden sind anschließend ins Internet kommen. Andere Geräte die nicht verbunden sind und sich zu einem späteren Zeitpunkt ins Netzwerk eingewählt haben kommen nicht mehr ins Internet. Bei meinem Macbook, einem WIN 10 PC und meinem Iphone war die Verbindung dann auch so stabil, dass sie nach dem Aufwachen oder nach der erneuten Verbindung mit dem Heimnetz weiterhin ins Internet gekommen sind (so wie es ja auch sein soll). Nachdem ich das festgestellt habe, habe ich mich nat. gefreut und alle meine Geräte mit dem Netzwerk verbunden und die Fritzbox neugestartet. Leider hat es dann doch nicht so stabil funktioniert und vor allem drei Geräte haben weiterhin keinen Zugriff auf das Internet gehabt, ein Amazon Stick, das Iphone meiner Frau und eine TonieBox. Gerade das Iphone meiner Frau und die TonieBox (der Kinder) sind da leider worst-case und vergrößern den Druck auf mich 😉 …. deshalb habe ich jetzt auch erst mal entnervt aufgegeben.
    Ich vermute so ein wenig, dass es in der Tat an IPv6 und der USG liegt. Wie geschrieben wurde meine Verbindung auf DS-Lite umgestellt. Da meine Fritzbox von Vodafone ist, kann ich hier leider nicht alle Einstellungen vornehmen, die sonst so möglich wären. Was ich getestet habe und was für die Geräte funktioniert hat, die im Endeffekt Zugriff auf das Netz hatten waren unter Heimnetz>Netzwerk>Netzwerkeinstellungen>IPv6 Adressen folgende Einstellungen:
    
    * Unique Local Addresses (ULA) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)
    *Diese FRITZ!Box stellt den Standard-Internetzugang zur Verfügung (hoch)
    * DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen
    * Präferenz des FRITZ!Box DHCPv6-Servers: 60
    
    von vodafone bekomme ich eine ipv6 mit /62. Ich habe mir schon überlegt, ob die PD von Vodafone das Problem sein könnte? Die Präferenz des Fritzbox DHCPv6 Servers auf 64 o.ä. zu ändern hat leider nichts gebracht.
    
    Im Unifi Controller habe ich IPV6 sowohl im WAN als auch in LAN1 aktiviert. So wie oben von dir beschrieben. Im Wan habe ich “using DHCPv6” und PD “64” angegeben. Das hat auch erstmalig dazu geführt, dass mein MAcbook eine IPv6 Adresse erhalten hat, die nicht nur verbindungslokal war (fe…).
    Per SSH auf der USG habe ich mir die DHCPv6 Einstellungen noch mal genauer angeschaut und gesehen, dass hier zunächst nur eth0 eine ipv6 adresse hat und eth1 nur eine ipv4 Adresse. Weiterhin ist “show ipv6 route”fehlgeschlagen und “show ipv6 neighbors” hat (bis auf mein macbook) nur diese verbindungslokalen Adressen angezeigt. Ich habe es dann per “delete” und “renew” versucht zu fixen und erst dann, zusammen mit der oben erwähnten EInstellung im Controller von PD “64”, habe ich auch eine IPv6 Adresse am eth1 interface erhalten.
    Allerdings hat mir das USG weiterhin gemeldet, dass kein DHCPv6 Server läuft und im DHCPv6 log stand folgendes: “add_ifprefix: invalid prefix length 63 + 2 + 64” und “dhcp6_get_options: unknown or unexpected DHCP6 option opt_86, len 16”.
    
    Das ist der aktuelle Stand. Mein Eindruck ist, dass sich die USG irgendwie an dem vom ISP bereitgestellten IPV6 verschluckt/nicht richtig konfiguriert ist. Was mich allerdings wundert ist, dass es bei manchen Geräten funktioniert… dann kann es ja nicht komplett falsch konfiguriert sein. Ich bin jedenfalls ein wenig ratlos.
    
    LG
    Eric
    
    Antworten
    1. Martin Ziegler sagt:
      
      1. Januar 2020 um 19:33 Uhr
      
      Hallo Eric,
      dass alle Geräte wie erwartet funktionieren, wenn sie direkt im Netz der FritzBox hängen, ist ein gutes Zeichen (bzw. es wäre ein schlechtes, wenn sie nicht gingen…). Bekommen Sie jetzt alle “richtige” IPv6 Adressen?
      
      Die Meldung “DHCP6 option opt_86, len 16” kannst du ignorieren – habe ich auch und es funktioniert trotzdem. Da geht es um die Konfiguration eines “Port Control Protocol (PCP) Server” (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml).
      
      Die Meldung “add_ifprefix: invalid prefix length 63 + 2 + 64” sieht vielversprechend aus. Kennst du diesen Beitrag: forum.vodafone.de Hier wurde einem Kunden von Vodafone ein zu kleiner Präfix zugewiesen. Er konnte es dadurch lösen, dass er IPv6 komplett deaktiviert hatte, bis sein Lease abgelaufen war. Danach hat er wieder ein 56 Bit Präfix bekommen.
      
      Vielleicht war’s bei dir am Tag des Firmwareupdates deiner FritzBox ähnlich?
      
      Gruß Martin
      
      Antworten
Florian sagt:

18. Dezember 2019 um 18:45 Uhr

Guten Abend,

ich habe z.B. das Problem, dass ich zwar eine IPv6-Adresse bekomme aber die Clients können dann nicht per IPv6 ins Netz. Provider ist die Telekom. IPv6-PD geht ebenfalls.
Das Aufrufen von Webseiten/ Dienste über IPv4 geht hingegen ohne Probleme.

Folgender Aufbau bei mir:
Fritzbox (7530) -> USG -> Switch -> Switch -> Client

Hat hier ggf. jemand eine Idee woran das liegen kann? Ich kann leider nicht auf IPv6 verzichten.

Vielen Dank und viele Grüße
Florian

Antworten
1. Martin Ziegler sagt:
  
  19. Dezember 2019 um 20:38 Uhr
  Hallo Florian,
  ich bin mir nicht sicher ob ich die Frage richtig verstehe.
  - “Bekommst du von der Telekom eine IPv6 Adresse und Prefix Delegation ist vom Provider unterstützt aber deine Clients/USG bekommen keine “korrekten” IPv6-Adressen” oder
  - “Bekommst du von der Telekom eine IPv6-Adresse, dein USG bekommt eine IPv6 Adresse mit dem Prefix des Providers und deine Clients bekommen auch korrekte Adressen aber können trotzdem keine Verbindung zu IPv6-Adressen im Internet aufbauen?”
  Gruß
  Martin
  Antworten
Florian sagt:

20. Dezember 2019 um 8:53 Uhr

Hallo Martin,

vielen Dank für deine Nachricht.

Ich meine die zweite Variante. Soweit ich mich richtig erinnern kann, habe ich sogar das USG anpingen können per IPv6.

Antworten
1. Martin Ziegler sagt:
  
  23. Dezember 2019 um 15:40 Uhr
  Hallo Florian,
  aufgrund der Rückmeldung kann ich leider nicht wirklich Rückschlüsse auf deine Installation ziehen. Ich versuche kurz mein IPv6 Setup aufzuzeigen, vielleicht hilft dir das schon weiter.
  In der FritzBox habe ich unter „Internet -> Zugangsdaten->IPv6“ die Option
  - „IPv6-Unterstützung aktiv“ aktiviert,
  - „IPv6-Anbindung -> Native IPv6-Anbindung verwenden“ ausgewählt,
  - „Verbindungseinstellungen -> Globale Adresse aus dem zugewiesenen Präfix ableiten“ ausgewählt und
  - „Verbindungseinstellungen -> DHCPv6 Rapid Commit verwenden“ aktiviert.
  Die FritzBox zeigt mir im Menüpunkt „Internet -> Online-Monitor“ eine „IPv6-Adresse“ und einen „IPv6-Präfix“ sowie zwei IPv6 Adressen für die DNS Server meines Providers an (neben der IPv4 Konfiguration).
  
  Auf meinem UniFi Controller habe ich mehrere IP-Netze „hinter“ dem USG konfiguriert. Für eines habe ich IPv6 unter „Einstellungen->Netzwerke->->Bearbeiten“ wie folgt eingestellt:
  - IPV6-NETZWERK KONFIGURIEREN
  - IPv6 Schnittstellentyp: Präfix-Delegierung
  - IPv6 Präfix-Delegierungsschnittstelle: WAN
  - IPv6 RA: aktiv
  - IPv6 RA Priorität: Hoch
  - DHCPv6/RDNSS DNS Steuerung: Automatisch
  Wenn’s nicht klappt, müssten wir Schritt für Schritt deine Komponenten durchgehen. Welche Adressen hat das jeweilige Geräte auf welchem Interface und wie ist es konfiguriert.
  
  Gruß
  Martin
  Antworten
Anderl sagt:

23. Dezember 2019 um 0:00 Uhr

Hallo Martin,

wollte einfach mal auch kurz Danke sagen für die tolle Anleitung.

Ich hatte mir auf Grund anderer Berichte ein Vigor 165 Modem zugelegt und habe es leider nicht zum Laufen bekommen (DSL Synchronisierung klappt nicht). Ich bin daher sehr froh, deinen Artikel gefunden zu haben und kann das Ding wieder zurück schicken 🙂

Auch die vielen Kommentare und deine Antworten sind super hilfreich.

VG

Antworten
Fire_Croc sagt:

23. Dezember 2019 um 16:52 Uhr

Hi,

erstmal vielen Dank für die Anleitung.
Leider bin ich noch nicht am Ziel, ggf. könnt Ihr mir helfen.

Setup
Fritzbox 6490 -> IP 192.168.10.1
USG WAN 192.168.10.2 | LAN 192.168.20.1 (dahinter diverse VLANs | QNAP | Pihole | etc.)
Die Fritzboxen halten VPN Tunnel zu anderen Fritzboxen (192.168.10.x zu …11.x | …10.x zu …12.x | usw). Ich hab das doppelte NAT (die JSON Datei oben) NICHT eingespielt, da es mich nicht stört und ich persönlich keinen enormen Sinn gesehen habe es zu tun; ggf. hab ich es auch nicht verstanden?

Der Tunnel aus dem neuen Netz (192.168.20.5 = QNAP) zu einem entfernten NAS (192.168.11.5 | NAS Site2) funktioniert aus dem Stand. Zurück geht es nicht. Ich kann auch von einem Client der direkt an der Fritzbox hängt (192.168.10.100) nicht auf das neue Netz (192.168.20.x) pingen/http/etc.
Also: Firewall oder statische Routen. Alles probiert was mir eingefallen ist oder ich gelesen habe, ging nicht.

Was hab ich probiert?
– Statische Route in Fritzbox (192.168.20.0 mit Gateway 192.168.10.2)
– Exposed host / Auotomatische Portfreigaben akzeptieren in Fritzbox (das USG ist NICHT Exposed Host jetzt)
– USG: IDP/IPS aktiviert/deaktiviert
– USG: Firewall Regel wie hier erläutert

Wo hab ich denn meinen Denkfehler?

Danke!
Fire_Croc

Antworten
1. Martin Ziegler sagt:
  
  23. Dezember 2019 um 19:22 Uhr
  Hallo Fire_Croc,
  da hast du ja eine schöne Installation. Unabhängig von deiner VPN-Konfiguration: wenn du NAT im USG nicht deaktivierst (das mach die JSON im Artikel), sind die Netze hinter dem USG für Geräte im Netz der Fritzbox nicht sichtbar, da NAT/Masquerading genau dafür da ist, Netze hinter einer IP “zu verstecken”. In deinem Kommentar liest es sich ein wenig, als würdest du davon ausgehen, dass mit dem JSON “doppeltes NAT” aktiviert würde – zur Sicherheit: es deaktiviert nur NAT auf dem USG.
  
  Wenn du jetzt auf Geräte hinter dem USG (192.168.20.0/24) aus deinem Netz der FritzBox (192.168.10.0/24) zugreifen willst, kannst du
  - in der Firewall des USG Portforwarding auf die entsprechenden Geräte aktivieren (und diese über die IP des USG mit dem konfigurierten Port ansprechen) oder
  - das NAT im USG deaktivieren, eine statische Route in der FritzBox auf 192.168.20.0/24 konfigurieren und eingehende Anfragen auf Geräte hinter dem USG in der USG Firewall freigeben (dieser Artikel)
  Hilft dir das weiter?
  
  Gruß
  Martin
  Antworten
  1. Fire_Croc sagt:
    
    23. Dezember 2019 um 19:50 Uhr
    
    Damit ich es richtig lesen, sind die beiden Bulletpoints von Dir oben zwei Alternativen?
    Also entweder in der FW des USG Portforwarding machen (wenn du kannst, gerne ein Beispiel, ich hab es zig mal probiert und es geht nicht)
    ODER
    NAT im USG deaktivieren
    
    Hab ich dich korrekt verstanden?
    
    Alternativ könnte ich den VPN Tunnel direkt auf das USG (wofür ich die Fritzbox Config & die USG Config händisch anpassen muss, soweit hab ich es gelesen). Dazu müsste das USG dann aber in den Exposed Modus, sonst krieg ich es ja vom Internet nicht.
    
    Seh ich das richtig?
    Danke für die schnelle Antwort.
    
    Antworten
    1. Martin Ziegler sagt:
      
      25. Dezember 2019 um 20:48 Uhr
      
      Hallo Fire_Croc,
      ja, die Bulletpoins sind Alternativen. Es gibt für Alternative “1” in der Konfiguration des Controllers unter “Einstellungen”->”Routing&Firewall”->”Portweiterleitung” einen Menüpunkt, der genau das macht. Du leitest dann zum Beispiel den Port 4434 des USG auf :443 um und sprichst dein NAS aus den entfernten Netzen mit :4434 an. Eine genauere Anleitung für das erste Beispiel kann ich dir auf die Schnelle nicht geben, da ich bei mir Alternative 2 (NAT in USG deaktiviert) am Laufen habe. Die Variante funktioniert und erlaubt dir ein VPN zur FritzBox aufzubauen um anschließend (wenn in der USG Firewall erlaubt) auf deine Geräte hinter dem USG direkt mit deren IP-Adresse zuzugreifen.
      
      Ein VPN Tunnel direkt auf das USG benötigt das USG nicht zwingend im Exposed Host Modus in der FritzBox sondern nur ein Portforwarding der relevanten Ports von der FritzBox zum USG. Von Exposed Hosts würde ich nach Möglichkeit absehen. Wenn du etwas zu offen konfigurierst, hast du am Ende Besuch, ohne es zu merken. Wenn du deine VPNs zwischen FritzBoxen aufbaust, würde ich das nicht auf das USG verlagern – sonst machst du dir nur eine zusätzliche Baustelle auf.
      
      Wenn du dich für eine Variante entschieden hast, können wir für diese die Konfiguration gerne gemeinsam durchgehen, damit die verschiedenen Ansätze nicht durcheinander gehen.
      
      Gruß
      
      Martin
      
      Antworten
      1. Fire_Croc sagt:
        
        19. Januar 2020 um 19:20 Uhr
        
        Hey,
        
        leider war ich einige Zeit off, daher erstmal DANKE für Deine Erläuterungen.
        Woran ich grad noch knusper… wie krieg ich die config.gateway.json Datei denn auf mein QNAP? Dort läuft Unify im Docker Container und ehrlicherweise hab ich KEINEN Plan wie ich da rankomme. SSH lässt er nicht zu (SSH ist AN in der Weboberfläche) und im QNAP finde ich ehrlich gesagt nicht den Ort, wo die Datei hin muss.
        Hat hier jemand eine Idee?
        
        Danke,
        Fire_Croc!
        
        Antworten
        
        Felix sagt:
        
        20. Januar 2020 um 10:16 Uhr
        
        Hallo Fire_Croc!,
        
        ich habe meinen Controller erst auf eine Synology migirert. Nun ist das nicht das Gleiche, ich weiß aber, dass die Dockeranwedung sehr ähnlich ist. Wenn du in deinem Docker bist und den Controller-Container installiert hast, musst du den Container einrichten. Dabei fragt er dich auch nach dem Speicherort unter “Shared Folder”. Hier gibt es einen “Mount Point” und “Volume from host”. Der Pfad der in letzterem Punkt steht gibt an wo die Dateien des Controllers auf deiner Nas landen. Die Ordnerstruktur sieht bei mir dann genau so aus, wie wenn man den Controller auf nem Win 10 Rechner installiert.
        Alternativ kannst du auch einfach mal die Suche deiner QNAP bemühen. Bei mir gabs aber nach \Data keine weiteren Unterordner. Das musste ich selbst anlegen.
        
        Viele Grüße
        
        Felix
        
        Antworten
        
        Fire_Croc sagt:
        
        20. Januar 2020 um 23:15 Uhr
        
        Felix,
        
        danke Dir, soweit dachte ich es mir.
        Bei mir sieht es dann so aus:
        Container -> lib ->docker -> volumes -> 96….langer-key -> _data
        Dort hab ich aber nur einen Folder “work”, eine mongodb.sock, eine update.json Datei. Thats it – den ganzen Teil mit sites etc. hab ich da nicht 🙁
        
        Bei der Suche nach “sites” als Ordner kommt irgendwie auch nix… sehr strange.
        Ich hab den Docker Container “jacobalberty/unifi:latest” – du?
        
        Fire_Croc
        
        Antworten
        
        Fire_Croc sagt:
        
        20. Januar 2020 um 23:19 Uhr
        
        Felix,
        
        genauer gesagt hab ich bei mir nur folgende 2 shared folders:
        /var/run/unifi
        =====
        var/
        /share/CE_CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/96c3e8b2b2e5f84fd9c1f25e1bf7296636b30821f069e35196b1ae168703bf32/_data
        
        und
        
        /unifi
        =====
        /share/CE_CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/3400e79ec2bb27b1125f9f3f60da0f08d345795b89e44498405c57bb75f98ed9/_data
        
        da is gar kein volume from host etc…
        VERY strange…
        
        Fire_Croc!
        
        Antworten
        
        Felix sagt:
        
        20. Januar 2020 um 23:53 Uhr
        
        Hallo Fire_Croc!,
        
        mhm ich bin auch kein Profi, aber es sieht mir so aus als ob das bei dir alles in temporären oder versteckten Ordnern liegt. Wenn ich auf meine Synology mit Putty drauf gehe, sehe ich auch solche von dir beschriebenen Ordner. Aber es gibt zwei Pfade die es einzurichten gilt:
        
        https://www.qnap.com/de-de/how-to/tutorial/article/wie-richtet-man-einen-unifi-controller-in-container-station-ein/
        
        in dieser Anleitung wird nicht wirklich darauf eingegangen aber man sieht es im Bild 4 von oben. Hier gibt es den Punkt „shared Folder“ (vermutlich unter “advanced Settings” und da muss es wie hier (https://docs.luckycloud.de/de/nas unter und über 8.) die Möglichkeit geben einen Pfad und einen Mountingpfad anzugeben. Letzteren bekommst du nicht zu Gesicht. In ersterem landet Data (bei mir gab es da auch keinen Ordner Sites/default; das habe ich anlegen müssen).
        
        “jacobalberty/unifi:latest” dito.
        
        Vielleicht hilft dir ja auch diese Anleitung: http://www.bu4.eu/unifi-controller-und-synology-nas-das-docker-dream-team/
        Das ist Synology, aber auch hier ist zu sehen was ich meine: Datei/Ordner wird extra angelegt -> Docker/unifi und daraus entsteht später dann Docker/unifi/data/sites/default [oder wie auch immer deine site heißt].
        
        Ebenfalls gut bei Synology in den Advanced Settings zu sehen: Es gibt Pfade wie var/lib… aber der Pfad data landet auf dem VolumeXY.
        Hoffe das hilft ein wenig….
        
        Gruß
        Felix
        
        Antworten
Thomas sagt:

30. Dezember 2019 um 11:32 Uhr

Unifi Probleme

Hallo Martin,
vielen Dank für die Tolle Erklärung.
Versuche jetzt seit 2 Tagen das ganze nachzuvollziehen, klappt aber irgendwie nicht.
Ich bekomme keinen Internetzugang an LAN1
Zur Erklärung meines Netzwerkes: Habe eine 7590. Viele Geräte haben eine statische IP im Bereich 192.168.178.xxx. Möchte daher der Fritzbox die Adresse 192.168.0.1 geben und dann im USG den Adressbereich 192.168.178.xxx nutzen. Mein Unifi Controller läuft auf einem QNAP Server.

Einstellungen: FritzBox 7590:
IPv4-Adressen (Heimnetz)
IPv4-Adresse: 192.168.0.1
Subnetzmaske: 255.255.255.0
DHCP aktiv
DHCP von: 192.168.0.2
DHCP bis: 192.168.254
Lokaler DNS Server: 192.168.0.1
IPv4-Routen
IPv4-Netzwerk: 192.168.178.1
Subnetzmaske: 255.255.255.0
Gateway: 192.168.0.250
IPv4-Route aktiv

Unifi USG
USG-WAN1 and FRITZBox LAN1 angeschlossen.
AM USG-LAN1 hängt ein Testnotebook (Netzwerkeinstellungen auf DHCP)
Über 192.168.1.1 direkter Zugriff auf USG. Daten eingestellt und gespeichert.
Danach Zugriff über 192.168.178.1

Configuration WAN Settings
Connection Type Static IP
IP-Adress 192.168.0.250
Subnetmask 255.255.255.0
Router 192.168.0.1
Preferred DNS 192.168.0.1
Alternate DNS 8.8.8.8
Configuration LAN Settings
IP-Adress 192.168.178.1
Subnetmask 255.255.255.0
DHCP Server On
DHCP Range from 192.168.178.200
DHCP Range to 192.168.178.254

Mit diesen Einstellungen erhalte ich auf der USG Main Seite (192.168.178.1) die Meldung: „Congratulations! The Gateway is connected tot he internet“

Testnotebook neu gestartet. Erhalte mit cmd \ ipconfig folgende Informationen:
IPv4-Adresse 192.168.178.200
Subnetzmaske 255.255.255.0
Standardgateway: – kein Eintrag –

Mit dem Notebook erhalte ich keinen Zugriff auf das Internet.

Unifi Controller Software lokal installiert. USG kann nicht eingebunden werden.
Zugriff über die 192.168.178.1 danach nicht mehr möglich (Username / Passwort) falsch.
Daher konnte ich auch bisher die .json Datei nicht einspielen.

Irgendwelche Ideen was ich falsch mache?

Antworten
1. Martin Ziegler sagt:
  
  5. Januar 2020 um 22:07 Uhr
  
  Hallo Thomas,
  
  du hast mir zwischenzeitlich gemailt, dass du die Ursache bereits gefunden hast, warum du keinen Zugriff aufs Internet mit der oben beschriebenen Konfiguration hattest. Du hast dir die Konfigurationsempfehlungen aus dem Artikel und den Kommentaren in einem Excel zusammengefasst und festgestellt, dass du in der FritzBox bei der statischen Route als Netzadresse 192.168.178.1 anstelle 192.168.178.0 angegeben hattest. Da dieser Fehler bereits einigen Lesern passiert ist, freue ich mich, dass du mir erlaubt hast, dein Bild aus der Mail in meiner Antwort zu verwenden – so sticht die Antwort vielleicht aus der Menge etwas hervor und hilft dem einen oder anderen Leser.
  
  Erklärung: Bei einer statischen Route geht es darum dem Gerät (in unserem Fall die FritzBox) zu erklären, wie es in IP-Netze kommt, an die es nicht direkt angebunden ist und zu der kein Weg über die Default-Route führt. In deinem Fall geht es um das Netz 192.168.178.0/24, das du hinter deinem USG konfiguriert hast und das über die IP des USG im Netz der FritzBox 192.168.10.3 erreicht werden kann, wenn dort NAT deaktiviert ist. 192.168.178.1/24 ist keine Netzadresse, sondern eine IP-Adresse eines Endgeräts.
  
  192.168.178.0/24 meint: Das Subnetz 192.168.178.0 mit der Subnetzmaske 255.255.255.0 (24 Bit), der Broadcast Adresse 192.168.178.255 und 254 Adressen für Endgeräte von 192.168.178.1 bis 192.168.178.254.
  
  Achtung: 192.168.178.0/24 ist eigentlich das Netz, dass die FritzBox defaultmäßig verwendet. Thomas hat es “umgezogen” damit er die bisherigen IP-Adressen seiner Endgeräte beibehalten kann – davon nicht verwirren lassen. Am besten wie Thomas in Ruhe ein Excel erstellen und so die korrekten Werte für die eigene Umgebung dokumentieren.
  
  Gruß Martin
  
  Antworten
  1. Bastian sagt:
    
    15. Dezember 2021 um 11:16 Uhr
    
    Klasse Darstellung, damit habe ich es jetzt auch verstanden und umsetzen können!
    
    Antworten
Bernd sagt:

5. Januar 2020 um 5:07 Uhr

Lieber Martin,

erstmal Danke für den fantastischen Artikel. Hat bei mir auf Anhieb funktioniert.
Gerade für nicht so versierte Leute, die trotzdem eine Unifi Umgebung haben sehr hilfreich!
Eine Frage hätte ich noch, die du mit vermutlich Stehgreif beantworten kannst.

In meinem Fall ist eine FritzBox 7530 das Modem und Router (nicht im Bridge Mode), daran hängt die USG und dahinter mein internes Netz mit Unifi Switch und AP.
Die FritzBox hat sonst keine andere Funktion und es sind auch keine anderen Geräte angeschlossen (WLAN deaktiviert).
Warum sollte ich in diesem Szenario die USG nicht als Exposed Host definieren? Die USG übernimmt doch die Firewall Funktion und die FritzBox hat außer DSL Verbindung aufbauen und USG eine IP zuordnen keine weiteren Funktionen.
Bzw. was wären die Vor-/Nachteile das zu machen?

Danke!

Antworten
1. Martin Ziegler sagt:
  
  5. Januar 2020 um 22:30 Uhr
  
  Hallo Bernd,
  
  wenn du das USG in der FritzBox als Exposed Host konfigurierst, werden alle Anfragen aus dem Internet, die an die IP der FritzBox gehen an das USG weitergeleitet. Kann man machen – ich bin allerdings kein Freund davon. Persönlich möchte ich unerwünschten Traffik so früh wie möglich blockieren und nicht erst ins eigene Netz lassen. Für den Fall, dass das Gerät, das als Exposed Host konfiguriert ist, Sicherheitslücken hat oder versehentlich ein unerwünschter Dienst darauf läuft, bietest du mehr Angriffsfläche als notwendig. Der Vorteil eines Exposed Hosts ist, dass die Umgebung weniger komplex zu konfigurieren ist und weniger beim Aufbauen nachgedacht und aufgepasst werden muss – das kommt dann später, wenn es ein Problem gibt. Wenn du keine Dienste in deinem Netz für den Rest der Welt anbieten willst und nur Verbindungen von “innen nach außen” aufbaust, bringt dir ein Exposed Host jedoch keinen Mehrwert.
  
  Hilft dir das weiter? Bitte nicht als technische Wahrheit sehen, ist meine persönliche Meinung.
  
  Gruß Martin
  
  Antworten
  1. Bernd sagt:
    
    6. Januar 2020 um 7:16 Uhr
    
    Hi Martin,
    
    ja das hilft absolut weiter, vielen Dank! In meinem Nutzungsszenario geht es tatsächlich rein um inside-out, umgekehrt mache ich nichts dergleichen.
    
    In meiner laienhaften Vorstellung dachte ich mir, dass zweimal Firewall sich etwas behindert oder zumindest keinen Vorteil bringt und man sich damit auch die Portfreigaben spart, falls benötigt.
    In der FritzBox gibt es ja auch noch die Option “selbstständige Portfreigabe erlaubt” zu aktivieren. Vermute allerdings das wäre dann genauso wie wenn man die USG als Exposed Host definiert.
    
    Vielen Dank für deine Geduld und wertvollen Inputs!
    
    LG Bernd
    
    Antworten
    1. Martin Ziegler sagt:
      
      6. Januar 2020 um 10:22 Uhr
      
      Hallo Bernd,
      
      der Unterschied zwischen “selbstständige Portfreigabe erlaubt” und “Exposed Host” ist, dass es bei der zweiten Variante nur ein Endgerät im Netz geben kann, bei dem die Option aktiv ist und alle Anfragen dorthin geleitet werden. Bei der ersten Variante werden nur aktiv von einem oder mehreren Geräten im privaten Netz per UPnP oder PCP angeforderte Ports weitergeleitet. Das kann für Konsolen, Filesharing oder ähnliches nützlich oder notwendig sein. Wenn die Überwachungskamera per UPnP Port 80 (mit Sicherheitslücke im Webserver) auf sich weiterleitet und so “jeder” aus dem Internet in deine Wohnung schauen kann, ist es weniger gut…
      
      Wenn du auf eine Firewall verzichten wolltest, würde ich nicht die beim Übergang vom öffentlichen zum privaten Netz deaktivieren/pauschal öffnen.
      
      Gruß
      
      Martin
      
      Antworten
Markus sagt:

9. Januar 2020 um 13:49 Uhr

Hallo zusammen, ich bekomme meine VPN-Verbindung nicht aufgebaut.

Ich habe eine Fritz.Box 7590. Dort gibt es keine VPN Verbindungen, kein WLAN. Sie hat die Standard-IP 192.168.178.1. Das einzige Gerät, welches dort an LAN4 hängt ist die USG mit fester IP 192.168.178.20.
Die USG hat die 192.168.1.1 und baut derzeit 3 Subnetze auf (LAN1 192.168.1.0, LAN2 192.168.2.0 und einen Adressbereich für die VPN Verbindung 192.168.3.0). VPN ist mit RADIUS auf der USG konfiguriert.
Auf der Fritz.Box gibt es 3 statische Routen für die 3 Subnetze der USG. In der USG gibt es eine neue FW-Regel für WAN-IN wie laut Anleitung hier. Quell-IP ist die 192.168.178.201 und Ziel ist das LAN1.
Die Fritz.Box hat DynDns mit spdyn konfiguriert (funktioniert).

Mit dem iPHone bekomme ich nun immer “Authentication failed”.

Das VPN log direkt auf der USG (per SSH) zeigt folgendes bei Verbindungsversuchen:

Jan 9 13:22:37 12[IKE] 80.187.105.156 is initiating a Main Mode IKE_SA
Jan 9 13:22:38 04[IKE] IKE_SA remote-access[5] established between 192.168.178.20[192.168.178.20]…80.187.105.156[10.77.158.246]
Jan 9 13:22:39 16[IKE] CHILD_SA remote-access{5} established with SPIs cef40e45_i 0a6075e1_o and TS 192.168.178.20/32[udp/l2f] === 80.187.105.156/32[udp/49167]
Jan 9 13:23:12 16[IKE] closing CHILD_SA remote-access{5} with SPIs cef40e45_i (1466 bytes) 0a6075e1_o (534 bytes) and TS 192.168.178.20/32[udp/l2f] === 80.187.105.156/32[udp/49167]
Jan 9 13:23:12 14[IKE] deleting IKE_SA remote-access[5] between 192.168.178.20[192.168.178.20]…80.187.105.156[10.77.158.246]
Jan 9 13:23:18 01[KNL] interface ppp0 deleted

Jan 9 13:26:58 10[IKE] 80.187.105.156 is initiating a Main Mode IKE_SA
Jan 9 13:27:00 06[IKE] IKE_SA remote-access[6] established between 192.168.178.20[192.168.178.20]…80.187.105.156[10.77.158.246]
Jan 9 13:27:00 16[IKE] CHILD_SA remote-access{6} established with SPIs cf12ad46_i 039281bc_o and TS 192.168.178.20/32[udp/l2f] === 80.187.105.156/32[udp/50778]
Jan 9 13:27:34 16[IKE] closing CHILD_SA remote-access{6} with SPIs cf12ad46_i (1466 bytes) 039281bc_o (534 bytes) and TS 192.168.178.20/32[udp/l2f] === 80.187.105.156/32[udp/50778]
Jan 9 13:27:34 13[IKE] deleting IKE_SA remote-access[6] between 192.168.178.20[192.168.178.20]…80.187.105.156[10.77.158.246]
Jan 9 13:27:40 12[KNL] interface ppp0 deleted

Es kommt immer bis zum Eintrag CHILD_SA, dann dauert es eine Weile und es erscheint automatisch closing CHILD_SA etc..

Was fehlt bzw. was mache ich noch falsch?

Wäre sehr dankbar für Unterstützung.

Grüße,
Markus

Antworten
1. Martin Ziegler sagt:
  
  9. Januar 2020 um 22:30 Uhr
  
  Hallo Markus,
  
  in dem Artikel bin ich davon ausgegangen, dass die VPN-Funktionalität der FritzBox verwendet wird. Von daher kannst du die Firewallanpassungen im USG nicht 1zu1 auf deinen Fall übertragen. Du musst ein Portforwarding der für das VPN notwendigen Ports von der FritzBox auf das Endgerät in deinem Netz konfigurieren, zu dem der VPN Tunnel aufgebaut werden soll (in deinem Fall das USG).
  
  Hilft dir das weiter? Die eventuell relevanten Ports findest du, wenn du in Google nach “usg vpn ports” suchst. Ich habe sie nicht in meine Antwort genommen, da ich eine solche Konfiguration nicht am Laufen habe und nicht ungetestet irgendwelche Angaben zu Ports machen möchte.
  
  Gruß
  
  Martin
  
  Antworten
Felix sagt:

9. Januar 2020 um 21:56 Uhr

Guten Abend Martin,

Ich habe es ja erfolgreich hinbekommen die config hochzuladen.
Nun wollte ich einen Schritt weiter gehen und den Controller auf eine NAS umziehen. Anfangen wollte ich mit einem Backup des alten conteollers. Aber eben das geht nicht mehr. Es werden automatische Backups erstellt. Aber wenn man im Controller sich ein Backup erstellen will (unabhängig von den Einstellungen) dann kommt ein ERROR. Das ist unabhängig vom Browser nur die Fehlermeldung ist eine andere.
Es gibt von ubiquiti einen Hilfe thread der damit endet, dass es an der config-datei liegen kann. Kennst du das Problem? Ich könnte das natürlich testen in dem ich die Datei für die USG lösche, aber dadurch habe ich nicht wirlich was gewonnen.

Gruß
Felix

Antworten
1. Martin Ziegler sagt:
  
  9. Januar 2020 um 22:20 Uhr
  
  Hallo Felix,
  den von dir erwähnten Hifethread kenne ich leider nicht. Das Herunterladen einer Backupdatei über “Einstellungen->Backup-> BACKUP / WIEDERHERSTELLEN -> DATEI HERUNTERLADEN” funktioniert bei mir sowohl mit der Option “7 Tage” als auch mit “Keine Begrenzung” ohne Probleme. Mein Controller hat die Version 5.12.35-12979-1, als Browser habe ich Chrome verwendet. Hast du in einer Log-Datei auf dem Controller eine Meldung gefunden, die mehr als nur “ERROR” sagt?
  
  Wenn es bei dir doch an der Datei liegen sollte, kannst du sie löschen, deinen Controller aufs NAS umziehen und abschließend die Datei wieder erstellen. Auf dem USG werden die Änderungen durch die Datei nur aktiv, wenn du das Provisionieren aktiv startest oder es durch eine andere, für das USG relevante, Konfigurationsänderung anstößt.
  
  Gruß Martin
  
  Antworten
  1. Felix sagt:
    
    9. Januar 2020 um 22:27 Uhr
    
    Hallo Martin,
    
    Die Version des Controllers ist bei mir gleich. Und genau der von dir beschriebene Schritt für bei mir in Firefox zu einem Seitenladefehler und in Chrome zu dem besagten Error.
    Aber dann muss ich vielleicht wirklich einfach mal die Datei löschen. Eigentlich sollte ja kein Provisionieren stattfinden, wenn es nicht manuell ausgelöst wird.
    Ich werde mal noch etwas probieren.
    Danke für die schnelle Antwort.
    
    Gruß
    Felix
    
    Antworten
    1. Felix sagt:
      
      20. Januar 2020 um 10:22 Uhr
      
      Hallo,
      
      also schlussendlich hat bei mir eine Neuinstallation des Controllers geholfen. Einfach über die alte Installation drüber bügeln. Dabei hat sich die Version des Controllers NICHT geändert.
      Der Hilfeartikel von Unifi den ich ansprach und mir nicht geholfen hat ;-):
      https://help.ubnt.com/hc/en-us/articles/360012624134-UniFi-Troubleshooting-Issues-with-Controller-Backup-Files
      
      Gruß
      Felix
      
      Antworten
      1. Martin Ziegler sagt:
        
        20. Januar 2020 um 21:19 Uhr
        
        Hallo Felix,
        
        es freut mich, dass du dein Problem lösen konntest. Die Neuinstallation war eine gute Idee – daran hatte ich nicht gedacht. Vielen Dank für das Teilen deiner Lösung.
        
        Gruß
        Martin
        
        Antworten
Thomas sagt:

14. Januar 2020 um 20:16 Uhr

Hallo,

weiß jemand zufällig, wo das richtige Verzeichniss für das config.gateway.json auf der Unifi DreamMachine sich befindet, die ja auch den Controller beinhaltet.

Die Infos aus dem Artikeln oben passen nich und ich finde auch nichts im Filesystem, was passt.

Danke und Gruß

Thomas

Antworten
1. Martin Ziegler sagt:
  
  16. Januar 2020 um 23:40 Uhr
  
  Hallo Thomas,
  ich habe leider keine UniFi DreamMachine. Hast du versucht das Verzeichnis mit dem temporären Aktivieren des Gästeportals anzulegen? Siehe: Kommentar vom 26. November 2019 um 20:31 Uhr.
  
  Gruß
  Martin
  
  Antworten
Max sagt:

15. Januar 2020 um 1:33 Uhr

Moin Moin Martin,

vorab vielen Dank für deine tolle Arbeit!

Ich bin deiner Anleitung gefolgt und meines Erachtens nach habe ich alles auch so ausgeführt, nur komme ich nicht über die FritzBox auf meine gewünschte IP ins USG Netzwerk.

1. “JSON” Datei (die du oben zum Download zur verfügung gestellt hast) auf dem Controller abgelegt, muss diese irgendwie besonders angepasst werden? (Screenshot Ablage Datei: https://www.bilder-upload.eu/bild-de7605-1579047193.jpg.html)

2. Dann habe ich die Statische IPv4 Route in meiner FritzBox eingepflegt. (Screenshot: https://www.bilder-upload.eu/bild-9de00f-1579047427.jpg.html)

3. Dann habe ich das Gateway Provisioniert (Welches nicht mit einem Neustart verbunden war und dementsprechend auch nicht allzu lange gedauert hat?)

4. Dann habe ich die Regel für eine VPN Verbindung auf eine bestimmte IP erstellt. (Screenshot: https://www.bilder-upload.eu/bild-a92109-1579047894.jpg.html) Warum auf Intern? Das wäre beispielsweise eine NAS oder ein Drucker auf welchen ich zugreifen möchte.
Ebenfalls kann ich dort aber auch das Netzwerk: LAN (192.168.1.0) auswählen komme aber auch nur auf die 192.168.1.3 welches der CloudKey wäre aber auf kein weiteres Gerät in dieser Reichweite, wie z.B. den Controller auf der 192.168.1.1

Netzwerkadressen:
FritzBox Netzwerk: 192.168.178.0
USG Gateway WAN: 192.168.178.10
USG Gateway LAN: 192.168.1.0
USG Gateway: 192.168.1.1
Unifi Switch: 192.168.1.2
Unifi CloudKeyGen2: 192.168.1.3
NAS: 192.168.10.18
Drucker: 192.168.10.19

Vielen dank vorab für deine Unterstützung
Gruß Max

Antworten
1. Martin Ziegler sagt:
  
  18. Januar 2020 um 17:11 Uhr
  
  Hallo Max,
  
  Punkte 1-3: Wenn du testen möchtest, ob dein USG kein NAT mehr durchführt, kannst du wie folgt vorgehen:
  Greife von einem Gerät aus einem Netz hinter dem USG – bei dir zum Beispiel 192.168.10.0 oder 192.168.1.0 – auf das Internet zu. Wenn das klappt, deaktiviere die statische Route für dieses Netz in der Fritz!Box. Wenn der Zugriff nicht mehr funktioniert, ist NAT auf dem USG deaktiviert und du kannst die statische Route wieder aktivieren. Wenn der Zugriff trotz deaktivierter statischer Route in der Fritz!Box noch funktionieren sollte, macht das USG noch NAT und du solltest die Konfiguration prüfen.
  Im “Gutfall” funktioniert bei deaktiviertem NAT der Zugriff durch die Firewall des USG, da es eine Regel gib, die Pakete aus dem Netz am WAN-Port des USG akzeptieren, wenn sie zu Verbindungen gehören, die initial aus einem Netz am LAN-Port des USG aufgebaut wurden. Verbindungen, die initial aus einem Netz am WAN-Port des USG aufgebaut werden (bei dir 192.168.178.0), werden verworfen.
  
  Punkt 4: Leider bin ich mir nicht ganz sicher, was du mit “VPN Verbindung” meinst. Im Screenshot ist eine Firewallregel, bei der ich leider nicht erkennen kann, ob sie unter “WAN eingehend” angelegt ist. Ich vermute, du willst entweder Endgeräten aus dem Netz der Fritz!Box oder VPN-Verbindungen, die du zur Fritz!Box aufbaust, erlauben auf deine Netze oder einzelne Geräte “hinter” deinem USG zuzugreifen. In deinem Fall sollte das Endgerät 192.168.178.234 auf alle Geräte im Subnetz “intern” (192.168.10.0?) zugreifen können. Du schreibst, dass du auf deinen CloudKey 192.168.1.3 zugreifen kannst (wenn du anstelle “intern” das Subnetz 192.168.1.0 als Ziel konfigurierst). Du bezeichnest 192.168.1.1 als “Controller”, der läuft jedoch auf deinem CloudKey – ich vermute du meinst das USG?
  
  Bei Punkt vier bin ich mir wie gesagt nicht sicher, ob ich dich, bzw. dein Problem, richtig verstanden habe. Wenn du korrigierst oder ergänzt, was ich falsch verstanden habe, kann ich dir vielleicht noch einen Tipp geben.
  
  Gruß
  Martin
  
  Antworten
Thomas sagt:

17. Januar 2020 um 17:41 Uhr

Hallo,

ich habe mittlerweile die Infos aus dem Unifi-Forum, das es auf der DreamMaschine nicht möglich ist, das NAT über ein JSON-File auszuschalten und es aktuell auch keine Möglichkeit gibt.

Antworten
1. Martin Ziegler sagt:
  
  18. Januar 2020 um 16:41 Uhr
  
  Hallo Thomas,
  
  vielen Dank für die Info zur UniFi Dream Machine. Habe auch ein wenig im Netz gesucht – schade, dass man auf das Problem mit dem nicht deaktivierbaren NAT erst stößt, wenn man gezielt danach sucht…
  
  Gruß
  
  Martin
  
  Antworten
Micha sagt:

19. Januar 2020 um 10:55 Uhr

Hey Martin, ich stehe vor der gleichen Aufgabe. Habe ein Unifi Switch mit Unifi WiFi APs und einen Cloud Key. Alles top. Jetzt habe ich mir noch das USG geholt und habe auch die “doppeltes Nat”-Problem. Bevor ich den ganzen Weg von dir gehe: was ist denn der wirkliche Vorteil des USG gegenüber der Fritz Box? Was kann es besser als die Fritzbox, wenn ich diese doch eh als Modem und DECT-Anlage weiter nutzen möchte?

Antworten
1. Martin Ziegler sagt:
  
  19. Januar 2020 um 16:43 Uhr
  
  Hallo Micha,
  
  wenn du bereits das USG in dein Netz integriert hast und – mal abgesehen vom doppelten NAT – alles funktioniert wie du möchtest, hast du nur noch einen kleinen Schritt vor dir.
  
  Zu deiner Frage des Vorteils des UniFi Security Gateways gegenüber einer Fritz!Box: In deiner Installation ist es, nach meinem Verständnis, weniger ein “entweder oder” sondern eher ein “was bringt mir das USG zusätzlich an Mehrwert”. Das USG ist die Komponente im UniFi “Ökosystem”, die es dir erlaubt VLANs zu definieren und den Verkehr zwischen deinen Netzen über eine Firewall zu regulieren. Zusätzlich hat sie noch einen Radiusserver (z.B. für WPA2-Enterprise) und ein paar andere nette Features wie Intrusion-Detection und -Prevention (IDS/IPS). All das kannst du auch ohne das USG (mit anderer Hardware) erreichen. Meist jedoch mit mehr Zeit, Geld oder weniger einfach. Kurz: Wenn du das “software defined network”, das du über den UniFi Controller konfigurieren kannst, möglichst vollumfänglich wie von Ubiquiti vorgesehen, nutzen willst, brauchst du das UniFi Security Gateway.
  
  Passt die Antwort zu deiner Frage?
  
  Gruß
  Martin
  
  Antworten
Matt sagt:

21. Januar 2020 um 11:49 Uhr

Hallo Martin, vielen Dank für den Blog Eintrag. Ich habe eine Frage bezüglich Newbies zum Ubiquiti, wie ich 🙂

Ich habe ein ganz einfaches Netzwerk, möchte ich gern es über den nächsten Monate aufbauen. Zurzeit habe ich nur die FB 7490 und ein Unifi Switch 24, darauf hangt auch ein Fritz Repeater (der ich später mit ein Ubiquiti AP ersetzen will). Ich habe mir ein USG gekauft aber ich bin zuerst nicht sicher, wie und wo fange ich an ihn zu integrieren… Ich habe schon probiert aber er könnte überhaupt nicht adopiert. Ich habe gelesen das vielleicht muss ich etwas manuell mit ihm konfigurien:
https://help.ubnt.com/hc/en-us/articles/236281367-UniFi-USG-How-to-Adopt-a-USG-into-an-Existing-Network

Ich dachte vielliecht haben sie einen Hinweis für mich, damit ich zwei Tage ohne Internet Zugang vermeiden kann 😉

Danach, ist es möglich der USG sofort einzustellen, damit er ohne NAT funkioniert, wie Sie beschrieben haben, oder ist es einfacher zuerst ihn “normal” zu installerien – mit doppel NAT – und danach weiter konfiguerien?

Danke für die Hilfe und sorry für mein Deustch ha ha!

Cheers.

Antworten
1. Martin Ziegler sagt:
  
  21. Januar 2020 um 21:31 Uhr
  
  Hallo Matt,
  
  dein Ansatz, das USG erst mal “normal” einzubinden – also wie vom Hersteller vorgesehen, mit aktivem NAT – ist der sichere Weg. Internet hast du auch mit dem USG weiterhin, wenn du deine Geräte direkt an deine FritzBox hängst. Wie du dein USG am besten in dein Netz integrierst, hängt davon ab, wie deine Netzinfrastruktur danach aussehen soll.
  
  Einfach ausprobieren – solange, du deine FritzBox hast, die dir den Internetzugang herstellt, solltest du keine internetfreien Tage zu befürchten haben.
  
  Gruß
  
  Martin
  
  Antworten
FlakeZ sagt:

30. Januar 2020 um 17:32 Uhr

Hallo zusammen,
ich bin dank Google auf die Seite aufmerksam geworden und muss einmal um Hilfe fragen. Das Thema ist etwas ausführlicher – daher ein kurzer Link in die Historie: https://community.ui.com/questions/GER-CloudKey-Kommunikation-uber-VLAN-ENG-CloudKey-communication-over-VLAN/78dae421-300e-4b30-bb2e-87d84d8cef8a?page=1

Ich möchte letztendlich eine Portfreigabe von der FritzBox 192.168.5.1 -> zum USG 192.168.5.2 -> zu einem anderen Netzwerk / Client was dem USG gehört 192.168.15.150 betreiben. Die WAN Schnittstellen können nicht genutzt werden, da hier zwei LTE Funkstrecken hinterlegt sind. der USG, die APs, Switch und das Büro-Netzwerk liegen auf einer ausgelagerten FritzBox mit einem DSL AS (Warum steht in dem Thread oben). Nun bekomme ich es aber nicht hin dem USG zu sagen, dass ich extern auf das 15er Netz zugreifen möchte. Gibts da vielleicht einen Rat?

Antworten
Fritspet sagt:

5. Februar 2020 um 18:13 Uhr

Hallo zusammen,

habe es genau nach Anleitung konfiguriert .
NAT auf USG ist deaktiviert (eth2).

Fritzbox -192.168.176.0/24 -> ist auf WAN2 am USG angeschlossen.
USG – 192.168.179.0/15
Die Statische Route wurde in der FritzBox korrekt eingetragen.

Die Verbindung zwischen den Geräten im USG Netz und zur FritzBox funktioniert einwandfrei.
Verbindungen von USG ins Internet funktionieren jedoch nicht.

#traceroute von einem am USG Angeschlossenen Client
traceroute to google.de (172.217.16.163), 64 hops max, 52 byte packets
1 router (192.168.179.1) 0.463 ms 0.201 ms 0.187 ms
2 fritz.box (192.168.176.1) 0.601 ms 0.508 ms 0.497 ms
3 *^C

#traceroute vom USG aus
traceroute to google.de (172.217.16.163), 30 hops max, 38 byte packets
1 fritz.box (192.168.176.1) 0.298 ms 0.277 ms 0.240 ms
2 HSxxxxxxxxx.hsi15.kabel-badenwuerttemberg.de (xxxxxxx) 18.921 ms 8.964 ms 10.767 ms
3 ip-81-210-144-156.hsi17.unitymediagroup.de (81.210.144.156) 13.237 ms 18.171 ms 24.034 ms
4 de-fra04a-rc1-ae-19-0.aorta.net (84.116.191.161) 51.655 ms 15.729 ms 35.849 ms
5 de-fra04d-rc1-ae-26-0.aorta.net (84.116.138.238) 14.049 ms 13.331 ms 16.671 ms
6 de-fra03b-ri1-ae-5-0.aorta.net (84.116.133.118) 21.522 ms 16.038 ms 14.530 ms
7 72.14.195.116 (72.14.195.116) 18.256 ms 15.325 ms 12.259 ms
8 * * *
9 74.125.37.124 (74.125.37.124) 17.781 ms 72.14.233.46 (72.14.233.46) 25.140 ms 108.170.235.246 (108.170.235.246) 18.225 ms
10 216.239.63.255 (216.239.63.255) 13.957 ms 25.847 ms 108.170.251.208 (108.170.251.208) 14.637 ms
11 fra15s11-in-f163.1e100.net (172.217.16.163) 73.901 ms 15.075 ms 209.85.252.214 (209.85.252.214) 44.695 ms

Hoffe ihr könnt mir helfen. Bin am verzweifeln.
Grüße Peter

Antworten
1. Martin Ziegler sagt:
  
  1. März 2020 um 17:04 Uhr
  Hallo Peter,
  
  leider habe ich erst mal ein paar Rückfragen. Danach, kann ich dir eventuell weiterhelfen.
  - Du deaktivierst NAT für eth2 (in der Anleitung: eth0) und hast die FritzBox an WAN2 des USG angeschlossen (Anleitung: WAN1). Bist du mit Absicht von der Anleitung abgewischen?
  - Bist du dir sicher, dass du beim USG “192.168.179.0/15” (als Adresse des LAN Ports?) definiert hast? Wenn ja, möchtest du das wirklich? Das wäre ein von 131072 möglichen Hostadressen im Subnetz 192.168.0.0/15 – das gäbe zumindest einen Konflikt mit dem Netz 192.168.176.0/24 deiner FritzBox.
  Tipp: bleibe bei 24 Bit Subnetzen hinter dem USG – es kann zwar Gründe geben größere oder kleinere Subnetze zu definieren, bei 24 Bit passen jedoch die meisten Anleitungen und Beispiele im Internet besser auf dein Netzwerk und du findest schneller Hilfe.
  
  Gruß
  Martin
  Antworten
Stefan sagt:

11. Februar 2020 um 16:34 Uhr

Hallo Martin,
habe deinen sehr interessanten Bericht gelesen. Kann man deine config.gateway.json 1:1 übernehmen oder muss ich da noch was individuell anpassen?
Habe jetzt richtig Lust bekommen mein kleines Netzwerk vernünftig aufzubauen.

Viele Grüße
Stefan

Antworten
1. Martin Ziegler sagt:
  
  1. März 2020 um 17:05 Uhr
  
  Hallo Stefan,
  wenn “alles außenrum passt” kannst du die Konfiguration 1:1 übernehmen.
  Gruß
  Martin
  
  Antworten
Christopher Lee sagt:

14. Februar 2020 um 16:10 Uhr

Sehr schöner Artikel und interessante Kommentare…

…leider kann ich PPPoE bei mir nicht einrichten sonst hätte ich es gleich ausprobiert (bin bei der Telekom und die erlauben lt. Fritz-Webseite keine zweite Einwahl mit den gleichen Daten). Nun muss ich also die USG als “Exposed Host” verwenden und stoße dort an ein paar Grenzen:

1. UPnP kann ich nicht verwenden – funktioniert weder wenn ich es nur im USG konfiguriere oder zusätzlich auf der Fritzbox – ich hätte gedacht dadurch, dass das alles weitergeleitet wird an die USG brauche ich es nur im USG zu aktivieren.

2. Portweiterleitung scheint nicht richtig zu funktionieren. Habe eine Weiterleitung von zwei Ports UDP auf die IP meines Spielerechners, doch das Spiel meldet: “NAT Moderate” – was im Klartext heisst, dass der Traffic nicht weitergeleitet wird. Seltsamerweise sagt ein tcpdump am interface eth1 auf der USG jedoch was ganz anderes. Eine OpenVPN Verbindung mit eier Weiterleitung auf den entsprechenden Endpunkt läuft auch. NAT-Regel 5999 ist auch aktiv.

Hat jemand UPnP sauber am laufen ohne PPPoE und kann hier verklickern was er dazu tun musste?

Antworten
1. Martin Ziegler sagt:
  
  1. März 2020 um 17:13 Uhr
  
  Hallo Thomas,
  wenn du das im Artikel beschriebene Vorgehen umsetzt und NAT auf dem USG deaktivierst (“PPPoE” und “Exposed Host” sind Varianten, die in den Kommentaren beschrieben werden, nicht im Artikel), sollte es für deinen PC keinen Unterschied machen ob er direkt an deinem Router oder hinter dem USG hängt. Habe ich erfolgreich mit der PS4 testen können.
  Mit welchen Spiel hast du Probleme? Vielleicht habe ich es auch und kann schauen, wie es sich bei mir verhält.
  Portweiterleitungen (auf dem USG) sind nicht notwendig, wenn der Artikel umgesetzt wurde. Portweiterleitungen auf der FritzBox zum PC können helfen, wenn UPnP nicht funktioniert.
  Gruß
  Martin
  
  Antworten
  1. Christopher Lee sagt:
    
    1. März 2020 um 23:13 Uhr
    
    Hi Martin,
    
    das Spiel um das es hier geht ist in der Grundversion sogar Free2Play: Destiny 2. NAT ist auf USG deaktiviert (Regel 5999).
    
    Im Moment verwende ich die USG als “Exposed Host” und eine Portweiterleitung auf die endgültige IP-Adresse des Spielerechners. Eine weiterleitung an die USG und die Konfiguration einer Portweiterleitung in der USG brachten übrigens den gleichen Effekt: “NAT Moderate”.
    
    Würde ich UPnP der Fritzbox verwenden dann müsste diese ja auch den DHCP-Server stellen sonst funktioniert das nicht wie man in vielen Foreneinträgen nachlesen kann.
    
    Danke sehr,
    Chris
    
    Antworten
    1. Martin Ziegler sagt:
      
      3. März 2020 um 21:49 Uhr
      
      Hallo Chris,
      NAT Type 2 (Moderate) ist der “gute” NAT Mode, wenn du hinter einem Router hängst. Problematisch ist Mode 3. Wenn du unbedingt Type 1 erreichen möchtest, gehst du mit dem Exposed Host (der bei deaktiviertem NAT auf dem USG dein PC sein sollte, mit Firewallregeln, die den Zugriff von der IP deiner FritzBox “durch” das USG auf deinen PC erlauben anstelle von Portweiterleitungen) das Risiko ein, dass dein Windows?-PC direkt im Internet hängt.
      
      Ich schau mit Destiny 2 am Wochenende mal an – vielleicht kann ich deine UPnP Probleme nachvollziehen.
      
      UPnP und DHCP haben erst mal nichts miteinander zu tun. Ich kenne die Foreneinträge nicht, aber eventuell wird dort die Hypothese aufgestellt, dass UPnP nicht über Subnetze hinweg funktioniert.
      
      Gruß
      
      Martin
      
      Antworten
      1. Christopher Lee sagt:
        
        6. März 2020 um 9:39 Uhr
        
        Hi Martin,
        
        Mode 2 bekomme ich locker hin und ja ich möchte für diese beiden Ports den Rechner direkt ins Internet hängen.
        
        Hier steht das z.B. mit dem UPnP und der Fritzbox ohne DHCP – ich habe es ausprobiert damals (hatte auch nur ein flaches Netzwerk aus einem Netz) und hatte tatsächlich das gleiche Problem: https://forum.vodafone.de/t5/Archiv-Internet-Telefon-TV-über/Fritzbox-6490-UPnP-nur-wie/m-p/1375355#M208853
        
        Also UPnP + Fritzbox ohne DHCP geht nicht und UPnP hinter der Fritzbox trotz Exposed Host geht auch nicht. Ist nicht wirklich schlimm für mich aber interessieren warum es nicht funktioniert tut es mich schon.
        
        Gruß,
        Chris
        
        Antworten
        
        Martin Ziegler sagt:
        
        7. März 2020 um 8:35 Uhr
        
        Hallo Chris,
        
        wenn du einen (oder mehr) definierte Ports eines Rechners vom Internet aus direkt erreichbar machen willst, musst du.
        Beispiel Port 8080 auf PC 192.168.12.34/24 hinter USG 192.168.0.250 und FritzBox 192.168.0.1:
        
        Dienst hinter Port 8080 auf dem PC starten und sicherstellen, dass der Zugriff nicht durch eine Firewall blockiert wird.
        
        USG: Firewallregel, die den Zugriff von 192.168.0.1 auf 192.168.12.34:8080 erlaubt konfigurieren.
        
        FritzBox: Freigaben -> statische Portfreigaben -> Gerät für Freigabe hinzufügen | Gerät: IP-Adresse manuell hinzufügen <192.168.12.34> | hier gibt es auch die Option selbstständige Portfreigaben für dieses Gerät zu erlauben (UPnP), oder das Gerät als Exposed Host zu konfigurieren (benötigt eine umfassendere Firewallfreischaltung auf dem USG) |Neue Freigabe -> Einstellungen abhängig von deinen Anforderungen.
        
        UPnP Geräte finden sich “eigentlich” (unter anderem) über Multicast. Das lässt sich theoretisch von einem Reflektor in andere Subnetze übertragen. Hat direkt nichts mit DHCP zu tun. Ob die FritzBox gewisse Dienst nur dann aktiviert, wenn auch DHCP aktiv ist, habe ich bisher nicht festgestellt – hatte diese Fragestellung bisher aber auch noch nicht.
        
        Gruß
        Martin
        
        Antworten
        
        Martin Ziegler sagt:
        
        8. März 2020 um 22:11 Uhr
        
        Hallo Chris,
        ich habe mir das Verhalten von ~~Halo~~ Destiny 2 etwas genauer angeschaut. Da die bisherige Analyse zu weit von diesem Beitrag weg ist, habe ich einen eigenen Artikel angelegt Probleme bei der Portfreigabe über UPnP von Systemen hinter einem USG ohne NAT und einer FRITZ!Box. Kurz: UPnP ist nicht das Problem, sondern nach aktueller Analyse IGMP und SSDP.
        Vielleicht hilft dir der Stand der Analyse schon etwas das Problem besser eingrenzen zu können – eine elegante Lösung habe ich leider noch keine. Mir hat deine Frage sehr geholfen, da ich das Problem einiger anderer Fragen beim aktuellen Beitrag wohl in der Vergangenheit nicht korrekt verstanden habe. Für mich war NAT-Typ 2 in Ordnung und ich habe nicht verstanden, warum jemand NAT-Typ 1 unbedingt benötigt. Bei mir ging alles und ich spiele eventuell inzwischen zu wenig 😉
        
        Ich hoffe, für das Problem noch eine Lösung zu finden – muss etwas nachdenken. Bin offen für Anmerkungen und Vorschläge.
        
        Gruß
        Martin
        
        Antworten
        
        Christopher Lee sagt:
        
        9. März 2020 um 9:28 Uhr
        
        Hi Martin,
        
        Super Sache!
        
        Dann werde ich dort entsprechend weiterkommentieren 🙂
        
        Ich danke dir!
        
        Chris
        
        Antworten
Sebastian Kessler sagt:

18. Februar 2020 um 22:47 Uhr

Hallo Martin.

Erst einmal besten Dank für dein Tutorial.

Ich hab den uSG auch seit heute und verzweifelt etwas daran .

Ich habe die fritzbox 7430 also Modem /DHCP laufen und dahinter hätte ich gerne den USG.

Die Ip der FB :192.168.2.1
IP des USB am LAN 1 :192.168.2.200

Schließe ich den USG an WAN an habe ich die IP des USG 192.168.2.122 und ist dann nicht mehr über den Controller erreichbar .

Kannst du vielleicht ein paar tips Geben wie ich das hin bekommen?

Danke

Und Gruß
Sebastian

Antworten
1. Martin Ziegler sagt:
  
  1. März 2020 um 17:19 Uhr
  Hallo Sebastian,
  
  Wenn die IP der FritzBox im Subnetz 192.168.2.0/24 ist, darf die IP des USG LAN 1 nicht auf dem Subnetz 192.168.2.0/24 sein. Aber: Die IP des WAN-Anschluss deines USG muss aus 192.168.2.0/24 sein.
  
  Beispiel:
  1. FritzBox: 192.168.2.1/24
  2. USG-WAN: 192.168.2.200/24 (an einem LAN-Port der Fritz Box, per DHCP von der FritzBox bekommen)
  3. USG-LAN: 192.168.10.1/24 (+ alle anderen VLANs, die du im USG konfigurierst.
  Hilft dir das weiter?
  
  Gruß
  
  Martin
  Antworten
Steffen sagt:

19. Februar 2020 um 16:30 Uhr

Hallo zusammen,
vielen Dank für Martin für die tolle Anleitung.
Ein Problem habe ich aktuell noch, und zwar kann ich in meiner Fritzbox keine Freigaben erstellen. Ich bekomme immer den Hinweis, dass ein anderes Gerät die IP Adresse benutzt.
Unter Heimnetz –> Netzwerk sehe ich nur noch das Gateway (z.B. 192.168.0.2, Fritzbox IP 192.168.0.3 und das USG Subnet 192.168.1.0/24) als aktive Verbindung. Wenn ich darauf klicke kommen ich jedesmal auf ein anderes Netzwerkgerät, dass hinter dem USG angeschlossen ist.
Woran kann das liegen, dass ich in der Fritzbox keine Portfreigaben für Geräte hinter dem USG erstellen kann?

Antworten
1. Martin Ziegler sagt:
  
  1. März 2020 um 17:24 Uhr
  
  Hallo Steffen,
  generell funktioniert das. Ich habe bei mir Ports der FritzBox auf Geräte hinter dem USG weitergeleitet. Hast du NAT wie im Artikel beschrieben auf dem USG deaktviert? Wenn nicht, musst du von der FritzBox auf dein USG weiterleiten und auf dem USG eine 2. Weiterleitung auf dein Zielsystem konfigurieren.
  
  Hoffe, das hilft dir etwas weiter.
  
  Gruß
  
  Martin
  
  Antworten
  1. Steffen Böck sagt:
    
    2. März 2020 um 11:20 Uhr
    
    Hallo Martin,
    
    das NAT ist deaktiviert. Habe ich auch getestet. Es muss wohl irgendwie an ipv6 Einstellungen gelegen haben. Ich habe diese in der Fritzbox und an meinem QNAP (hat 4 Netzwerkanschlüsse, dass kann wohl zu Problemen bei der Fritzbox führen) deaktiviert. Das hat mir geholfen und ich konnte die Portweiterleitungen manuel in der Fritzbox anlegen. Anschließend habe ich IPV6 auf der Fritzbox wieder aktiviert. Das hat mir geholfen und jetzt funktioniert alles so wie es soll 🙂
    Vielen Dank für deine Anleitung.
    
    Gruß
    
    Steffen
    
    Antworten
Fraggle sagt:

2. März 2020 um 11:11 Uhr

Hallo, wunderbare Anleitung. Funktioniert auch alles soweit, allerdings ein Problem. Wenn ich über VPN von außen komme kann ich meine Geräte über das Zwischenetz nur mit der IP ansprechen. Die Namensauflösung der Fritzbox greift nicht, da die Fritzbox nur in dem Transfernetz eine DNS-Auflösung macht, aber nicht zu dem Unifi-LAN-Netz. DNS im LAN-Netz funktioniert einwandfrei, allerdings scheint die USG dies nicht auf dem WAN-Port zur Verfügung zu stellen. Es hilft auch nicht in der Fritzbox den DNS-Server auf den WAN-Port des USG zu legen.

Antworten
1. Martin Ziegler sagt:
  
  3. März 2020 um 21:58 Uhr
  
  Hallo Fraggle,
  ich habe bei mir die /etc/hosts (C:\Windows\System32\drivers\etc\hosts) für den Zugriff per VPN gepflegt. Der DNS des USG könnte durch das Öffnen des Port 53 in der Firewall des USG für deine VPN-IPs zugänglich gemacht werden. Habe ich bisher noch nicht getestet.
  Gruß
  Martin
  
  Antworten
Heiko Graumann sagt:

2. März 2020 um 13:05 Uhr

Hallo zusammen,

zuerst einmal vielen Dank für diese geniale Anleitung. Demnächst werde ich mein komplettes Netzwerk auf Unifi umrüsten und habe dazu auch schon so ziemlich alle Unifi-Geräte wie USG, Switch, AP etc. hier rumliegen.
Eine Frage beschäftigt mich jedoch trotzdem noch. Muss das NAT auf dem USG per config.gateway.json bereits ausgeschaltet sein bevor ich das USG zum ersten Mal an die Fritzbox an Lan 1 anschließe oder kann ich das USG gleich in die Fritzbox stöpseln und im Anschluss daran dann das NAT auf dem USG ausschalten ?
Ist die Reihenfolge also relevant für die Funktion oder ist das egal ?

Danke und Gruß

Heiko

Antworten
1. Martin Ziegler sagt:
  
  3. März 2020 um 21:55 Uhr
  
  Hallo Heiko,
  du kannst alles aufbauen und nutzen ohne NAT im USG zu deaktivieren (das ist der von Ubiquiti vorgesehene Betriebsmodus). Wenn du irgendwann NAT im USG deaktivieren willst, einfach die Route(n) in der FritzBox konfigurieren und NAT auf dem USG per config.gateway.json ausschalten.
  
  Gruß
  
  Martin
  
  Antworten
  1. Heiko Graumann sagt:
    
    5. März 2020 um 17:19 Uhr
    
    Hallo Martin,
    vielen Dank für die schnelle Antwort. Ich werde dann erst alles wie gewünscht aufbauen und dann NAT auf dem USG ausschalten.
    Eine Frage hätte ich jedoch noch zur Portweiterleitung auf der Fritzbox und dem USG. Ich möchte nämlich nicht die Variante mit dem “Exposed Host” nutzen sondern lieber gezielt einzelne Portfreigaben tätigen.
    Ich weiß, dass ich in der Fritzbox sowie im USG die Portweiterleitung einrichten muss.
    
    Beispiel:
    
    Fritzbox: 192.168.178.1
    USG-WAN: 192.168.178.200/24
    USG-LAN: 192.168.10.1/24
    NAS: 192.168.10.100
    
    Wenn ich z.B. den Port 7000 auf das NAS leiten möchte, würde die Weiterleitung dann in der Fritzbox auf die IP des USG-WAN weitergeleitet werden, also 192.168.178.200 (Gateway) oder direkt auf die IP des NAS im Netz des USG, also 192.168.10.100 ?
    Im USG müsste ja Port 7000 auf jeden Fall auf die IP 192.168.10.100 weitergeleitet werden, sonst macht es ja eigentlich keinen Sinn.
    Also Weiterleitung auf das Gateway des USG und von dort dann auf das NAS oder in der Fritzbox direkt auf das NAS ?
    Da hab ich gerade irgendwie eine Denkblockade 🙂
    
    Gruß Heiko
    
    Antworten
    1. Christopher Lee sagt:
      
      6. März 2020 um 9:27 Uhr
      
      Hey Heiko,
      
      ich habe ein ähnliches Setup und ich muss tatsächlich die Weiterleitung auf die End-IP (also in deinem Falle 192.168.10.100) machen sonst erkennt mein Spiel zum Beispiel die Weiterleitung nicht richtig und meldet mir es wäre geNATet. Natürlich brauchst du noch eine entsprechende Freigabe in der USG damit der Traffic nicht geblockt wird.
      
      Gruß,
      Chris
      
      Antworten
      1. Heiko Graumann sagt:
        
        6. März 2020 um 10:18 Uhr
        
        Hallo Chris,
        
        vielen Dank für die Information. Damit kann ich dann ab heute Nachmittag beginnen mein Netzwerk komplett auf Unifi umzustellen.
        Allen hier ein angenehmes Wochenende.
        
        Gruß,
        Heiko
        
        Antworten
        
        Heiko Graumann sagt:
        
        6. März 2020 um 19:16 Uhr
        
        Hallo Zusammen,
        
        habe mein Netzwerk umgekrempelt, das USG, Switch sowie CloudKey Gen2+ installiert und es läuft.
        Was ich jetzt nach stundenlangem Probieren nicht schaffe ist es per SSH die Config.Gateway.Json auf den CloudKey zu übertragen.
        Ich bekomme nicht mit meinem Nutzer Heiko_69 Zugang per SSH sondern nur als Root.
        Dabei finde ich dann aber nicht den Ordner /srv/unifi/data/sites/default und kann auch somit nicht die Datei dort ablegen.
        Gibt es hier jemanden, der mir beim Cloudkey Gen2 + sagen kann, wo die Datei abgelegt werden muss ?
        Oder liegt es daran, dass mein Nutzer Heiko_69 irgendwie keinen SSH-Zugang erhält.
        Hoffe auf schnelle Hilfe, denn ich komme irgendwie nicht weiter.
        
        Gruß Heiko
        
        Antworten
        
        Martin Ziegler sagt:
        
        7. März 2020 um 8:16 Uhr
        
        Hallo Heiko,
        wenn du als root/ubnt Zugriff auf dein USG bekommst, ist das in Ordnung. So hast du auch genug Rechte die Datei anzulegen. Wenn es den Pfad zu der Datei nicht gibt, kannst du die entsprechenden Verzeichnisse anlegen (Details). Wenn du die Verzeichnisse nicht manuell anlegen willst, kannst du alternativ für jede deiner Sites bei den Einstellungen unter Gaststeuerung die Optionen Gastportal aktivieren und Vorlagen mit eigenen Anpassungen überschreiben anklicken und die Änderungen übernehmen. Dadurch werden die Verzeichnisse angelegt und bleiben auch bestehen, wenn du die Optionen wieder deaktivierst.
        Gruß
        Martin
        
        Antworten
        
        Heiko Graumann sagt:
        
        7. März 2020 um 11:27 Uhr
        
        Hallo Martin,
        
        tausend Dank nochmals für deine tolle und vor allem kompetente Hilfe. Gestern noch hätte ich das USG samt Zubehör fast gegen die Wand geworfen 🙂
        Ich habe es gefühlt bestimmt 10 mal auf Werkszustand zurückgesetzt und es wollte und wollte nicht funktionieren.
        Letztlich, aus welchem Grund kann ich nicht sagen, konnte ich dann doch alles einrichten.
        Jetzt müsste ich nur noch ein Controller-Update machen von 5.11 auf 5.12 und habe davor ein wenig Bammel.
        Nicht, dass die Probleme meines gestrigen Scheiterns an den vielen Updates lag, die sämtlich Geräte gestern mehr oder weniger gut überstanden haben.
        Deshalb auch dazu noch eine Frage von mir:
        Sollte sich der Controller aus welchem Grund auch immer mal zerlegen, macht man das einfach einen Werksreset und spielt dann das vorhandene Update ein oder welche Möglichkeiten gibt es ?
        Läuft gerade alles so gut, da will ich nichts kaputt machen 🙂 Von daher warte ich mit dem Unifi-Controller-Update noch deine Antwort dazu ab.
        
        Gruß Heiko
        
        Antworten
        
        Martin Ziegler sagt:
        
        8. März 2020 um 22:19 Uhr
        
        Hallo Heiko,
        an die Wand werfen kann manchmal befreiend wirken, hilft langfristig aber selten wirklich weiter. Controllerupdates liefen bei mir bis auf einmal ohne Probleme. ich habe den CloudKey. Hier kannst du zwischen Firmware (mit Anwendung) und Anwendung wählen. Ich hatte nur die Anwendung aktualisiert, dann gesehen, dass es auch ein Firmwareupdate gab. Leider war die Anwendung in der Firmware älter als die von mir bereits installierte und das Datenmodell des Controllers hat nicht mehr gepasst. Zum Reparieren musste ich per SSH auf den CloudKey und die aktuelle Version der Anwendung manuell installieren.
        Ansonsten: Wenn du ein Backup hast, einfach einspielen. Hat bei mir bisher zumindest immer (immer = nur einmal benötigt, weil ich das SSH Passwort “vergessen” habe) funktioniert 😉
        
        Gruß
        
        Martin
        
        Antworten
        
        Heiko Graumann sagt:
        
        9. März 2020 um 15:36 Uhr
        
        Hallo Martin,
        
        vielen Dank für deine Antwort. Habe mir das mit dem SSH Zugriff auch schon zusammen gesucht.
        Im Moment stehe ich jedoch auch schon vor dem nächsten, für mich nicht zu erklärenden Problem, nämlich das Einbinden meines Synology NAS.
        Dachte eigentlich, das ich das einfach nur an den Switch stecke, im Controller schaue, welche IP es erhalten hat, drauf zugreifen und los gehts.
        Leider klappt das nicht. Im Controller ist die IP des NAS zu sehen, es kommt beim Zugriff jedoch immer zu einem Timeout.
        Auch mit dem Synology Assistent klappt der Zugriff nicht, da NAS nicht gefunden wird.
        Vielleicht hast du ja, oder auch jemand anders hier im Forum, eine Lösung für mich oder noch etwas, was ich versuchen könnte.
        Das NAS ist bei den Netzwerkeinstellungen auf DHCP, so dass dies passen sollte. Ist eine DS 114, falls benötigt.
        Vielen Dank und lieben Gruß,
        
        Heiko
        
        Felix sagt:
        
        9. März 2020 um 19:22 Uhr
        
        Hallo Heiko,
        
        ich kann direkt leider nicht auf deinen Beitrag antworten, deshalb versuche ich es hier.
        Ich besitze ebenfalls ein Synology. Die IP reicht nicht aus. In Abhängigkeit zu deinen Einstellungen in der NAS und der Firewall benötigst du noch den Port. Der Standard-Port der Synology ist 5000 für http und 5001 für https. Je nach Sicherheitseinstellung geht nur https://192.168.0.0:5001. IP ist natürlich nur ein Beispiel und den Port solltest du nach Möglichkeit auch ändern, wenn nicht bereits geschehen. Dann solltest du direkt zur Login-Maske des NAS kommen.
        Wenn du DDNS nutzt und via (Sub-)Domain auf die NAS zugreifen willst musst du in der Fritzbox und der Unifi-Firewall die IP und den Port dementsprechend zuweisen.
        
        Gruß
        Felix
Kai sagt:

4. März 2020 um 9:41 Uhr

Hallo Martin und alle Beitragenden,
auch von mir vielen Dank für diese geniale Anleitung und die super konstruktiven Beiträge! Ich stelle mein Netzwerk auch gerade auf UniFi um – Controller, Switches und AP sind bereits vorhanden und laufen schon. Gestern kam das USG, welches nun in das bestehende Netz integriert werden soll.
Ich habe mich als FritzBox-Besitzer für die Variante “hinter die FritzBox” entschieden (also ohne doppeltes NAT mit der JSON-Konfigurationdsatei).
Jetzt habe ich noch eine Rookie-Frage zum UniFi Controller: sobald das USG läuft, kann ich im Controller in den (LAN-) Netzwerkeinstellungen Gateway und Subnet angeben. Das USG wird zur FritzBox hin (WAN1) beispielsweise eine Adresse aus deren Netz 192.168.0.0 erhalten, soll nach “innen” aber das Netzwerk 192.168.10.0 verwalten (LAN1).
Da ich mit dem Controller zunächst erstaml mein Netzwerk “hinter” dem USG verwalte, muss ich hier als Gateway/Subnet das Netzwerk 192.168.10.0 eintragen, oder?

Vielen Dank und viele Grüße
Kai

Antworten
Kai sagt:

5. März 2020 um 13:57 Uhr

Hallo Martin,
ah, jetzt habe ich es kapiert. 🙂
USG ist installiert, FritzBox läuft, ich bin wieder am Netz Dank Deines tollen Blogs!
Von mir aus brauchst Du meinen vorigen Beitrag bzw. Frage zum UniFi Controller nicht zu veröffentlichen – wie Du möchtest.
Danke Dir nochmals!!!
Viele Grüße
Kai

Antworten
1. Martin Ziegler sagt:
  
  7. März 2020 um 8:17 Uhr
  
  Hallo Kai,
  
  freut mich wenn es funktioniert!
  
  Gruß Martin
  
  Antworten
Marcus Reppel sagt:

8. März 2020 um 18:44 Uhr

Hallo zusammen
ein super Beitrag und viele aufschlussreiche Kommentare. Wir ziehen per August 2020 um und dann werde ich vom Kabelmodem auf VDSL umsteingen. Zu diesem Zweck habe ich mir bereits eine Fritzbox 7590 zugelegt. Die Fritzbox hängt im Moment hinter dem USG (nur Telefonie). Ich würde gerne die FritzApp auch von unterwegs nutzen um Anrufe angezeigt zu bekommen – leider habe ich es noch nicht geschafft die IPv6 Portweiterleitung USG-Seitig richtig zum laufen zu bringen – von extern komme ich nicht via App/MyFritz auf die Box. Eine IPv6 Adresse wurde der Box zugeteilt.
Hat jemand ein ähnliches Setup das läuft? Falls ja, wie genau muss ich vorgehen?

Danke und liebe Grüsse
Marcus

Antworten
1. Martin Ziegler sagt:
  
  8. März 2020 um 22:30 Uhr
  Hallo Marcus,
  ein paar Fragen, um dich besser zu verstehen:
  - Möchtest du ab August deine FritzBox “vor” das USG hängen? Wenn ja, suchst du bis August oder für danach eine Lösung?
  - Bekommst du neben IPv6 auch eine IPv4 Adresse von deinem Provider? Wenn nein, hast du unterwegs eine IPv6 Adresse? Mein Mobilfunkanbieter bietet mir zum Bespiel keine an.
  - Willst du deine FritzBox “offen” ins Internet stellen oder per VPN eine (dauerhafte/on demand-Verbindnug) in dein Netz aufbauen?
  Ich habe mein Handy so konfiguriert, dass es bei Bedarf eine VPN Verbindung in mein Netz aufbaut. Wenn ich dann die FRITZ!Fon-App starte kann ich telefonieren und Gespräche entgegennehmen. Das mache ich aber nur ganz gezielt, da die App meist keine Verbindung hat oder sich abmeldet. Ich habe es eher wegen des Basteltriebs eingerichtet – wirklich gebraucht habe ich es noch nicht. Daher habe ich mich nicht weiter darum gekümmert, dass es nur zuverlässig geht, wenn ich es bewusst starte.
  
  Gruß
  
  Martin
  Antworten
Heiko Graumann sagt:

9. März 2020 um 20:55 Uhr

Hallo Felix,
vielen Dank für deine Hilfe aber das Problem war die Firewall auf dem NAS. Hatte vor dem Netzwerkumbau vergessen dieses auszuschalten.
Nachdem diese deaktiviert wurde war ein Zugriff, wie von dir beschrieben, wieder möglich.
Vielen Dank nochmals und für diesen tollen Blog.

Gruß Heiko

Antworten
Vetti52 sagt:

15. März 2020 um 21:16 Uhr

Dieser Blog ist sogar für mich nachvollziehbar. 😉 Besonders begeistert mich, dass auch die Quellen verlinkt sind. Jetzt bin ich kurz davor, mir eine USG zu beschaffen.
Allerdings weiß ich an einem Punkt noch gar nichts: Geht es bei meinem Szenario auch ohne Fritzbox?
Mein Netzwerk sieht so aus:
Provider -> FTTH mit DualStack -> Genexis Abschluß -> GB-Net -> Fritzbox -> Switch(UAC|NAS|RPI4).
Die Fritzbox bedient auch per ISDN eine interne Telefonanlage und an LAN1/Switch auch IP-Telefonie. LAN4 geht an Powerline ins Nebengebäude, außer Strom ist dort keine Infrastruktur, dort Switch mit UAC und devolo Outdoor-AC.
Die FB 7580 geht bereits 2022 auf ihr Support-Ende zu. Ich würde sie daher gerne bis dahin durch die USG ersetzen.

Allerdings….
Was ist mit Telefonie?

Und auf dem RPi4 läuft der Unifi Controller, dazu Home-Assistant mit einem ZigBee deConz Gateway und Weewx, das ständig von einer Wetterstation mit Daten beliefert wird und an Windy weiter gibt. Diese Station funkt per WLAN und muss, damit ich sie per Smartphone bedienen kann, im gleichen Heim-Netzwerk laufen. Das gesamte smart home würde ich gerne isolieren. Aber ich werde AUF KEINEN FALL die Einstellungen in der Wetterstation ändern. Noch einmal mache ich den Mist mit der WSView-App nicht mehr mit.
Sämtliche Geräte, die dauerhaft im Heimnetz sind, werden in der FB mit einer festen IP-Adresse per DHCP aus dem Bereich 192.168.100.0 versorgt. Einige, Server, alter Drucker, haben eine statische IP-Adresse, die jedoch auch in der FB als feste Adresse angelegt ist, quasi as Erinnerung. Alle “festen” Adressen sind außerhalb des dynamischen Adress-Bereiches, so dass Neulinge ohne Konflikte eine Adresse erhalten werden.
Nachts schalte ich das UAC-WLAN komplett aus, bis auf die FB, die mit 6% Leistung gerade so ausreicht, um die Signale der Wetterstation zu empfangen, die rund um die Uhr Daten sendet. Es könnten gerne noch weniger als 6% sein, denn die Geräte stehen in einem Raum nahe beieinander, und alle anderen Geräte sollten nachts keinen WLAN-Kontakt mehr bekommen. Die SSID ist ja für alle die gleiche, einmal fürs Roaming und, damit das Smartphone die Verbindung zur Wetterstation halten kann. Das WLAN-Gastnetz der FB habe ich ausgeschaltet, aber eines im Controller – für Gäste – eingerichtet. So weit mein WLAN-Verständnis…

Bei meinem Vorhaben, ein USG einzubinden, gehe ich wohl anders vor, als manche hier in der Runde es gemacht haben, denn ich habe kein USG herum liegen. 😉 Daher habe ich auch noch kein Spielzeug, um heraus zu bekommen, wie es eigentlich eingerichtet werden muss. Die Schnellanleitung von Ubiquity hilft mir da nicht weiter. Und ohne ein USG im Controller gibt es für mich im GUI auch keine Spielwiese.
Meine Skills liegen zwar durchaus auch auf der CLI, allerdinge war ich von Anfang an ein Fan von “grafischer Benutzeroberfläche”, sprich, zu meinen Anfängen hieß die noch “Norton Commander”. Auch heute gehört auf dem RPi als erstes der Befehl “sudo apt-get install mc” zur Pflicht, um den Midnight Commander zu installieren. bash verliert für mich dadurch einiges an Schrecken.

Der Controller läuft im RPi-Docker. So weit reicht der Midnight Commander leider nicht. Die json-Datei, wie auch immer sie aussehen wird, muss ich also noch händisch dort hinein bringen. Der Rest ist hoffentlich einfacher….

Die Intro ist ein bisschen lang…. Sorry

Trotzdem bin ich jetzt gespannt, wie Lösungsvorschläge aussehen. 🙂

Antworten
1. Martin Ziegler sagt:
  
  24. März 2020 um 7:19 Uhr
  Hallo,
  
  es freut mich, wenn dir der Artikel lesbar und verständlich ist.
  
  Zu deinen Themen – wenn ich etwas übersehen oder unzureichend geantwortet habe, einfach nachfragen:
  - Geht es auch ohne FritzBox: generell ja.
  - Welches Produkt von Genexis hast du? Bzw. die eigentliche Frage ist: bekommt deine FritzBox direkt eine IP von der Genesis Box oder baut sie selbst eine Verbindung zu deinem Provider auf?
  - Da die FritzBox auch eine interne ISDN Anlage bedient, wäre der einfachste Weg, dass du sie – wenn sie nicht “vor” dem USG hängen soll, dahinter nimmst.
  - Alternativ für die Telefonie: Asterisk mit ISDN Karte – Sicher ein lohnendes Projekt für sich alleine. Habe ich aber selbst noch keine Erfahrung damit.
  - Anbindung deines Nebengebäudes per PowerLAN: Geht auch “hinter” dem USG.
  - UAC (User Account Control von Windows?) – bin mir nicht sicher, ob ich es richtig zuordne. Meinst du Ubiquiti UniFi Access Point (UAP)? Oder, dass du nur UniFi AccessPoint mit “AC” (IEEE 802.11ac) im Einsatz hast?
  - devolo Outdoor-AP: Lässt sich mit UniFi kombinieren, der Vorteil, dass du alle WLAN-Komponenten gemeinsam verwalten kannst, geht dir dadurch verloren. Dafür hast du aktuell ein Stück Hardware weniger.
  - SmartHome isolieren, ohne die Wetterstation mit anderer IP zu konfigurieren: Dafür kannst du 192.168.100.0/24 nehmen – für alle anderen Geräte müssten dann umziehen.
  - Das WLAN der FritzBox würde ich persönlich nicht weiterverwenden (wie auch den devolo Outdoor-AP). Unverwaltete Geräte helfen aus meiner Erfahrung heraus nicht unbedingt bei der Fehleranalyse in einem ansonsten verwalteten Umfeld.
  - json Datei zur USG Konfiguration im Dockercontainer: Du kannst bei Docker Verzeichnisse angeben, die in den Container gemounted werden. So kannst du auf die json-Datei mit mc oder vi zugreifen.
  - bash ist doch nicht schrecklich – spätestens, wenn du heute nochmal mit DOS 6.22 in Kontakt kommst, erkennst du die der bash innewohnende Ästhetik. Natürlich war damals der Norton Commander auch schon praktisch 😉
  Ich hoffe du kannst mit den Anmerkungen etwas für dich anfangen. Ansonsten gerne nachfragen.
  
  Gruß
  
  Martin
  Antworten
  1. Vetti52 sagt:
    
    27. März 2020 um 22:03 Uhr
    
    Hallo, Martin!
    Erst mal herzlichen Dank für deine Erklärungen.
    
    Schon deine erste Frage stellte mich vor Probleme:
    – Die Genexis Serie, aus der meine Box ist, gibt es nicht mehr (Der FTTH-Anschluss kam damals im Rahmen einer “Pilot-Phase” einiger sehr reger Akteure hier im Landkreis). Mit Google-Bildersuche habe ich herausgefunden, dass es sich um die Genexis FiberXport OCG-1020m handeln muß. Also gibt’s keine Routerfunktionen. Die FB muss die Verbindung per “Anschluss an externes Modem oder Router” und “Internetverbindung selbst aufbauen”. Die Verbindung erfolgte entweder über “WT-Dynamic-CGN-LSN-Pool” oder “WT-PPPOE-PRIVATE-CUSTOMER” Letzteres ist seit ca 1 Jahr Standard, aber, wer weiß.
    
    – Die Idee mit Asterisk hatte ich mal vo 15 Jahren in der c’t gelesen und angedacht, mit dem Hintergrund, dass damals im ganzen Gebäude eine ISDN-Bus-Verkabelung mit CAT3 Kabeln installiert und ein Internet-Proxy an einer (Fritz)-ISDN-Karte installiert wurde. Dort sollte eigentlich auch Asterisk installiert werden. Dann gab es aber von Quante eine schicke kleine ISDN-Telefonanlage mit internem S0-Bus. Tja, das Teil läuft noch immer, jetzt hinter der FB.
    
    – Es sind UAP-AC, war wohl zu schreibfaul, sorry. Das gesamte Wohngebäude versorgt ein einziger UAP-IW-HD, das Nebengebäude ein UAP-AC-LR und demnächst kommt der UAP-AC-M-PRO, der den dLAN outdoor ersetzen soll. Das Management sehe ich genauso, wie du. Wer also Interesse an einem Outdoor dLAN hat…. 🙂
    
    – Das Smarthome isolieren, steht erst im zweiten Schritt an. Erst mal soll alles hinter der USG vernünftig laufen. Vermutlich komme ich dafür nicht um einen managed switch herum, bin aber in die Richtung noch komplett unbeleckt. Für die Wetterstation-Console ist es unwesentlich, welche IP-Adresse sie per WLAN erhält. Sie hat aber per abenteuerlicher Hotspot-Einstellung SSID und Passwort erhalten und bucht sich damit ein, wo immer ein 2,4MHz Netz sie rein läßt. Mein Problem ist hier lediglich, dass ich gerne eine kleine WLAN-Insel hätte, die auch nachts durchlaufen kann, wobei das gesamte übrige Areal WLAN-frei sein soll. Mit Einsatz der UAP-ACs sind die Inseln allerdings eher Kontinente. Da fehlt mir noch eine gute Idee.
    Später benötige ich noch zu WLAN Nachhilfe, z.B., ob ich die gleiche SSID in verschiedenen IP-Adressbereichen haben kann, und, wie ich Geräte im smart home z.B. per smart phone steuern kann, die aber ihrerseits nicht herum spionieren dürfen.
    
    – Da ich ja nicht ständig in Docker reinpfuschen muss, reicht mir auch einmalig der Docker-Befehl “docker cp src_path dest_path”. Muss halt nur den richtigen Pfad in Docker-Container wissen.
    
    – Und, ja, neben den klassischen F3, F4 Tasten nutze ich im Midnight Commander am häufigsten CTRL-0, also eine neue Shell. Die bash braucht es halt fast täglich….
    
    Jetzt sollte ich mich mal an die USG wagen. An der FB habe ich schon eine statische Route in das Netz 192.168.1.0 gesetzt und auch prompt die USG, mit LAN1 verbunden, zu sehen bekommen. Man kann’s ja nicht lassen: Da ist eine Buchse, da ist ein Stecker, passt!
    Weiter bin ich leider nicht gekommen, im Controller wird sie gezeigt, aber Adoption failed. Vermutlich, weil sie noch nichts an WAN1 hängen hatte? Danach hatte ich im Controller neben dem LAN-Netz noch ein zusätzliches WAN-Netz, das so erstmal total mistig war und zudem keinen delete button hatte. Also erst mal an der USG reset gedrückt und im Controller letztes Backup zurück gespielt, was selbstverständlich total aktuell war….
    Ich würde die USG gerne so einstellen, dass sie mit WAN1 an der Genexis hängt und mit LAN2 an der FB. Den LAN2-Port würde ich gerne die Adresse 192.168.100.254 geben. Die Fritzbox würde ich dann in den IP-Client Modus versetzen. Sie darf dann gerne im 192.168.100.0 Netz bleiben und ihre Adresse 192.168.100.1 von der USG per DHCP beziehen.
    
    – was ist mit den übrigen Geräten? Muss ich alle Geräte im Controller einzeln einrichten? Bisher sind nur die WLAN-Geräte erfasst. Sie könnten, sobald das USG eingerichtet ist, mit einer festen IP-Adresse versehen werden. Aber die übrigen Geräte, z.B. Netzwerkdrucker???
    
    – was ist mit der FB-Einstellung “Zwangstrennung durch den Anbieter verschieben in die Zeit zwischen” ?
    
    – was ist mit IPv6: “IPv6-Unterstützung aktiv” und “Native IPv4-Anbindung verwenden” und “DHCPv6 Rapid Commit verwenden” und – im Heimnetz “Unique Local Addresses (ULA) immer zuweisen” und “DNSv6-Server auch über Router Advertisement bekanntgeben (RFC 5006)”?
    
    – Auch eine Stolperfalle in den FB-Heimnetz-Einstellungen: “Statusinformationen über UPnP übertragen”. Wie sieht das Pendant bei ubnt aus? Da lustwandelt nämlich auch ein Fernseher und ein Linux-Gerbera im Heimnetz…
    
    Ich denke, das sind genug Fragen für ein verregnetes Wochenende. Wenn es sowas irgendwann mal wieder gibt 🙂
    
    Vielen Dank!
    
    Peter
    
    Antworten
    1. Martin Ziegler sagt:
      
      28. März 2020 um 8:56 Uhr
      
      Hallo Peter,
      
      wenn du einen Genexis FiberXport OCG-1020m (mit 4 LAN-Ports) hast und in er FritzBox deine Internetverbindung über “Anschluss an externes Modem oder Router” und “WT-PPPOE-PRIVATE-CUSTOMER” selbst aufbaust, solltest du die PPPoE Verbindung auch direkt mit deinem USG über PPPoE aufbauen können. Nach deiner Beschreibung gehe ich davon aus, dass du due keinen Router zwischen deiner Fiber-Box und dem USG benötigst und somit das “doppeltes NAT”-Problem wie hier im Artikel beschrieben, gar nicht erst auftritt.
      
      Isolation VLAN: Ich würde dir einen Managed-UniFi-Switch empfehlen. So kannst du im gleichen Managementtool, indem du USG und dein WLAN konfiguriertest auch dein LAN konfigurieren.
      
      WLAN, eine SID, mehrere IP-Netze: Geht mit WPA2-Enterprise und Radius. Das muss dann aber auch der Client mitmachen. Ohne WPA2-Enterprise, kannst du aber auch verschiedene SIDs über deine Access Points zur Verfügung stellen. Wenn du alle WLANs außer deinem SmartHome-WLAN über Nacht mit der Zeitsteuerung abschalten willst, musst du diese mit getrennten SIDs anlegen, da die Zeitsteuerung auf (WLAN)Netz-Ebene erfolgt. Das SmartHome-WLAN, kannst du nur auf den Access Point konfigurieren, der in der Nähe deiner Wetterstation ist. Das sollte in etwa dem entsprechen, was du dir gewünscht hast – wenn ich dich richtig verstanden habe.
      
      Docker: War das ein “ja so kann ich’s machen” oder “was ist der richtige Pfad im Container”? Der Pfad sollte: “/data/sites/” sein. Dazu gibt es hier in den Antworten bereits mehrere Hinweise, wo Leser beschrieben haben, wo die Datei bei Ihnen hingehört hat. Da ich den Manager nicht im Docker Container am Laufen habe, kann ich leider nicht nachschauen.
      
      FritzBox & USG: Du hast den WAN-Anschluss des USG in LAN1 der FritzBox gesteckt nachdem du die statische Route eingerichtet hast? Für die statische Route brauchst du die IP, die die FritzBox dem USG auf dem WAN-Interface zu weißt und auch nur dann, wenn du doppeltes NAT vermeiden möchtest (was du eventuell gar nicht bekommst, wenn du dein USG direkt mit deiner Fiber-Box verbindest und im USG die PPPoE Verbindung aufbaust.
      
      USG in Controller einbinden: Der Controller muss “hinter” dem USG hängen (genaugenommen nicht wirklich, aber um es zu vereinfachen schon).
      
      Vorschlag:
      
      Fiber LAN <-(PPPoE)-> USG WAN1 | USG LAN1 <-> Managed-(UniFi-)Switch <- (* mehrere Ports) *Switch Port 1 (untaged VLAN "192.168.100.0"): <- FritzBox IP-Client Modem *Switch Ports x (untaged VLAN "192.168.100.0"): <- alle anderen Endgeräte, die im gleichen Subnetz wie die FritzBox sein sollen. Achtung: das default Gateway ist das USG, nicht mehr die FritzBox) *Switch Ports y (untaged VLAN "management): <- Alle AccessPoints
      
      Anderen Geräte: In dem Szenario von dir, muss du alle Geräte mit fester IP manuell konfigurieren (zumindest das Gateway). Oder du stellst sie auf DHCP um und machst alles über den Controller.
      
      Zwangstrennung verschieben: Geht leider nicht über die grafische Konfiguration, muss über das CLI gemacht werden.
      
      IPv6: Kommt darauf an, was dein Provider unterstützt und du möchtest. Ich weiß, dass ist keine zufriedenstellende Antwort. Vorschlag: wenn der Rest funktioniert und du dann IPv6 im USG aktiv hast, aber es nicht "automatisch" macht was du willst, kannst du die Frage konkretisieren.
      
      UPnP: Lässt sich im USG pro konfiguriertem Netz an-/ausschalten.
      
      Das waren viele verschiedene Fragen, die jede für sich eigentlich etwas mehr Tiefgang in der Antwort verdient hätten. Ich hoffe die Antworten helfen dir trotzdem etwas weiter.
      
      Gruß
      
      Martin
      
      Antworten
      1. Vetti52 sagt:
        
        28. März 2020 um 19:06 Uhr
        
        Hallo, Martin!
        
        Super Antwort, alles dabei. Dabei war doch gar kein verregnetes Wochenende 😉
        
        – Die ersten beiden bullets überspringe ich mal. Managed Switch kommt später nochmal genauer dran, wenn ich mir einen besorgt habe. Die beiden vorhandenen sind unmanaged.
        
        – WLAN kommt dann auch später dran. Das ist mir aktuell zu kompliziert. Getrennte SIDs ist ja eigentlich das, was ich vermeiden wollte. Wird aber wohl nicht anders gehen. Ich merke mir für später die Frage, wie ich im smart home in unterschiedlichen SIDs kommunizieren kann. Später…. Gerade kam die c’t herein, wo smart home Titelthema ist. Erst lesen, dann weiter denken.
        
        – Docker: ” ja, so kann ich’s machen”. Den richtigen Pfad finde ich ja hier. Aber, wie im Bullet 1 gesagt, brauche ich das ja garnicht. Vorerst, denn ich gehe davon aus, dass USG vor FB klappen wird. Nur bei Plan B, also USG hinter FB, wird es ein Thema, wenn ich das richtig verstanden habe.
        
        – USG hinter FB ausprobiert, weil neugierig: An LAN1 hat USG ja die fixe Adresse 192.168.1.1. Dafür hatte ich in der FB eine statische Route eingerichtet. Ohne diese Route erkennt doch mein Heimnetz das USG garnicht, wenn ich es mit LAN1 in’s Heimnetz bringe. Wenn WAN1 funktioniert, wird das doch auch meine Gateway-Adresse. Außer, ich bekomme es hin, dass auf LAN2 die Adresse 192.168.100.254 eingerichtet wird. Dann wäre dies mein Gateway, oder ist das zu naiv?
        Mein Versuch, das USG im Controller zu konfigurieren, schlug fehl. Es wurde mir zwar das USG im Dashboard angezeigt, ließ sich aber nicht einbinden. Irgendwas mache ich hier wohl falsch. Hier hänge ich gerade total!
        
        – dein Vorschlag, jetzt mal ohne managed switch:
        Fiber LAN USG WAN1 | USG LAN1 FritzBox IP-Client Mode?
        Eingang in die FB am WAN Port? Im Client-Mode ist das doch nur ein zusätzlicher Platz im internen Switch, oder? Warum eigentlich nicht einfach USG LAN2 mit einer Heimnetz-Adresse nehmen, sondern LAN1 mit 192.168.1.1?
        Erst mal müsste ich in die Lage versetzt werden, das USG zu konfigurieren.
        
        – Den Rest können wir gerne später frühstücken. Aber vielleicht in einem separaten Thread?
        
        Vielen Dank
        Peter
        
        Antworten
        
        Martin Ziegler sagt:
        
        30. März 2020 um 12:07 Uhr
        
        Hallo Peter,
        
        “USG hinter FB ausprobiert”: Es klingt so, als hättest du eine statische Route auf 192.168.1.1/24 konfiguriert – das wäre eine Route für eine IP-Adresse. Wenn du NAT im USG deaktivierst (mit der JSON), möchtest du eine Route auf jedes Netz (zum Beispiel 192.168.1.0/24) über die WAN-IP des USG (im Netz deiner FritzBox) konfigurieren. Wenn du NAT im USG nicht deaktivierst, brauchst du keine statische Routen in der FritzBox (je nach Anwendungsfall aber PortForwarding im USG). Eventuell verstehe ich dich aber nur falsch.
        
        Gateway-Adresse: kommt drauf ;-). Für das USG ist deine FritzBox das Default-Gateway. Für alle Geräte “hinter” dem USG, de USG-Adresse im jeweiligen Subnetz.
        
        Wie du aktuell verkabeln möchtest, ist mir nicht ganz klar. Können uns gerne kurz per Skype austauchen – das ist eventuell einfacher als über den Blog.
        
        Gruß
        
        Martin
        
        Antworten
        
        Vetti52 sagt:
        
        1. April 2020 um 16:57 Uhr
        
        Hallo, Martin!
        
        Mittlerweile habe ich doch etwas mit dem USG herum gespielt und sehe damit auch selber etwas klarer. Tut mir leid, dass du meine etwas verwirrten Gedanken ertragen musstest.
        Aber der Reihe nach:
        Laut USG-Kurzanleitung ist doch LAN1 auf die fixe Adresse 192.168.1.1 und als DHCP-Server eingestellt. Meine Idee war, dass ich von der FB mit statischer Route ins Netz 192.168.1.0/24 per switch an LAN1 vom USG gehe, um sie von da aus zu konfigurieren. Das klappt nicht, weil zwar das USG im Controller auftaucht, sich aber nicht einbinden läßt. Testweise ging es auch nicht, wenn ich anstatt LAN1 am USG WAN1 nahm, obwohl das doch per DHCP eine Adresse aus dem FB-Adressraum gewählt werden sollte. Trotzdem schaltete es einfach nie auf “blau”. Meine Lösung war dann das von Unifi vorgeschlagene Verfahren, das USG ausschließlich mit einem Rechner an LAN1 zu koppeln, alles starten, und dort die Erstkonfiguration vorzunehmen. Eine an sich logische Maßnahme musste ich da auch erst lernen: Am Gateway gibt es entweder LAN1 oder LAN2. Also zuerst LAN deaktivieren und dann LAN2 aktivieren. Ich habe USG LAN2 auf 192.168.100.254 eingerichtet, was auch anstandslos klappte. Alles ausgeschaltet, PC wieder am Switch eingestöpselt, und dort den Controller geöffnet. USG gestartet, und, siehe da, nach kurzer Zeit war es verbunden, Dauerlicht blau. In der FB wurde auch der Hinweis gebracht, dass sich ein Gerät mit der Adresse 192.168.100.254 verbunden hat. Allerdings war keines vorhanden. Statt dessen gab es nun zwei mit der Adresse 192.168.100.1, nämlich USG und FB. Ich nehme an, dass beim ersten Provisionieren der Controller dem USG die im LAN-Netzwerk eingetragene default gateway Adresse gegeben hat, weil er ja die Fritzbox garnicht kennt. Nunja, das ist nicht weiter schlimm. Denn wenn ich jetzt die FB als IP-Client eintrage, bekommt sie sowieso eine neue Adresse. Ich habe ja die Möglichkeit, wenn ich die FB als IP-Client einstelle, auf dieser Seite die Adresse entweder über DHCP auszuwählen oder manuell einstellen. Erst mal wollte ich die Adresse statisch auf 192.168.100.2 setzen und dann die FB komlett neu starten.
        
        Im Controller habe im neu aufgetauchten WAN-Netz am USG WAN1 bereits auf PPPoE gesetzt und die Daten aus der FB übertragen. Damti sollte doch die Anmeldung funktionieren, sobald ich WAN1 an die Genexis anschließe. Wenn ich im USG LAN2 als DHCP-Server aktiviere, hätte ich doch für alle Geräte im Haus die gleichen Bedingungen wie bisher, also, dass sie 192.168.100.1 als gateway verwenden und von dort auch DNS, NAT und Timeserver beziehen. Wenn das so läuft, würde ich auch die FB auf DHCP umstellen, damit alle Aktualisierungen nur im Controller erfolgen. Die FB dient dann nur als einfacher switch, an dem alle Strippen wie bisher weg gehen, und für die Telefonie. Oder?
        
        Sorgen macht mir halt die Telefonie, weil ich nicht weiß, wie ich testen soll, ob alles stabil läuft. Ok, mit Wireshark war ich schon mal auf der Spur, weil nach einem Update die FB plötzlich Telefonate nur signalisierte, aber nichts mehr entgegen nahm. Das konnte nach Analyse der Daten behoben werden, indem von DS-Lite auf DualStack umgestellt wurde. Ich musste dazu lediglich einstellen, dass der Inernetanbieter nur über IPv4 kontaktiert werden darf. Aber das Ganze war sehr problematisch, und das Knowhow der beteiligten Supporter ging nicht weit über meines hinaus. Insofern erwarte ich bei Mißlingen der USG-Einrichtung nur ein maximal mögliches Desaster, mit Plan B als Lösung: USG hinter FB, daran einen managed switch mit dem gesamten Heimnetz.
        
        Ich denke, das gibt ein schlüssigeres Bild, oder?
        
        Antworten
        
        Vetti52 sagt:
        
        2. April 2020 um 16:13 Uhr
        
        Nachtrag:
        Bin schon beim ersten Test genau am Telefon gescheitert. USG verbindet sich problemlos mit Internet und arbeitet auch als Router. Die Geräte an der FB kommen auch ins Internet. Allerdings bekomme ich die Telefonie nicht verbunden. Fehler: “Anmeldung der Internetrufnummer xxx war nicht erfolgreich. Ursache: DNS-Fehler”
        Also schnell wieder zurück auf Null. Ist ja auch etwas mühsam, weil die FB alle DHCP-Hosteinträge nach dem Abschalten von DHCP vergessen hat. Gut, wenn davon ein aktuelles analoges Backup (Liste auf Papier gedruckt) vorhanden ist. Nun heißt es: Mühsame Kleinarbeit zur Suche, wo ich irgendwas in der Konfiguration verbockt habe. Plan B soll’s nicht so schnell gewesen sein.
        
        Antworten
        
        Martin Ziegler sagt:
        
        3. April 2020 um 15:24 Uhr
        
        Hallo Peter,
        
        leider habe ich noch kein klares Bild.
        
        “Meine Idee war, dass ich von der FB mit statischer Route ins Netz 192.168.1.0/24 per switch an LAN1 vom USG gehe, um sie von da aus zu konfigurieren”
        Wenn ich dich richtig verstehe: FritzBox 192.168.100.1 mit DHCP Server “LAN1” <-> “LAN1” USG 192.168.1.1 mit DHCP Server
        In dieser Konstellation hättest du zwei IP-Subnetze im einem “physikalischen” Netz (nicht schön aber machbar) und zwei DHCP Server die Adressen aus verschiedenen IP-Subnetzen im gleichen “physikalischen” Netz verteilen (schlecht). Eine Route zeigt auf ein Gerät im eigenen IP-Subnetz, hinter dem definierte Subnetze liegen, und macht in dieser Konstellation keinen Sinn. Oder ich verstehe dich komplett falsch :-/
        
        Wenn du testen möchstest, kannst du so vorgehen
        * “Internet” -> WAN1 (PPPoE) – USG – LAN1 -> (Switch) -> Controller & PC & “Rest”: Alles konfigurieren.
        Wenn alles klappt:
        * FritzBox -> PC: FritzBox als IPClient konfigurieren
        * FritzBox LAN1 -> (Switch) -> USG LAN1
        * Alle für VoIP notwendigen Ports vom USG an die FritzBox forwarden.
        
        Ich glaube, wir denken noch etwas aneinander vorbei oder ich verstehe dich nicht. 10 Minuten Skype helfen sicher mehr als 30 Minuten lesen & schreiben, wenn du möchtest.
        
        Gruß
        Martin
        
        Antworten
        
        Vetti52 sagt:
        
        3. April 2020 um 18:48 Uhr
        
        Hallo, Martin!
        
        eigentlich dachte ich, es wie in deinem Vorschlag gemacht zu haben. Also:
        * “Internet” -> WAN1 (PPPoE) – USG – LAN2 -> (FB-Switch) -> Controller & PC & “Rest”
        Das lief. Dass die FritzBox noch “daneben” lief, macht Kuddelmuddel, weiß ich. Daher habe ich sie gleich am PC als IP-Client konfiguriert, aber mit statischer IP 192.168.100.2, und dann den Stecker gezogen. So sah bei mir die Umsetzung deines 2. Punktes aus.
        * FritzBox -> PC: FritzBox als IPClient konfigurieren
        Ok?
        Der Punkt
        * FritzBox LAN1 -> (Switch) -> USG LAN1
        erledigt sich bei der FB7580 beim Umstellen auf IP-Client von alleine, denn der WAN Port der FritzBox als Router wird dabei zu einem weiteren LAN Port.
        Meine Konstellation heißt dann demgemäß
        * FritzBox WAN (=Teil von FB-Switch)-> USG LAN2.
        Ist das ok so?
        In diesem Status lief das Ensemble problemlos. Alle Geräte hatten Internet-Verbindung, der Unifi-Controller war auch zufrieden.
        
        Meiner Meinung nach sind wir bis da also garnicht so weit auseinander.
        
        Doch jetzt kommt Neuland:
        
        * Alle für VoIP notwendigen Ports vom USG an die FritzBox forwarden.
        
        Bisher hatte ich nur den Verdacht, dass die Namen von Registrar und Proxy in den VOIP-Anbietereinstellungen ein Problem darstellen, weil wohl die Namen nicht aufgelöst werden konnten. Ich habe dann nochmal die DHCP-Einstellungen geprüft, die Fritzbox von statisch auf dynamisch umgestellt, Neustart veranlasst und wieder den Stecker gezogen. Aber immer das Gleiche: DNS-Fehler bei der Anmeldung. Dass die DNS-Auflösung prinzipiell funktioniert, zeigt doch auch die Tatsache, dass die Fritzbox erfolgreich Emails mit Änderungsnotizen verschicken konnte.
        
        Mein Controller mit Version 5.12.66 hat SIP ALG voreingestellt auf “Aus” stehen. Aber was muss ich denn da noch machen?
        Was mir übrigens auch nicht gelingt, ist das USG-Update auf firmware 4.4.50. Sie bleibt einfach auf 4.4.44. Irgendwie ist das Teil widerspenstig!!!
        
        Skypen kann ich gerade nicht, weil mein PC mit Skype zwar Lautsprecher, aber (seit zwei Jahren noch immer) kein Mikro hat. Die Kommunikation wäre dann schon sehr einseitig. Also: Möchten täte ich schon, aber können nicht. Aber es wird mir schon was dazu einfallen.
        
        Erst mal vielen Dank!
        Peter
        
        Vetti52 sagt:
        
        5. April 2020 um 21:51 Uhr
        
        Hallo, Martin!
        Nachdem ich mich mit dem USG nochmal beschäftigt habe, bin ich zu der Einsicht gekommen, mir doch einen Switch zu besorgen. Dann kann ich, so wie du es vorschlägst, step by step vorgehen und USG-LAN1 an einen switch hängen, an den dann das gesamte Netz gekoppelt ist. Dass es auf Anhieb bei mir geklappt hatte, war eher Zufall und leider nicht reproduzierbar. Also erst USG in’S Netz einbinden. Anschließend darf dann die Fritzbox als IP-Client mitspielen.
        Mittlerweile gibt es auch hier eine nette Ungereimtheit: Nachdem ich die Fritzbox als IP-Client mit statischer Adresse und festen DNS-Servern einrichtete, blieben diese DNS-Server erhalten, auch wenn ich die Box wieder auf Routerbetrieb umstellte. Mit Google-DNS 8.8.8.8 klappte auch die Telefonieverbindung nicht zuverlässig. Erst nachdem ich die DNS-Server des Providers in die Tabelle der statischen Adressen eingetragen hatte, funktionierte es wieder problemlos. Wohlgemerkt, im Routerbetrieb, wo die Daten für den statischen IP-Client Betrieb eigentlich keine Rolle mehr spielen sollten. Möglicherweise löst Google-DNS die für die Telefonie benötigten Adressen von Registrar und VOIP-Proxy anders auf als die DNS vom Provider.
        Der Service von AVM gab sogar an, dass der Betrieb mit statischer Adresse zu schwerwiegenden Störungen führt, die nur mittels Werkseinstellungen zu beheben seien. Er hat mich auch auf die Seite https://avm.de/service/fritzbox/fritzbox-7580/wissensdatenbank/publication/show/28_Aufbau-ausgehender-Telefonverbindungen-nicht-moglich#zd verwiesen, wo auch ein Link auf die Einstellung als IP-Client mit Porteinstellungen vorkommt. Anscheinend ist auch bei AVM einiges an Problemen mit dem IP-Client-Betrieb bekannt. Da ist es wohl besser, die Fritzbox, wie du vorschlägst, ganz separat in ein funktionierendes Unifi-System einzubinden. Hast ja recht 😉
        Also: Nicht zaubern! Handwerk und Sorgfalt sind gefragt. Jetzt warte ich auf den Switch. Um in der Familie zu bleiben, wird es natürlich ein US-8-60W.
        Bis zum Punkt
        * FritzBox -> PC: FritzBox als IPClient konfigurieren
        werde ich problemlos kommen. Falls ich danach noch mal deinen Rat brauche, melde ich mich. Wenn’s dir nicht zuviel wird…
        Wenn es auc dann nicht mit der Telefonie klappt, kommt Plan B: USG hinter Fritzbox, ohne doppeltes NAT. 🙁
        Bis dann
        Peter
        
        Martin Ziegler sagt:
        
        6. April 2020 um 8:55 Uhr
        
        Hallo Peter,
        
        du kannst dir bezüglich der Auflösung der VoIP-relevanten Adressen Sicherheit verschaffen:
        nslookup <"VoIP-IP"> 8.8.8.8 nslookup <"VoIP-IP">
        Wenn hier verschiedene Ergebnisse kommen, kannst du eine Unbekannte von deiner Liste streichen.
        
        Bei Fragen gerne melden – ich lerne jedes Mal mit 😉
        
        P.S.: Das Update des USG sollte “eigentlich” problemlos laufen. Ich würde versuchen herauszufinden, warum es nicht klappt – nicht, dass du noch ein verstecktes Problem hast, was dir an anderer Stelle weh tut.
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        6. April 2020 um 21:20 Uhr
        
        Hallo Martin!
        Wir sind schon mit der Antwort-Tiefe am Anschlag. Daher meine Antwort auf die nächst freie Stelle…
        
        Mit nslookup werde ich mal nachforschen, danke für den Tipp!
        Warum das update nicht klappte, weiß ich immer noch nicht, aber ich vermute mal, dass es an mir selbst lag. Obwohl….
        Nachdem mir das SSH-Passwort für das USG wieder einfiel, habe ich mich am CLI eingeloggt. Ich habe allerdings eine very special Umgebung, indem ich im Controller das default gateway auf 192.168.100.2 gesetzt habe und USG nur LAN2, kein WAN1 angestöpselt hat. Damit läßt sich das USG einbinden und provisionieren, hat aber selbst keine Funktion udn beißt sich nicht mit der Fritzbox auf 192.168.100.1, bis ich meinen Switch bekomme und das USG vor die Fritzbox hängen werde. Mas mich in dieser Konstellation wundert, ist, erstens, dass das UAP-Netz anscheinend keine Notiz vom “default gateway” nimmt, sondern stur bei seinen DHCP-Einstellungen, die es von der Fritzbox erhalten hat, bleibt, und zweitens, dass der Controller meldet, es gäbe ein Update und dann auch noch angeblich dieses Update installiert. Per CLI eingeloggt, ist zu erkennen, dass das USG gar keinen DNS hat. Woher auch! Ich habe daher die Update-Datei auf meinem FTP-Server gespeichert und im USG per ftp runter geladen. Dann konnte ich das lokal vorhandene Update einspielen. Warum einfach, wenn es auch ganz sicher geht??? Mich wundert nur, dass der Controller solche Kinken nicht merkt. Aber auch, als ich das USG voll funktionsfähig vor der FB hatte, und alles bis auf die Telefonie lief, wollte das Update genauso wenig funktionieren. Also irgendwas stimmt nicht. Muß mich mal mit den CLI-Befehlen auseinander setzen. Naja, ich weiß mir ja zu helfen. Ok, manchmal überschätze ich mich wohl auch, etwas….
        
        Genieße das Frühlingswetter!
        Gruß
        
        Peter
        
        Vetti52 sagt:
        
        6. April 2020 um 21:33 Uhr
        
        Da haben wir den Salat!
        
        linux:~ # nslookup proxy.voipslb.wtnet.de
        Server: 192.168.100.1
        Address: 192.168.100.1#53
        
        Non-authoritative answer:
        Name: proxy.voipslb.wtnet.de
        Address: 213.209.115.117
        Name: proxy.voipslb.wtnet.de
        Address: 2a02:2028:ff01::ca11:1000
        
        linux:~ # nslookup proxy.voipslb.wtnet.de 8.8.8.8
        Server: 8.8.8.8
        Address: 8.8.8.8#53
        
        ** server can’t find proxy.voipslb.wtnet.de: SERVFAIL
        
        Also fährt der Provider ein inhouse-DNS. Nun gut, dann muss ich also die Telefonie-IP-Einstellungen manuell festlegen. Oder ich verlasse mich auf den Fritzbox-Bug, dass die statischen DNS-Einträge auch dann verwendet werden, wenn die Adressen per DHCP abgerufen werden sollen. Oh, was ist das für ein Mist! Kann das lange gut gehen?
        
        Martin Ziegler sagt:
        
        7. April 2020 um 18:42 Uhr
        
        Hallo Peter,
        
        ob das gut oder schlecht ist, lässt sich nicht pauschal beantworten. Dein Provider hat sicher gute Gründe das so zu machen. Eventuell um Missbrauch zu erschweren. Jetzt da du weißt, dass du den DNS Server deines Providers nutzen muss, kannst du dies in deiner Planung berücksichtigen. Da das USG in deinem Zielbild die Internetverbindung aufbaut und seine IP Adresse von deinem Provider bekommt, sollte auch der richtige DNS mitkommen.
        
        Bezüglich DHCP/Default-Gateway/FritzBox/USG-CLI: Bei Skype ging es mir vor allem darum, dass wir den Bildschirm teilen können. Für den Ton lässt sich auch ein “klassisches” Telefon/Handy nutzen. Das Angebot steht immer noch – 15 Minuten telefonieren schaffen mehr Klarheit als viele kleine Postings und spart uns beiden Zeit. Ich glaube andere Leser könnten an deiner Lösung interessiert sein. Ich weiß aber nicht, ob sich sich durch die Postings durchwühlen wollen 😉
        
        Du bist generell auf dem richtigen Weg. Wenn dein Switch da ist und vielleicht die eine oder andere Einstellung eines alten Versuchs wieder rückgängig gemacht wird, solltest du ein schönes Netzwerk mit dem USG als “Tor zum Internet”, der FritzBox als “Telefonanlage” und der Möglichkeit mehre (getrennte) Netzwerke ohne doppeltem NAT aufzubauen, haben.
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        13. April 2020 um 21:04 Uhr
        
        Hallo, Martin!
        
        Pünktlich am Kar-Samstag kam der Switch. Also volles Osterprogramm für eine Corona-Klausur 🙂
        Kurz: Es hat genau so geklappt, wie ich es mir vorgestellt habe. Fast schon verwunderlich, denn eigentlich habe ich nichts anders gemacht als im “Blindflug-Modus”. USG vorbereitet auf 192.168.100.1, mit DHCP aktiv und die Fritzbox in den Clientmodus gebracht. Während des Provisionierens die Kabel umgesteckt, so dass WAN1 an Genexis hing, LAN2 am Switch blieb, und die Fritzbox in den Switch umgesteckt wurde. Nach ein paar Minuten war die Verbindung perfekt, sowohl ins Internet, als auch die Telefonie an der Fritzbox. Frag mich nicht, warum das nicht ohne Switch klappen wollte. Es war natürlich noch etwas Aufwand, die Geräte per DHCP wieder auf ihre alten, von der Fritzbox fest vergebenen IP-Adressen zu bringen. Und für die Wetterstation gab es auch einen Break, weil sie auf den fqdn-Suffix .fritz.box sendete, der sich bei Unifi auf .local geändert hat. Das sollte man mal in eine Checkliste mit aufnehmen. Kleiner Mist, große Wirkung…
        So… Das alles klappt auch nach komplettem Stecker-Ziehen!!!
        
        Was klappt nicht?
        
        Na klar, irgendwas ist ja immer: Ein IP-Telefon verbindet sich nach dem Umstellen in den IP-Client-Modus nicht mehr mit der Fritzbox. Nach meinen ersten Nachforschungen scheint in der Fritzbox was falsch verdrahtet zu sein. In den Anmeldedaten steht:
        
        Registrar
        fritz.box oder
        192.168.100.1
        
        Weder der Name fritz.box noch die IP-Adresse können stimmen. Sie können aber auch nicht geändert werden. Da kann ja nicht gut gehen.
        
        Also kurzerhand die Adressen getauscht, jetzt ist das USG 192.168.100.2 und die Fritzbox hat wieder die 191.168.100.1.
        
        Aber denkste, das Gigaset C430A GO meldet sich einfach nicht an der Fritzbox an. Mit den Portweiterleitungen für SIP hat da ja nichts zu tun. Aber wo liegt der Haken??? Doppel-NAT sollte es ja nicht geben, oder? Vorher hat es ja monatelang problemlos funktioniert. Also muß der Fehler bei mir liegen. Nur, wo??? Zwischen den Ohren? Da komme ich leider nicht hin!
        
        Immerhin, wenn man brav dem folgt, was oben beschrieben ist, dann klappt es auch bis dahin:
        Provider USG (WAN1:PPPoE) USG (LAN:192.168.100.2/DHCP-Server) Switch USW8 (all) Heimnetz / Fritzbox (192.168.100.1)
        
        Bis auf das IP-Telefon ist alles wie es sein soll. Hast du ne Idee?
        
        Danke
        Peter
        
        Vetti52 sagt:
        
        14. April 2020 um 10:26 Uhr
        
        Hallo, Martin!
        
        Nachtrag: Nun geht doch alles. Ich sollte einfach mehr auf dich hören 😉 Der „Trick“ ist, dass nach dem Umstellen der Fritzbox auf IP-Client der WAN-Port doch nicht ein Bestandteil des internen Switches wird. Mir fiel es heute auf, weil im Unifi-Switch das Symbol zur FB auf Uplink stand und ein WLAN-Test von einem UAP quälend langsam ging. Also an der Fritzbox das Kabel von WAN nach LAN1 umgesteckt. Schon ist das Uplink-Symbol auf dem Port zum USG und das IP-Telefon hat sich verbunden.
        Also alles „hervorragend“, wie der Controller behauptet. Jetzt fehlt nur noch die Zwangsabschaltung…
        
        Sonnige Grüße
        Peter
        
        Martin Ziegler sagt:
        
        20. April 2020 um 14:45 Uhr
        
        Hallo Peter,
        freut mich, dass bisher alles so läuft, wie du es wolltest.
        
        Die Sonne ist hier angekommen 😉
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        20. April 2020 um 20:46 Uhr
        
        Hallo, Martin!
        
        Auch die Zwangsabschaltung habe ich nun erledigt.
        Es muß, wie immer, wenn es dauerhaft eingereichtet sein soll, in die config.gateway.json dieses eingefügt werden:
        
        { "system": { "task-scheduler": { "task": { "pppoe-disc": { "crontab-spec": "0 3 * * * ", "executable": { "path": "/usr/bin/killall -HUP pppd" } } } } } }
        
        Die Neu-Verbindung geht so flott, dass es gerade mal ntpd merkt, dass die Verbindung gekappt ist, die Fritzbox-Telefonie merkt es nicht. Sie ist angeblich seit Tagen online. Nur in /var/log/messages des USG kann man erkennen, dass nun täglich um 03:00 Uhr die Trennung erfolgt. Sehr elegant, sehr empfehlenswert!!!!
        Aber, irgendwas ist ja immer: DHCP und DNS sind eine Katastrophe. Es werden täglich hosts aktualisiert, deren Hostnamen nicht stimmen. Ich habe das DNS-Forwarding im Controller abgestellt, so dass in die /etc/hosts keine DHCP-Einträge mehr vorgenommen werden. Diese Datei pflege ich nur noch per Hand. Ich fürchte, da sind noch ein paar simple Bugs in den Perl-Scripts, die dahinter werkeln. Perl kann ich aber leider noch weniger als bash. Und das EdgeOS-Konzept per CLI habe ich leider auch noch nicht richtig verinnerlicht. Aber, wenn du für das Verwalten der hosts noch Tipps hast, bitte gerne!!
        
        Weiterhin sonnige Grüße
        Peter
        
        Martin Ziegler sagt:
        
        26. April 2020 um 18:53 Uhr
        
        Hallo Peter,
        ich habe deinen Config-Block in “pre”-Tags gesetzt, damit er dem entspricht, was du eingegeben hast. Es freut mich, dass deine gezielte Neu-Verbindung so reibungslos funktioniert.
        Bezüglich hosts und DHCP/DNS: Bezieht sich dein Problem nur auf interne Adressen oder auch wenn du externe Adressen auflösen willst?
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        27. April 2020 um 17:34 Uhr
        
        Hallo, Martin!
        Danke für die “pre” Tags. Über die Formatierungsmöglichkeiten hier habe ich mich überhaupt nicht informiert 😉
        
        Es werden nur einige interne Namen nicht immer richtig aufgelöst. Besonders ärgerlich ist, dass der Unifi-Controller per DHCP der Fritzbox die “richtige” Adresse 192.168.100.1 fixiert zuteilt. Das USG bekommt die Adresse 192.168.100.2 über den Controller-Eintrag “default gateway”. Allerdings steht in der Liste der Geräte im Hostname der Fritzbox der Hostname des USG-3P. Gelegentlich, vermutlich, wenn DHCP-Lease erneuert wird, schreibt DHCP in die /etc/hosts Liste die aktualisierten Hosts. Dann steht in /etc/hosts neben 192.168.100.1 USG-3P, anstatt Fritzbox. Anschließend kommt man beim http-Aufruf von USG-3P auf die Fritzbox. Ich habe daher das automatische Forwarding von dhcp im Controller abgeschaltet und /etc/hosts komplett von Hand geschrieben. Das geht gut, wenn nur statische oder fixierte Adressen vergeben werden. Aber richtig wohl ist mir dabei nicht. Ich hätte lieber die Einträge der Hostnamen im Controller mit denen in /etc/hosts konsistent.
        
        Alle externen IPv4 und IPv6-Adressen funktionieren perfekt. IPv6-test.com meldet auf den LAN-Geräten zwar nur score 17 (1. firewall is filtering ICMPv6, 2. no reverse DNS record to associate your IPv6 address with a host name). Auf WLAN-Geräten geht bei IPv6-test.com gar nichts (IPv6 not supported), obwohl sie alle ordentliche IPv6-Adressen bekommen haben und immerhin DNS6 + IP4 auf “reachable” steht.
        Das ist aber wohl eine andere Baustelle.
        
        viel zu trockene Grüße
        Peter
        
        Martin Ziegler sagt:
        
        2. Mai 2020 um 18:18 Uhr
        
        Hallo Peter,
        inzwischen hat es bei uns zum Glück etwas geregnet. Das USG geht in der Regel davon aus, dass es die “.1er” Adresse der Netze hat, die es definiert. Wenn die FritzBox ein Client in einem solchen Netz ist sollte die nicht diese Adresse verwenden.
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        4. Mai 2020 um 16:31 Uhr
        
        Hallo, Martin!
        
        Mit der *.1 Adresse für das USG hatte ich auch angefangen. Dann weigerte sich allerdings die Fritzbox, IP-Telefon-Verbindungen auf einer “neuen” IP-Adresse anzunehmen, so dass ich der FB wieder die *.1 gegeben habe. Besonders blöd war dann, allen statischen Adressen die *.2 als dhcp-/dns-Server und Gateway einzutragen. Das kostete einiges an Konzentration. Dabei ist mir wohl der Fehler unterlaufen, der Fritzbox manuell den DHCP-Namen “USG-3P” gegeben zu haben. Zum Haare raufen! Aber mittlerweile sehe ich bei jedem Host nach, welchen Hostnamen er übermittelt. Leider ist das bei den Androiden nicht änderbar. Eine Lösung wäre ja, per dhcp den Hostname zu überschreiben. Aber das unterstützt Unifi wohl (noch) nicht. Also nochmal ein paar Jahre warten, und in der Zwischenzeit perl lernen, um die dafür zuständigen /opt/vyatta/sbin/*.pl-scripte zu verstehen und ggf. anzupassen.
        
        Ach ja, die IPv6-Test.com scores warten ja auch noch….
        
        Der Regen ist hier schon wieder weg 🙁
        
        Vetti52 sagt:
        
        15. Mai 2020 um 17:00 Uhr
        
        Hallo, Martin!
        In der letzten c’t war ein Artikel über DynDNS bei der Fritzbox. das geht ja nicht mehr, wenn sie als IP-Client hinter dem USG hängt. Zur Ergänzung habe ich deshalb die config.gateway.json um das Update beim Dynv6 Service erweitert. Es macht das Update 15 Minuten nach der Trennung (siehe Script weiter oben):
        
        { "system": { "task-scheduler": { "task": { "dynv6-update": { "crontab-spec": "15 3 * * * ", "executable": { "path": "/config/scripts/dynv6.sh" } }, "pppoe-disc": { "crontab-spec": "0 3 * * * ", "executable": { "path": "/usr/bin/killall -HUP pppd" } } } } } }
        
        Ich habe allerdings zuerst per cli diese Einträge angelegt:
        configure
        set system task-scheduler task dynv6-update crontab-spec ’15 3 * * * ‘
        set system task-scheduler task dynv6-update executable path ‘/config/scripts/dynv6.sh’
        anschließend per commit und save gespeichert. In dem Zusammenhang habe ich erfahren, dass bash-Skripte, die im Verzeichnis /config/scripts abgelegt werden, ein firmware-update überleben. Das finde ich schon sehr wichtig!
        Das Skript dynv6.sh stammt von https://gist.github.com/corny/7a07f5ac901844bd20c9 und wird normalerweise so aufgerufen:
        token=${deinTokenXYZ} ./dynv6.sh ${deinHostnamebeiDynv6}.dynv6.net
        das übernimmt das USG im config.gateway.json aber nicht, wg. too many arguments. Also habe ich im Kopf des skripts die Argumente eingetragen und rufe es ohne diese auf:
        cat /config/scripts/dynv6.sh
        #!/bin/sh -e hostname=${deinHostnamebeiDynv6}.dynv6.net token=${deinTokenXYZ} netmask=56 device=$2 ...
        danach hat mein skript keine weiteren Veränderungen zum Original. Zur Dokumentation habe ich dann diesen Teil auf der USG cli per
        mca-ctrl -t dump-cfg > config.txt ausgelesen und hier zur Verfügung gestellt.
        Es gibt zwar im Controller eine hübsche Einstellung für DynDNS, die aber bei mir nur die IPv4-Adresse updated. Da gefällt mir diese Lösung schon besser 🙂
        
        Martin Ziegler sagt:
        
        15. Mai 2020 um 17:52 Uhr
        
        Hi,
        vielen Dank fürs Teilen. IPv6 ist leider noch nicht überall richtig integriert – leider bei einigen Herstellern. Wobei es so einen Grund gibt, sich in die Themen einzuarbeiten 😉
        
        Gruß
        
        Martin
        
        Martin Ziegler sagt:
        
        15. Mai 2020 um 17:55 Uhr
        
        habe deinen Kommentar etwas formatiert. Hoffe das war okay.
        
        Vetti52 sagt:
        
        16. Mai 2020 um 21:11 Uhr
        
        Hallo, Martin!
        Vielen Dank fürs Editieren.
        
        Allerdings sind ein paar Dinge deinen Filtern zum Opfer gefallen.
        
        Ich nehme jetzt mal geschweifte statt spitzer Klammern:
        Original-Aufruf:
        token={deinTokenXYZ} ./dynv6.sh {deinHostnamebeiDynv6}.dynv6.net
        und im USG-script:
        #!/bin/sh -e
        hostname={deinHostnamebeiDynv6}.dynv6.net
        token={deinTokenXYZ}
        netmask=64
        device=eth1
        …
        danach hat mein skript keine weiteren Veränderungen zum Original.
        
        Wer genau hinsieht, bemerkt, dass ich updaten musste, nachdem ich mir das bash-script nochmals genauer angesehen habe. Die aktuelle IP-Adresse wird darin mittels
        ip -6 addr list scope global
        ermittelt. Wenn kein device angegeben wird, wird die von pppoe0 genommen. Nach meiner Meinung ist die richtige aber die von device=eth1 (sofern man LAN1 am USG nutzt, sonst eth2),
        weil ich sehe, dass bei der Ausgabe von ip bei PPPoE-Verbindungen auf device=pppoe0 eine andere IPv6/128-Adresse angegeben wird. Das USG vergibt zudem für die internen Adressen IPv6/64-Adressen, so dass es sinnvoller ist, bei device=eth1 auch netmask=64 zu setzen.
        IPv6 ist für mich noch Neuland. Also, wer genaueres weiß, gerne her damit!
        
        Gruß
        Peter
        
        Martin Ziegler sagt:
        
        7. Juni 2020 um 20:27 Uhr
        
        Hallo Peter,
        
        ich habe die entsprechenden Stellen in deinem Post korrigiert. Aus den spitzen Klammern habe ich “${}” gemacht.
        
        Gruß
        
        Martin
        
        Vetti52 sagt:
        
        29. Mai 2020 um 17:11 Uhr
        
        Hallo, Martin!
        Der Eintrag bei Dynv6 ist ja nur die halbe Miete. Irgendwann will ich ja auch auf die Server per IPv6 von außen zugreifen. Die drei Records habe ich bei Dynv6 eingetragen und sie werden auch täglich aktualisiert. Nun kämpfe ich mit der Firewall des USG, die leider keine dynamischen IPv6-Adressen verarbeitet.
        Mein aktueller Stand ist, die gateway.config.json um die Firewall-Einträge zu erweitern:
        
        { "system": { "task-scheduler": { "task": { "pppoe-disc": { "crontab-spec": "0 3 * * * ", "executable": { "path": "/usr/bin/killall -HUP pppd" } }, "dynv6-update": { "crontab-spec": "15 3 * * * ", "executable": { "path": "/config/scripts/dynv6.sh" } } } } }, "firewall": { "ipv6-name": { "WANv6_IN": { "default-action": "drop", "description": "packets from internet to intranet", "rule": { "2000": { "action": "accept", "description": "Server1", "destination": { "address": "::dexx:xxff:fexx:xx49/::ffff:ffff:ffff:ffff" }, "protocol": "all" }, "2001": { "action": "accept", "description": "Fritzbox", "destination": { "address": "::e2xx:xxff:fexx:xxxx/::ffff:ffff:ffff:ffff" }, "protocol": "all" }, "2002": { "action": "accept", "description": "linux", "destination": { "address": "::4axx:xxff:fexx:xxxx/::ffff:ffff:ffff:ffff" }, "protocol": "all" } } } } } }
        
        Leider kann man die destination address nicht in der UI-Controller-Oberfläche eintragen. Und wenn man in der UI-Oberfläche die Firewall-Daten ändert, werden alle manuellen Einträge dort gelöscht. Also muß es auf diesem Weg laufen. Ich hoffe, es hilft jemandem hier weiter. Oder jemand hat noch eine bessere Idee!!!!
        
        Gruß
        Peter
Christopher Lee sagt:

17. März 2020 um 17:28 Uhr

Hallo in die Runde,

eine kleine Anmerkung zu Portweiterleitungen wenn die USG kein NAT mehr macht – ich habe mich da mit dem Fritz!Box-Support deswegen auseinandergesetzt:

Beispiel:
Fritz!Box LAN: 192.168.1.2/24
USG WAN: 192.168.1.1/24
LAN: 192.168.0.1/24
Client LAN: 192.168.0.2/24

Wenn man eine Weiterleitung auf eine geroutete Adresse macht (also auf der Fritz!Box nach 192.168.0.2) und der Client sich bereits mit IP-Paketen auf der Fritz!Box gemeldet hat, dann sieht man den Client zwar nicht auf der Fritz!Box unter “Heimnetzwerk”, aber man kann keine Portweiterleitung mehr machen. Unter “Heimnetzwerk” kann man den Client nicht hinzufügen, da die IP-Adresse nicht im Netz der Fritzbox ist und unter “Freigabe” kann man den Client nicht hinzufügen weil man dann eine Fehlermeldung bekommt die IP-Adresse würde bereits verwendet werden. Man kann also nur eine Weiterleitung auf die USG machen – was generell auch kein Problem sein sollte – Spiele wie Destiny 2 haben sich jedoch da etwas albern.

Antworten
Pascal Randow sagt:

19. März 2020 um 15:31 Uhr

Hallo Martin,

danke für diesen Blogpost. Das Double NAT Problem beschäftigt mich seit ich den USG habe. Komme mit deiner Anleitung etwas weiter, dass der USG ohne NAT die FB und 8.8.8.8 pingen kann – Clients am USG haben jedoch kein Internet mehr.

Setup:
USG: 192.168.1.0/24
FB 7530: 192.168.178.0/24
FB Route: 192.168.1.0/24 via 192.168.1.20 (also USG WAN)
DNS USG: 192.168.1.2 (pihole)

– config von dir habe ich provisioniert und gecheckt, dass diese aktiv ist
– clients am usg haben dann kein internet mehr (kein ping kein dns)
– ssh auf dem usg lässt sich die fritzbox und google (8.8.8.8) pingen und dns geht

Was mache ich falsch? Blockiert der USG irgendwie den WAN-Ausgang zur FB? Oder vielleicht die Antwort?

Bin dir unendlich für Hilfe dankbar !

Antworten
1. Martin Ziegler sagt:
  
  24. März 2020 um 7:22 Uhr
  
  Hallo Pascal,
  
  deine Route in der FritzBox zeigt auf “192.168.1.20” – es sollte aber die IP sein, die das USG im Netz der FritzBox (bei dir: 192.168.178.0/24) bekommt.
  
  Gruß
  
  Martin
  
  Antworten
Lothar sagt:

22. März 2020 um 16:40 Uhr

So ich habe folgendes Problem ! Ich habe auf der Fritzbox 6490 die Ip 192.168.178.1, welche im Bridgemodus läuft. Das Usg hat als Ip 192.168.1.1.
Meine Geräte bekommen also Ip‘s aus dem 192.168.1….Bereich. Wenn ich jetzt gerne von meinen Endgeräten auf die Fritzbox zugreifen möchte funktioniert das natürlich nicht. Wie bewerkstellige ich das ich mit meinen Endgeräten auf die Fritzbox komme. Wäre für Lösungen echt dankbar !
Gruß Lothar

Antworten
1. Martin Ziegler sagt:
  
  24. März 2020 um 7:26 Uhr
  
  Hallo Lother,
  ich bin mir nicht ganz sicher wie deine Konfiguration aussieht. Eventuell hilft dir das (Achtung: wenn deine Konfiguration nicht so ist, wie ich sie mir vorstelle, macht der Vorschlag Probleme):
  
  Du kannst mit der USG ein Netz (ohne DHCP) für 192.168.178.0/24 konfigurieren und ohne VLAN Tag auf einen Port eines UniFi Switch legen. An diesen Port schließt du deine FritzBox (einen Anschluss: LAN1 bis LAN4) an.
  
  Gruß
  Martin
  
  Antworten
Onkel Tom sagt:

23. März 2020 um 23:15 Uhr

Hallo in die Runde,

habe nach der o.g. Anleitung mein UniFi USG hinter einer FB7530 ohne doppeltes NAT zum Laufen bekommen. Vielen Dank an dieser Stelle nochmals für die gute Beschreibung.

Allerdings bekomme ich den VPN-Zugang nicht zum Laufen.
Die beschriebene Firewall-Regel habe ich im UniFi-Controller hinzugefügt.
Leider kommt die VPN-Leitung dennoch nicht zustande.

Hier meine Einstellungen:

FB7530:
IP: 192.168.178.1
stat. Routing: Netzwerk 192.168.1.0 Gateway 192.168.178.10
VPN: IP 192.168.178.201

USG:
WAN: stat. IP 192.168.178.10 LAN 192.168.1.1
Firewall-WANin-Regel: Quelle IP 192.168.178.201 Ziel IP 192.168.1.1
(Aktiviert, Positionierung, Aktion, IPv4-Protokoll alle wie oben beschrieben)

Was mache ich falsch ?

Für hilfreiche Hinweise wäre ich sehr dankbar.

Gruß
Onkel Tom

Antworten
1. Martin Ziegler sagt:
  
  24. März 2020 um 7:32 Uhr
  
  Hallo Tom,
  
  schön, dass das Deaktivieren des NAT für dich funktioniert hat. Zu deinem VPN-Problem:
  Du beschreibst die Firewallfreischaltung: “Firewall-WANin-Regel: Quelle IP 192.168.178.201 Ziel IP 192.168.1.1”. Ich habe bei mir als Ziel das IP-Subnetz “hinter” dem USG, auf das zugegriffen werden soll konfiguriert, nicht die IP des USG. Alternativ könntest du gezielt IPs als Gruppe hinter deinem USG freigeben. Die IP des USG macht allerdings nur in speziellen Fällen (zum Beispiel: SSH Zugriff auf das USG per VPN) Sinn.
  
  Ich hoffe das hilft dir etwas weiter.
  
  Gruß
  
  Martin
  
  Antworten
  1. Onkel Tom sagt:
    
    24. März 2020 um 20:17 Uhr
    
    Hallo Martin,
    
    Danke für die schnelle Antwort, die mich einen Schritt weitergebracht hat:
    
    Nach Änderung des Ziels in der Firewall-Regel auf:
    Netzwerk – LAN – IPv4-Subnetz oder Gateway IP-Adresse (beides probiert)
    kommt die VPN-Verbindung jetzt zustande. Super !
    
    Allerdings kann ich dann im Browser keine Seiten erreichen, weder im LAN (192.168.1. …) noch im www.
    
    Woran könnte das liegen ?
    
    Grüße
    Onkel Tom
    
    Antworten
    1. Martin Ziegler sagt:
      
      25. März 2020 um 17:34 Uhr
      
      Hallo Tom,
      baust du die VPN Verbindung zur Fritz!Box oder zum USG auf? Meine Anmerkungen waren für das VPN zur FritzBox und dann “normalen” IP-Verkehr in deinen Netzen gedacht. Ich frage, weil die VPN Verbindung zur Fritz!Box unabhängig von den Firewallregeln der USG zustande kommen sollte. Die Firewallregel ist dann “nur” dafür da, dass du mit der IP, die die Fritz!Box deinem VPN-Client gibt auch in die Netze hinter dem USG kommst. Dein “Browser” läuft auf einem Rechner, dem vom “Internet” über VPN auf dein Netz zugreift?
      
      Gruß
      Martin
      
      Antworten
      1. Onkel Tom sagt:
        
        25. März 2020 um 18:57 Uhr
        
        Hallo Martin,
        
        ja, ich baue eine VPN-Verbindung (IPSec) über das Internet zur FritzBox (über …myfritz.net) auf.
        
        Dabei habe ich jetzt übrigens festgestellt, dass das Aufrufen der IP-Adresse meiner FritzBox (192.178.1.1) funktioniert und ich tatsächlich auf der Anmeldeseite der FritzBox lande. Jede andere LAN-Adresse (192.168….) geht nicht.
        Vielleicht hilft das weiter, die Ursache einzugrenzen oder zu identifizieren.
        
        Gerne weitere Hilfe-Hinweise.
        Vielen Dank.
        
        Grüße
        Onkel Tom
        
        Antworten
        
        Martin Ziegler sagt:
        
        28. März 2020 um 7:58 Uhr
        
        Hallo Tom,
        
        deine anderen beiden Post habe ich gelöscht, da sie im Prinzip die gleiche Frage wie dieses enthalten – sonst wird’s noch unübersichtlicher als es jetzt schon ist. Wenn du eine VPN Verbindung in das Netz deiner FritzBox aufbauen kannst, kommst du ohne Anpassungen in der Firewall des USG nicht in die Netze “hinter” dem USG. Das USG lässt in der Standardeinstellung keine Netzwerkpakete vom WAN-Interface des USG in die Netze “hinter” sich, wenn die Verbindung nicht initial aus einem Netz “hinter” dem USG aufgebaut wurde. Um trotzdem auf Geräte hinter dem USG zugreifen zu können, musst du die IP Adresse, die dein VPN-Client von der Fritzbox erhält (bei einem Client, die erste IP hinter dem Range, den die FritzBox per DHCP vergibt) in der Firewall des USG für den Zugriff auf durch das USG geschützte Netze oder IPs erlauben (siehe Abschnitt “Zugriff vom FRITZ!Box Subnet durch das Security Gateway in die anderen Subnets freigeben” im Artikel).
        
        Gruß
        
        Martin
        
        Antworten
        
        Onkel Tom sagt:
        
        28. März 2020 um 10:53 Uhr
        
        Hallo Martin,
        
        Danke für deine erneut schnelle Antwort.
        
        Mein VPPN-Client bekommt von der FritzBox die IP 192.168.178.201.
        Dies wird in den FritzBox-Einstellungen unter Internet > Freigabe > VPN bestätigt, ebenso die grüne Ampel für den Status.
        Ich gehe also davon aus, dasss die FritzBox den VPN-Tunnel soweit korrekt herstellt.
        Dazu passt auch, dass ich über den VPN-Tunnel auf die interne IP meiner FritzBox (192.168.178.1) zugreifen kann.
        
        Den Fehler vermute ich auch in den USG-Einstellungen.
        Dort habe ich – wie von dir auch beschrieben – im UniFi-Controller eine Firewall-Regel wie folgt angelegt:
        – Quell-Typ: IP-Adresse 192.168.178.201 (keine MAC-Adresse)
        – Ziel-Typ: “LAN-Netzwerk” mit IPv4-Subnetz.
        
        Das “LAN-Netzwerk” hatte ich schon vorher im UniFi-Controller unter “Netzwerke” angelegt und erstmal nicht verändert:
        Verwendung: Unternehmen
        Gateway/Subnetz: 192.168.1.1/24
        Kann hier noch eine fehlerhafte Einstellung liegen ?
        
        Ansonsten komme ich vom Internet (IPhone über LTE/nicht WLAN mit den VPN-FritzBox-Einstellungen) weiterhin leider nicht auf interne LAN-Seiten (192.168.1. …).
        Won kann der Fehler sonst noch liegen ?
        
        Besten Dank für jeden Hinweis.
        
        Viele Grüße
        Onkel Tom
        
        Antworten
        
        Onkel Tom sagt:
        
        28. März 2020 um 17:16 Uhr
        
        Hallo zusammen,
        
        jetzt geht es !!!!
        
        Das Neu-Starten der FritzBox sowie Provisionieren der UniFi-Geräte (USG,Switch,APs) brachte den Erfolg.
        
        Vielen Dank dennoch für eure Hilfe.
        
        Viele Grüße
        Onkel Tom
        
        Antworten
Onkel Tom sagt:

28. März 2020 um 20:59 Uhr

Hallo zusammen,

mittlerweile bin ich begeistert, wie gut die Intergration meines neuen USG gemäß der tollen Anleitung inkl. VPN funktioniert !!
Dann habe ich aber heute doch noch ein weiteres Problem festgestellt:

Meine FritzBox 7530 dient weiterhin als Telefonzentrale.
Ich nutze als OS die neue Laborversion Nr. 07.19-76431 BETA,
da ich die Synchronisation des FritzBox-Telefonbuchs mit meinem CardDav-Server auf dem NAS realisieren möchte.

Vor der Installation des USG lief der Zugriff auf den NAS (192.168.1.2) mit folgender Adresse für den CardDav-Server: “https://192.168.1.2:8448/addressbooks”

Jetzt scheitert der Zugriff.
Kann es sein, dass ich den Port 8448 öffnen/durchleiten muss ?

Wäre super, wenn jemand hier helfen kann.

Viele Grüße
Onkel Tom

Antworten
1. Martin Ziegler sagt:
  
  30. März 2020 um 11:54 Uhr
  
  Hallo Tom,
  
  freut mich das es inzwischen funktioniert. Wenn Die FritzBox 192.168.178.1/24 (vor USG) auf 192.168.168.1.2:8448 (hinter USG) zugreifen soll, musst du den Zugriff, wie von dir vermutet, in der Firewall des USG erlauben. Für das USG sind alle Pakete, die am WAN-Interface ankommen und nicht zu einer Verbindung gehören, die von “hinter” dem USG aufgebaut wurde, nicht vertrauenswürdig.
  
  Gruß
  
  Martin
  
  Antworten
Ali sagt:

6. April 2020 um 4:53 Uhr

Hi Martin,

die Anleitung ist ein Hammer. Es hat Aufanhieb funktioniert. Ich habe die letzten Wochen das Internet auf den Kopf gestellt um eine vernünftige L2TP Verbindung herzustellen. Es hat einfach nicht funktioniert. Durch Zufall bin ich auf den Blog aufmerksam geworden.

Ich habe noch eine Frage bzgl. Fritzfax. Gibt es eine Möglichkeit aus dem USG Netz zurück auf das Fritzbox Netz zuzugreifen und das Fritzfax zu nutzen?

Grüße
Ali

Antworten
1. Martin Ziegler sagt:
  
  6. April 2020 um 9:07 Uhr
  
  Hallo Ali,
  
  ich nutze das FritzFax in der Regel nur noch zum Testen von Fax Geräten anderer – dafür nehme ich die Weboberfläche der FritzBox. Ich vermute, du willst den “Drucktreiber” zum Faxen nutzen. Das geht auch, aber so weit ich mich erinnere, nicht automatisch. Generell muss du “CAPIoTCP” in der FritzBox über ein Telefon mit “#96*3*” aktivieren. Ich musste damals zusätzlich die IP der FritzBox in der Registry eintragen. Ist schon eine Weile her. Mit einer aktuellen Windows 10 Installation habe ich es noch nicht eingerichtet.
  
  Hilft dir das weiter?
  
  Gruß
  
  Martin
  
  Antworten
2. Martin Ziegler sagt:
  
  6. April 2020 um 9:17 Uhr
  
  Hallo Ali,
  
  kleiner Nachtrag: auf der Seite von IT SOLUTIONS | Falk von Broen (ich stehe ich keinerlei Verbindung zu dieser Firma) wird sehr schön Schritt für Schritt durch den Installationsprozess geführt. In den Kommentaren wird auch auf den relevanten Schlüssel in der Registry eingegangen.
  
  Gruß
  
  Martin
  
  Antworten
  1. Ali sagt:
    
    6. April 2020 um 21:46 Uhr
    
    Danke erstmal für schnelle Rückmeldung. Es hat vorher ohne Probleme funktioniert. Seitdem ich den USG dazwischen gepackt habe, war ein faxen nicht mehr möglich.
    
    Antworten
    1. Jürgen sagt:
      
      18. April 2020 um 21:33 Uhr
      
      Konntest Du das Problem schon lösen? Wäre es eine Idee den zweiten LAN Port wieder an die Fritzbox zu hängen und im USG eine Freigabe für das Faxen zu machen?
      
      Antworten
Urban sagt:

8. April 2020 um 13:08 Uhr

Hallo und Danke für deine gute Anleitung.
Auch ich habe bei der USG mit der oben beschriebenen Methode NAT deaktiviert. Es hat bis auf die WLAN’s geklappt.
Internet – FBNetz – USGNetz
Das heißt über Kabel funktioniert der Zugang vom FBNetz zum USGNetz.
Alle WLAN’s haben kein Internet.
Auch nach löschen aller WLAN’s und auf sie bezogegen FW-Regeln und Netze und nach erneutem Hinzufügen (mit gleichen Einstellungen) kein Internet für WLAN.
Hier gab es auch schon einen Poster der das Problem mit neuer Adressvergabe gelöst hat.
Wie das genau geht ist mir aber nicht klar, hat er die USG komplett neu eingerichtet?

Antworten
1. Uwe sagt:
  
  8. April 2020 um 16:41 Uhr
  
  Lege in der FB Routen auf alle Netzwerke hinter der USG an.
  
  Antworten
  1. Urban sagt:
    
    14. April 2020 um 10:07 Uhr
    
    Danke, das wars.
    
    Antworten
Stefan sagt:

8. April 2020 um 13:11 Uhr

Hallo Martin,

nachdem ich dank deiner Anleitung das NAT auf meinem USG abschalten konnte und mein Netzwerk super läuft, spiele ich mitdem Gedanken, auf eine Unifi Dream Machine umzusteigen.
Weist du, ob das abschalten des NAT auf der Dream Machine genauso funktioniert? Oder sieht die Software da anders aus, weil da ja mehrere Komponente zusammen verbaut wurden.

Viele Grüße
Stefan

Antworten
1. Felix sagt:
  
  8. April 2020 um 17:07 Uhr
  
  Hallo Stafan,
  
  ich bin zwar nicht Martin, aber ich kann dir dennoch eine Antwort geben. Das geht mit der UDM Pro (ich vermute du meinst die Pro und nicht dieses komische Ei) NICHT. Eine Anpassung über eine json-Datei ist, wenn ich es richtig in Erinnerung habe, generell nicht möglich bei der UDM Pro. Einer der Gründe warum ich keine besitze.
  Die Antwort auf deine Frage findet sich übrigens auch schon hier irgendwo ;-). Ich konnte sie aber auf die schnelle auch nicht finden.
  Hier der Thread im Unifi-Forum dazu: https://community.ui.com/questions/UDM-Pro-Confirm-no-config-gateway-json-allowed-possible/b451feeb-9e67-4cc4-8344-b2c8759c8bd7
  
  Gruß
  
  Felix
  
  Antworten
  1. Christian sagt:
    
    17. September 2020 um 22:58 Uhr
    
    Hallo Stefan, Hallo Felix,
    
    Ich habe den hier beschriebenen Ansatz heute erfolgreich auf der UDM-Pro ans Laufen bekommen.
    
    Zwar gibt es tatsächlich keine Möglichkeit NAT einfach per Json-Konfiguration zu deaktivieren, aber man kann das direkt per iptables machen und dank https://github.com/boostchicken/udm-utilities auch persistieren.
    
    Im Prinzip einfach diese Anleitung befolgen: https://community.ui.com/questions/disable-NAT-in-UDM-pro/f5a97c47-e6bf-4ebf-a899-0c4271e8e6a2#answer/07f4aa8b-dfee-4246-92cd-2b535c3d9330
    
    Grüße
    Christian
    
    Antworten
Juergen sagt:

16. April 2020 um 0:12 Uhr

Nachdem ich vor kurzem zu Unifi APs gewechselt bin (anhaltende Probleme mit dem Fritzbox WLAN im Altbau und fehlgeschlagenen und teuren Mesh und Powerline Versuchen) habe ich mittlerweile einen CloudKey GEN2 und ganz frisch ein USG3 angeschafft. Leider habe ich bisher nur Ausfälle und wollte nun nochmal von vorne starten.

Meine Konfiguration:
Telekom VDSL2
Fritzbox 7590
Fritzbox macht bisher DHCP auf 192.168.178.xxx

Was ich gerne machen würde:
USG anschließen, geschafft habe ich es schon dass sie eine feste IP 192.168.178.10 bekommt. Ich habe dann versucht eine statische Route einzurichten aber hatte hinter dem USG kein Internet
Nat an der USG ausschalten
Fritzbox weiter für Telefonie nutzen

Konkrete Fragen:
Muss ich die USG als exposed host in der Fritzbox konfigurieren?
Wann lege ich die statische Route an?

Wäre toll wenn das nochmal einer in die richtige Reihenfolge bringt… ich bin zu doof

Antworten
1. Martin Ziegler sagt:
  
  20. April 2020 um 14:52 Uhr
  Hallo Jürgen,
  
  Das was du vorhast ist machbar. Zu deinen Fragen:
  - Du musst das USG nicht als “Exposed Host” konfigurieren.
  - Die statische Route auf die Netze “hinter” dem USG legst du an bevor du NAT auf dem USG deaktivierst. Oder danach, wenn du es davor vergessen hast ;-). Du brauchst nur dann statische Routen, wenn du NAT im USG deaktivierst. Ansonsten kannst du darauf verzichten.
  Bei den statischen Routen ist weniger die Reihenfolge entscheidend, als das sie technisch richtig konfiguriert sind. Wenn du noch Probleme hast, schreib einfach deine Konfiguration zusammen, so lässt sich die Ursache für deine Ausfälle leichter finden.
  
  Gruß
  
  Martin
  Antworten
Thomas sagt:

16. April 2020 um 19:49 Uhr

Ich habe eine Anmerkung zu den gewählten Netzen und den Router. Ich habe ein ähnliches Konstrukt. Allerdings mit Fritzbox und Edgerouter.

Transfer Netz Fritzbox UBNT:
IP Fritzbox 10.10.10.254
IP UBNT 10.10.10.1
Subnetzmaske 255.255.255.0

Netze hinter UBNT:
192.168.1.0 (255.255.255.0)
192.168.2.0 (255.255.255.0)
…
192.168.9.0 (255.255.255.0)

Durch die Wahl des Transfernetzes nicht in 192.168.x.x vereinfacht sich das Routing auf der Fritte.
Es ist noch genau 1 Routingeintrag auf der Fritte notwendig:
192.168.0.0 255.255.0.0 über Gateway 10.10.10.1
Alle 192.168-er Netze sind über den 10.10.10.1 erreichbar. Wenn ich jetzt 192.168.19.0 aufmache, muss ich an der Fritte nichts anpassen

Antworten
1. Martin Ziegler sagt:
  
  20. April 2020 um 15:10 Uhr
  
  Hallo Thomas,
  
  guter Hinweis. Die 16 Bit Netzmaske fürs Routing macht es bei der nachträglichen Konfiguration einfacher.
  Solange das Subnetz der FritzBox aus einem anderen 16-Bit Subnetz kommt und beim Zusammenschluss verschiedener VPNs darauf geachtet wird, dass es keine Subnetz-Überschneidungen gibt, sollte es für die meisten Anwendungsfälle in Ordnung sein.
  
  Danke für den Tipp
  
  Gruß
  
  Martin
  
  Antworten
Olli sagt:

26. April 2020 um 0:38 Uhr

Hallo,
vielen Dank für die tolle Anleitung. Das hat bei mir alles geklappt und läuft soweit!
Nur ein kleines Problem habe ich noch:
Und zwar kann ich mein Synology NAS sowie den darauf mit Docker Container laufenden Unifi Controller nur noch mit IP-Adresse erreichen und nicht mehr mit “meinNAS:5000” (DSM) oder “meinNAS:8443” (für Controller). Das ging vorher (ohne USG) aber noch.
Liegt das am deaktiviertem NAT? Oder wie könnte ich das wieder hinbekommen?
Danke & Viele Grüße
Olli

Antworten
1. Martin Ziegler sagt:
  
  26. April 2020 um 19:04 Uhr
  
  Hallo Olli,
  
  funktioniert der Zugriff, wenn du anstelle von meinNAS:5000 meinNAS.localdomain:5000 verwendest?
  
  Bekommen dein NAS & dein PC beide ihre IP Adressen per DHCP vom USG und ist das USG auch als DNS Server hinterlegt? Wenn nicht, wie sieht dein Konfiguration aus?
  
  Liegt das am deaktiviertem NAT? – nein, das ist ein DNS-Konfigurations-“Problem”.
  
  Gruß
  
  Martin
  
  Antworten
  1. Olli sagt:
    
    5. Mai 2020 um 12:18 Uhr
    
    Hallo Martin,
    vielen Dank. Ohne das ich was gemacht habe, funktioniert es jetzt. Vielleicht war ich zu ungeduldig.
    Danke & Viele Grüße
    Olli
    
    Antworten
Thomas H. sagt:

26. April 2020 um 12:14 Uhr

Hallo Martin,

hatte ja vor einiger Zeit das Problem, das ich nicht in´s Internet gekommen bin.
Habe dir dann das Bild geschickt wie es bei mir klappt.
Nun hat sich leider mein QNAP Server aufgehängt; keinen Zugriff mehr auf den UniFi Controller.
Den Unifi Controller nun wieder lokal auf einem PC installiert.

Doppeltes Nat deaktiviert.

Habe nun das Problem, dass ich mit WLan Netzwerken denen ich eine VLAN Nummer gebe innerhalb meines Netzwerkes kommunizieren kann, jedoch keinen Internetzugang bekomme.

Kannst du mir eine Idee geben wo mein Gedankenfehler ist?

Danke
Gruß
Thomas

Antworten
1. Martin Ziegler sagt:
  
  26. April 2020 um 19:07 Uhr
  
  Hallo Thomas,
  
  hast du in deiner FritzBox für jedes Subnetz (VLAN,LAN) hinter deinem USG eine eigene Route definiert? Wenn nicht, wäre das eine mögliche Ursache.
  
  Gruß
  
  Martin
  
  Antworten
  1. Thomas sagt:
    
    29. April 2020 um 13:43 Uhr
    
    Hallo Martin,
    
    genau das war das Problem. In der Fritzbox unter Heimnetz / Netzwerk / IPv4-Route nur das Routing meines “Standard” Netzwerkes eingesetellt und mein neues VLAN Netzwerk vergessen.
    
    Danke für den Tip.
    
    Gruß
    Thomas
    
    Antworten
Holger Haslbeck sagt:

28. April 2020 um 18:33 Uhr

Hallo Martin!

Vielen Dank für die Anleitung das hat alles perfekt funktioniert. Ich habe eine Problem/Frage, die glaube ich, mit der Anleitung nichts zu tun hat, aber vielleicht hast Du einen Tipp durch deine Erfahrung mit Fritzbox und USG:

Ich habe seit einiger Zeit ein seltsames Problem: Meine Bandbreite ins WAN aus dem Netz hinter meiner USG hat sich dramatisch verschlechtert. Vor der USG, an der Fritzbox 6591, erreiche ich bei Vodafone mindestens 85% der Gigabit Bandbreite, hinter der USG nur noch 30% Downstream. Upstream (50 Mbit, ist immer in Ordnung). Gleicher Rechner, Speedtest von Vodafone, Speedtest.net, File Downloads, etc. Gleiche Tageszeit (15 Sekunden zwischen den Tests beim Umstecken des LAN Kabels).

Hier mein Setup und die bisherigen Tests (die mich etwas verwirren):

Vodafone – Fritzbox – USG – Unifi Switch – Unifi Switches, Accesspoints + Netgear Gigabit Switches.

Doppeltes NAT ist per Config File im Controller in der USG nach deiner Anleitung ausgeschaltet. Die Fritzbox hat statische Route(n), zwei wegen eines Gast-Netzwerkes, zur USG eingetragen. Damit funktioniert alles, Telefonie über die Fritzbox, die Fritzbox ist bei mir der VPN Endpunkt und kümmert sich auch um DynDNS. Alle Online Anwendungen gehen ohne Probleme: Ausgehendes VPN, Online Spiele, Videotelefonie, etc.

Alle Performancetests die ich mache sind natürlich nur per LAN Kabel mit Gigabit NICs, alle Switches sind Gigabit Switches. Ob da Netgear Switches auf dem “Weg ins Internet” dabei sind und wieviele, ist egal. Das Problem besteht auch direkt an der USG.

Um auszuschliessen, dass es innerhalb des Netzwerks hinter der USG ein Problem gibt, habe ich auf zwei Macs iperf3 installiert und damit die Bandbreite gemessen. Kein Problem, die Gigabit Bandbreite wird erreicht (abzüglich des geringen Traffics anderer Geräte im Netz). Dabei gibt es kaum Unterschiede wieviele Switches zwischen Client und Server sind.

Nun habe ich einen Mac als iperf-Server an einen freien Fritzbox LAN Port gehängt. Der Mac bekommt eine IP im Fritzbox Netz und ich starte auf dem anderen Mac einen iperf-Test aus dem USG Netz. Der Traffic läuft also über die USG und über die Fritzbox zu dem iperf3-Server der an der Fritzbox hängt. Auch hier werden die netto Gigabit Bandbreite (932 Mbits/sec) geschafft.

IPS/IDS sind nicht aktiviert, wenn man die aktiviert sinkt auch erwartungsgemäß die Bandbreite zwischen den beiden Macs auf ca.110 Mbit/sec.

Nun die Frage: Was ist das Problem, das ich auf dem Mac, der an der Fritzbox hängt und der mit 932 Mbits/sec mit dem Mac hinter der USG kommuniziert, mit 830 Mbit ins Internet komme, der Mac hinter der USG (aber auch der gleiche Mac wenn ich ihn hinter die USG hänge) nur mit 300 Mbit?

Ich glaube auch, dass ich nichts geändert habe und ich vor einigen Wochen, auch hinter der USG die volle Bandbreite ins Internet hatte.

Downgrades zu den letzten 3 Firmware-Ständen der USG habe ich auch durchgeführt. Hardware-Offload etc. sind aktiviert und sollten da ich ja “Vollgas” zur Fritzbox komme auch nicht das Problem sein.

Gibt es da eine Idee was das ein könnte?

Antworten
1. Martin Ziegler sagt:
  
  2. Mai 2020 um 18:30 Uhr
  Hallo Holger,
  mein erster Gedanke wäre das IDS/IPS – was du allerdings bereits ausgeschlossen hast.
  - Hast du beim Testen geprüft, ob die Pakete mehrfach schickst, zum Beispiel wegen falscher MTU Größen?
  - Wie ist die CPU Auslastung des USG?
  - Hast du mit dem Test-PC direkt im USG LAN Port die Messung durchgeführt? Um Probleme bei den anderen Komponenten auszuschließen. (Hast du eigentlich schon durch deine internen Speed-Tests gemacht).
  Aus der Entfernung kann ich leider nicht mehr sagen.
  
  Gruß
  
  Martin
  Antworten
  1. Holger Haslbeck sagt:
    
    4. Mai 2020 um 16:42 Uhr
    
    Hallo Marin!
    
    Danke für das Feedback. Ich habe das Problem gefunden:
    
    Wenn ich die USG an LAN Port 1 oder 2 der Fritzbox anschliesse, habe ich 200-300 Mbit ins Internet. An Port 3 geht es dann “Vollgas” mit bis zu 980 Mbit.
    
    Dabei sind alle Ports NICHT im Stromsparmodus.
    
    Bei mir ist es die Fritzbox 6951 Cable. Bei dem Hinweis einem der Foren (hatte nichts mit der USG aber mit Bandbreite übers LAN zu tun, finde den Link nicht mehr) ging es um eine andere Fritzbox.
    
    Es gibt auch Hinweise zu Fritzboxen die Gigabit Autosense Probleme auf allen LAN Ports ausser Port 3 haben (das kann es bei 300 Mbit dann doch nicht gewesen sein).
    
    Anscheinend ist der “Magic LAN Port” der Fritzbox Port 3.
    
    Grüße,
    Hoger
    
    Antworten
    1. Martin Ziegler sagt:
      
      8. Mai 2020 um 16:38 Uhr
      
      Hallo Holger,
      
      das ist interessant. Bisher hatte ich einen solchen Fall noch nicht, werde es mir aber merken. Auf die Idee, dass die Ports sich unterschiedlich verhalten, muss man erst mal kommen.
      
      Gruß
      
      Martin
      
      Antworten
Joachim K. sagt:

28. April 2020 um 23:12 Uhr

Hallo Martin,

Cooler Blog, der endlich Licht ins Dunkel gebracht hat! Kompliment!
Ich habe eine Frage zu NAT,
Was ist der Vor-/Nachteil wenn USG kein NAT mehr machen kann sondern nur die FritzBox?
Gibt es dadurch irgendein Nachteil/Einschränkung?

V.a i Vergleich meinem geplanten Setup
Draytek Vigor 165 = Modem
USG4 Pro = Router
Fritzbox = Telefonie sowie einige von Dir genannten Funktionen halt als Client.

Was ich verstehe, in deinem gewählten Setup, hast du ein Gerät/Hersteller weniger und bist ISP konform. Für mich stellt sich halt die Frage was der Nachteil ist USG kein NAT und hinter der FB imVergleich USG macht NAT und FB ist als Client hinter USG?

Danke für deine Einschätzung 👍🏼

Antworten
1. Martin Ziegler sagt:
  
  2. Mai 2020 um 18:41 Uhr
  
  Hallo Joachim,
  
  wenn das USG als 2. Router in deinem LAN kein NAT durchführt, hast du keine Nachteile. Mit aktivem (doppeltem) NAT kannst du bei manchen Anwendungen Probleme haben. Dein geplantes Setup funktioniert auch. Da ich persönlich gute Erfahrungen mit der Hardware von AVM gemacht habe, wollte ich, nach ersten Tests mit dem Draytek Vigor 165, nicht wechseln. Das ist jedoch eher eine subjektive Entscheidung gewesen – ein ordentliches Netzwerksetup bekommst du auf verschiedenen Wegen hin, wie die unterschiedlichen Vorschläge und Erfahrungen in den Kommentaren zeigen.
  
  Einschätzung: Wenn ich es für mich einrichte, mache ich es so wie ich es beschrieben habe. Wenn ich es für jemand anderen einrichte, mache ich es so wie er will. Wenn es ihm egal ist, so wie ich’s bei mir eingerichtet habe. Was für dich richtig ist, kann ich dir nicht sagen, nur, dass, egal welchen Weg du nimmst, es am Ende funktioniert – solange du keinen Fehler gemacht hast ;-).
  
  Gruß
  
  Martin
  
  Antworten
  1. Matthias sagt:
    
    5. September 2020 um 8:32 Uhr
    
    Wenn es keinen Unterschied macht wäre es doch immer sinnvoll das weitere Gerät zu sparen.
    Gibt es vor und Nachteile der Varianten?
    
    Antworten
    1. Martin Ziegler sagt:
      
      6. September 2020 um 20:33 Uhr
      
      Hallo Matthias,
      leider geht für mich nicht ganz hervor, auf welche Geräte du dich beziehst. Ich vermute, du meinst ob die die Fritz!Box vor dem USG hast? Wenn ja, kannst du dir kein Gerät sparen, da das USG kein integriertes Modem hat. Irgendwas musst du davor hängen, wenn du dich nicht direkt in ein Ethernet hängst. O du dich dann für einen Router wie die Fritz!Box oder ein Modem entscheidest, hat Vor- und Nachteile, abhängig davon, was du für dich benötigst.
      
      Gruß
      
      Martin
      
      Antworten
Daniel Walter sagt:

9. Mai 2020 um 21:03 Uhr

Hallo Martin,

danke für diesen tollen Artikel und für Dein Engagement uns hier zu unterstützen 😉

Ich habe ebenfalls die Fritzbox 7590 sowie die USG mit dahinterliegendem LAN.
Ich habe eine Frage zu der “Kindersicherung” der Fritzbox. Ich finde diese ganz gelungen und würde diese gerne weiterverwenden, um die Zeiten und das Internet-Kontingent für die Endgeräte meines Kindes zu steuern.
Die Fritzbox hat intern die 192.168.10.1 im 255.255.255.0 Subnetz und ist DHCP-Server.
Die USG hängt mit einem “Bein” in diesem Netzwerk und bezieht von der Fritzbox die 192.168.77.101. Das andere “Bein” der USG ist im LAN mit der IP 192.168.77.7 und ist DHCP-Server für alle LAN-Geräte.
Wenn ich nun in der Fritzbox mir die Filterregeln (Internet->Filter->Kindersicherung) ansehe, erscheinen dort nur noch die IP-Adressen aus dem Netzwerk 192.168.10.x und keine IP-Adressen aus dem LAN (192.168.77.x). Ergo ich kann keine Filterung einsetzen.

Hast Du eine Idee, wie ich auf der Fritzbox die IP-Adressen aus dem LAN-Netzwerk in der Fritzbox unter “Kindersicherung” sichtbar machen kann, damit ich auf diese eine Kindersicherung aktivieren kann?

Viele Grüße!
Daniel

Antworten
1. Martin Ziegler sagt:
  
  15. Mai 2020 um 17:35 Uhr
  
  Hallo Daniel,
  
  wenn du NAT auf dem USG deaktivierst, kannst du für die IP Adressen hinter dem USG die Kindersicherung in der FritzBox aktivieren. Wenn die IP nicht in der Heimnetz-Liste der FritzBox aufgeführt ist, kannst du eine Portfreigabe für die IP manuell einrichten, anschließen die Kindersicherung konfigurieren und dann die Portfreigabe wieder entfernen. Du musst sicherstellen, dass die Geräte vom USG eine feste IP bekommen.
  
  Hilft dir das weiter?
  
  Gruß
  Martin
  
  Antworten
  1. Daniel Walter sagt:
    
    16. Mai 2020 um 17:07 Uhr
    
    Hallo Martin,
    
    danke erstmal für Dein Feedback und Deine Zeit!
    
    Ich habe Deine obige Anleitung zur Deaktivierung des NAT auf der USG verwendet. Habe das Routing für die nach der USG befindlichen Subnetze eingerichtet. Dann auf der Fritzbox die Portfreigabe für ein Endgerät erstellt. Dann konnte ich die Kindersicherung auf dieses Gerät einrichten. Danach habe ich die Portfreigabe wieder entfernt. Leider greift die Kindesicherung noch nicht.
    Ich bin mir nicht sicher ob ich das NAT erfolgreich ausgeschaltet habe. Ich nutze die Synology für den Controller. Somit habe ich Docker im Einsatz. Leider finde ich das Verzeichnis nicht, in dem die config.gateway.json abgelegt werden sollte. Die Unterverzeichnisse “Site” oder “Default” finde ich nicht. Kannst Du mir hier noch einmal behilflich sein.
    
    Wo sollte ich die config.gateway.json ablegen wenn ich Synology+Docker nutze?
    
    Antworten
  2. Daniel Walter sagt:
    
    16. Mai 2020 um 21:44 Uhr
    
    …kleiner Nachtrag:
    
    Internet Fritzbox USG LAN
    
    Fritzbox:
    192.168.10.1
    255.255.255.0
    
    USG-WAN
    192.168.10.101
    255.255.255.0
    
    USG-LAN
    192.168.77.7
    255.255.255.0
    
    Subnetze im LAN:
    192.168.77.0
    und
    192.168.20.0
    
    Die Nintendo-Switch mit der IP 192.168.20.12 soll über die Kindersicherung der Fritzbox gesteuert werden. Dauer der Online-Zeit und “Kontigent”.
    
    Wenn ich nun auf der Fritzbox eine Portfreigabe für die Nintendo-Switch 192.168.20.12 erteile und das Häckchen bei “Selbstständige Portfreigaben für dieses Gerät erlauben” setze kann ich wie erwähnt auf diesem Eintrag die Kindesicherung setzen.
    
    Abgesheen von meinem obigen heutigen Post mit der config.gateway.json passiert nach Aktivierung der Kindersicherung auf der Fritzbox folgendes:
    Sämtliche Clients aus dem LAN haben keine Internetverbindung mehr. Erst wenn ich die Kindersicherung für diese eine IP (192.168.20.12) wieder deaktiviere, haben alle Clients wieder eine Internet-Verbindung.
    
    Was könnte die Ursache sein?
    
    Antworten
    1. Martin Ziegler sagt:
      
      7. Juni 2020 um 20:15 Uhr
      
      Hallo Daniel,
      das ist ein merkwürdiges Verhalten. Ich hab es mir aufgeschrieben und versuche es bei Gelegenheit nachzustellen. Im Moment ist es bei mir leider zeitlich etwas eng…
      
      Gruß Martin
      
      Antworten
Sascha Brode sagt:

10. Mai 2020 um 20:43 Uhr

Hallo würde gerne folgendes machen, wäre super zu wissen ob das so passt.

Fritz – usg – switch – ap

Fritz 192.168.178.0/24
USG 192.168.1.0/24
Und 192.168.2.0/24

Statische Routen zu den beiden letzten Netzen, NAT auf USG aus.
Wenn ich wlan nur über die AP am Switch mache kann ich trotzdem meinen Entertain Receiver direkt an die Fritz ins 192.168.178.0 lan hängen?
So das ich das igmp v3 Problem nicht habe und alle anderen pcs usw hängen am USG und gehen über das ins Netz?

Wäre super wenn das geht brauche das entertain nur an einem Receiver das ginge per lan.
Und Handy und pcs würde ich dann über die USG ins Internet Routen wollen

Antworten
1. Martin Ziegler sagt:
  
  15. Mai 2020 um 17:38 Uhr
  
  Hallo Sascha,
  
  klingt nach einem guten Plan, solange du den Receiver mit einem Kabel in deiner FritzBox stecken hast.
  
  Gruß
  
  Martin
  
  Antworten
vitala sagt:

10. Mai 2020 um 22:54 Uhr

Hallo Martin,

ich habe ein Problem sobald ich “doppelt NAT” per config deaktiviere, können meine Unifi APs und die daran angeschlossenen WLAN Client nicht mehr ins WWW. Intern im 192.168.1.0/24 Netz lassen sich alle anderen Clients pingen.

Ich habe folgende Konfig:

WLAN Clients können ins WWW
Fritzbox: 192.168.10.1
USG WAN Port: 192.168.10.250
USG LAN Port: 192.168.1.1 und verteilt das Netz 192.168.1.0/24
USG doppelt NAT ist aktiv

WLAN Clients können nicht ins WWW
Fritzbox: 192.168.10.1
USG WAN Port: 192.168.10.250
USG LAN Port: 192.168.1.1 und verteilt das Netz 192.168.1.0/24
USG doppelt NAT wurde per config.json deaktiviert und USG Provisioning durchgeführt

Hast du eine Idee, was mein Problem ist?
Gruß

Antworten
1. Martin Ziegler sagt:
  
  15. Mai 2020 um 17:48 Uhr
  
  Hallo Vitala,
  
  wie sind die statischen Routen in deiner Fritzbox konfiguriert?
  
  Gruß
  Martin
  
  Antworten
  1. vitala sagt:
    
    16. Mai 2020 um 0:38 Uhr
    
    Statische Route sieht wie folgt auf der fritzbox aus:
    
    192.168.1.0
    255.255.255.0
    192.168.10.250
    
    Antworten
Sascha Brode sagt:

14. Mai 2020 um 15:25 Uhr

Hallo habe folgendes Problem:

Fritzbox hat das Netz 192.168.178.1/24
habe die usg auf den lanport der fritzbox gesteckt auf lan 2, lan 1 steckt entertain receiver drin.
die usg hat als wan adresse vom fritz dhcp 192.168.178.250 bekommen.
habe einen pc am usg lan1 hängen, dort hat der pc statisch 192.168.1.10 kann per ssh usw auf die usg.
wenn ich im controller die usg einbinden will, kommt immer adoption failed.
was muss ich tun um die usg einbinden zu können und dann sie so zu konfigurieren das ihr wan port weiter auf die 192.168.178.250 bleibt und sie intern das 192.168.1.1 netz hat und dort meine endgeräte bedient.
statische route auf der fritzbox ist auch eingetragen.

Antworten
1. Martin Ziegler sagt:
  
  15. Mai 2020 um 17:46 Uhr
  
  Hallo Sascha,
  ganz kleine Korrektur: deine Fritzbox hat die IP 192.168.178.1/24 im Netz 192.168.178.0/24. Deine Verkabelung klingt erst mal gut. Die IP des WAN-Ports muss du nicht über den Controller konfigurieren. Diese IP bekommt das USG von der FritzBox per DHCP. Wenn das adoptieren nicht klappt, kannst du das USG zurücksetzen (eventuell hast du das Passwort geändert) und neu importieren (Wenn du im Controller mehrere Sites konfiguriert hast, musst du die richtige nehmen).
  Vom generellen Aufbau her klingt alles gut – da die Konfiguration im Controller liegt, kannst du die anderen Komponenten in der Regel bedenkenlos zurücksetzten. Der Controller bietet die die Möglichkeit ein Backup deiner Konfiguration zu erstellen, was sich generell vor Anpassungen anbietet.
  
  Gruß
  
  Martin
  
  Antworten
Patrick sagt:

18. Mai 2020 um 20:31 Uhr

NAT abschalten bei Dual WAN wird ja dann wahrscheinlich nicht funktionieren, wenn an beiden WAN Ports jeweils eine Fritzbox hängt, oder?

Antworten
1. Martin Ziegler sagt:
  
  7. Juni 2020 um 20:13 Uhr
  
  Hallo Patrick,
  meine Erwartungshaltung wäre, das auch bei Dual WAN NAT deaktiviert werden kann. Eingehender Netzwerkverkehr wird entsprechend der Firewalleinstellungen des USG gefiltert und der ausgehende Netzwerkverkehr anhängig von der Default-Route des USG über WAN 1 oder 2 geführt.
  Gruß
  Martin
  
  Antworten
Patrick sagt:

25. Mai 2020 um 0:07 Uhr

Vielen Dank für den Artikel und die vielen Kommentare.

Ich habe eine Frage, die ich mir irgendwie gerade nicht beantworten kann.

Fritzbox 7590 – 192.168.200.1 -> USG3 WAN 192.168.200.2
USG LAN 192.168.10.1
IP4 Route 192.168.10.0 / 255.255.255.0 / 192.168.200.2 ist gesetzt
Von den USG Netzen komme ich ins Internet, von an der FB angeschlossenen Geräten auch.

Ich kann allerdings nicht aus dem FB Netz IPs in den USG Netzen erreichen (auch kein Ping).
Vielleicht liegt es an der Uhrzeit, ich weiß gerade nicht weiter.

Antworten
1. Martin Ziegler sagt:
  
  7. Juni 2020 um 20:20 Uhr
  
  Hallo Patrick,
  
  ich gehe davon aus, dass NAT deaktiviert ist? Dann muss du den Zugriff aus dem FritzBox Netz in die Netze hinter dem USG in der Firewall des USG erlauben.
  
  Gruß
  
  Martin
  
  Antworten
2. Suburban sagt:
  
  8. Juni 2020 um 9:36 Uhr
  
  Erstelle auf der USG eine WAN_in Regel Quelle ist dein FB-Netz. Wenn ich mich richtig erinnere muss dazu eine IP-Gruppe für dein FB-Netz angelegt werden. Ziel ist dein USG-Netz.
  
  Antworten
Kirsten sagt:

11. Juni 2020 um 23:19 Uhr

Hallo,

vielen Dank für die tollen Anleitung. Soweit klappt auch bei mir alles nur kann ich per FritzVPN nicht auf mein Netzwerk hinter dem USG zugreifen und ich finde den Fehler nicht. Muss man noch etwas in der FritzBox konfigurieren?

Antworten
1. Martin Ziegler sagt:
  
  29. August 2020 um 14:53 Uhr
  
  Hallo Kirsten,
  hast du in der Firewall des USG die Fritz!Box-VPN IPs freigegeben?
  Gruß
  Martin
  
  Antworten
  1. Kirsten sagt:
    
    27. März 2021 um 11:40 Uhr
    
    Hallo Martin,
    
    ich kann mich leider erst jetzt wieder mit dem Thema beschäftigen. Ja die IP Adressen der FritzBox hab ich auf der USG freigegeben.
    
    Antworten
    1. Martin Ziegler sagt:
      
      28. März 2021 um 19:30 Uhr
      
      Hallo Kirsten,
      wenn du
      
      das doppelte NAT in der USG deaktviert hast,
      
      das Routing in der Fritz!Box aktiviert hast,
      
      VPN auf deiner Fritz!Box am Laufen hast und
      
      die VPN-Client-IP Adressen in der Firewall des USG freigegeben hast,
      
      sollte es eigentlich funktionieren. Wenn nicht, hat sich eventuell irgendwo ein Tippfehler oder eine falsche Option eingeschlichen. Bevor du im Detail auf Fehlersuche gehst, kannst du jeden Schritt nach Anleitung neu durchführen, ohne auf das bisher eingerichtete Rücksicht zu nehmen. Wenn du das Gefühlt hast, dass es zum Beispiel auf jeden Fall an der Firewallkonfiguraiton liegt, kannst du diese auch gerne posten – eigene Konfigurationsfehler sind meist schwerer zu finden als die von anderen 😉
      
      Gruß
      Martin
      
      Antworten
Thomas sagt:

7. Juli 2020 um 15:36 Uhr

Hallo und vielen lieben Dank für den super Artikel.
Ich habe derzeit die Fritzbox nicht mehr im Netz, würde aber fast genau dein Setup aufbauen. Allerdings sollen bei mir auch an der Fritzbox Geräte hängen: Entertain Receiver von der Telekom und (da die Verkabelung nicht anderes passt) die WLAN APs von UniFi.
Grundsätzlich sollten diese ja durch die statischen Routen in der Lage sein, sich mit dem Controller zu unterhalten und ihren Job zu erfüllen. Bevor ich jedoch jetzt in irgendetwas reinrenne:
Die befinden sich ja für das USG ja quasi nicht im eigenen Netz.
Hast du dazu eine Idee? Oder soll ich den Gedanken besser verwerfen?

Gruß
Thomas

Antworten
1. Martin Ziegler sagt:
  
  29. August 2020 um 14:50 Uhr
  
  Hallo Thomas,
  
  alle Geräte hinter dem USG können auf die Geräte im Netz deiner Fritz!Box zugreifen. Die Geräte im Netz deiner Fritz!Box können, abhängig von deiner NAT-Konfiguration, den Routen, Portweiterleitungen und Firewalleinstellungen auf Geräte “hinter” dem USG zugreifen. Grundsätzlich also kein Problem. Du musst es nur so einrichten, wie du’s möchtest. Anmerkung: die WLAN-APs von UniFi würde ich persönlich “hinter” das USG und nicht ins Netz der Fritz!Box hängen.
  
  Gruß
  
  Martin
  
  Antworten
Angel Alamo Alonso sagt:

29. Juli 2020 um 15:29 Uhr

Super Anleitung, funktioniert sehr gut.
Aber wie bekomme ich das Logo von der Fritz Box auf den UniFi Controller (Karte).

Danke
Angel

Antworten
1. Martin Ziegler sagt:
  
  29. August 2020 um 14:32 Uhr
  
  Hallo Angel,
  das ist leider nur ein Symbolbild. habe ich mit Gimp erstellt.
  
  Gruß
  
  Martin
  
  Antworten
Dennis Otto sagt:

25. August 2020 um 21:34 Uhr

Hallo Martin,

danke für die Anleitung. Ich habe eine Frage bezüglich dem VPN. Den Punkt mit dem “Quell-Typ: IP-Adresse (im Beispiel 192.168.0.201)” verstehe ich nicht. Muss ich in der Fritzbox noch etwas zu VPN eintragen?

Zuvor ging mein VPN per Draytek -> USG -> L2TP tadellos. Da ich aber probleme habe mit VoIP Telekom und dem Draytek Modem habe ich dieses entfernt und die Fritzbox übernimmt jetzt die einwahl was auch alles funktioniert. Habe das NAT im USG ausgeschaltet (erfolgreich oder nicht keine ahnung).

Jetzt war mir natürlich klar das ich mit dem iPhone nicht wie gewohnt meine VPN Verbindung aufbauen kann aber was muss ich jetzt in der Fritzbox bzw USG abändern damit VPN wieder läuft?

Danke

Antworten
1. Martin Ziegler sagt:
  
  29. August 2020 um 14:44 Uhr
  
  Hallo Otto,
  kommt darauf an, wie du es verwenden möchtest. In meiner Anleitung baue ich eine VPN-Verbindung zur Fritz!Box auf. Du hast, so weit ich dich versteh die VPN-Verbindung bisher zum USG aufgebaut. Entweder du stellst dein VPN auf die Fritz!Box um oder du leitest die relevanten Ports von der Fritz!Box auf dein USG um. Wenn du nichts an deinen Endgeräten ändern möchtest, ist das Weiterleiten der VPN-Ports von der Fritz!Box an dein USG wohl der bequemere Weg.
  
  Gruß
  
  Martin
  
  Antworten
Thomas Baumann sagt:

26. August 2020 um 11:54 Uhr

Hallo Martin,
der Artikel ist prima geschrieben, vielen Dank dafür. Ich habe das in meinem Netz jetzt genauso gelöst, da ich wegen der Telefonfunktionalität nicht auf die FritzBox verzichten wollte.
Kannst du noch verraten, womit du die schönen Netzwerkübersichten erstellt hast?
LG Thomas

Antworten
1. Martin Ziegler sagt:
  
  29. August 2020 um 14:36 Uhr
  
  Hallo Thomas,
  
  die Übersicht liefert dir der UniFi Network Controller. Das Symbol für die Fritz!Box habe ich mit Gimp nachträglich hinzugefügt um mit dem Bild den Text im Artikel zu unterstützen.
  
  Gruß
  
  Martin
  
  Antworten
Roland sagt:

6. September 2020 um 18:08 Uhr

Hallo,
Also ich habe noch an der Fritzbox einen Drucker hängen… diesen sehe ich aus dem Netz des USG nicht mehr….

Antworten
1. Martin Ziegler sagt:
  
  6. September 2020 um 20:30 Uhr
  
  Hallo Roland,
  ist der Drucker per LAN oder USB an der Fritz Box? Was bedeutet “sehen” – kein Ping oder nicht mehr im Autodiscovery? Hast du NAT im USG deaktviert, die Routen in der Fritz!Box eingerichtet und die Fritz!Box als Default-Route in deinem Drucker eingerichtet (wenn er per IP angesprochen wird)?
  Gruß
  Martin
  
  Antworten
Roland sagt:

6. September 2020 um 18:09 Uhr

Mein Controller hängt noch an der Fb. Das USG sehe ich… die Accespoints oder Switches sehe ich nicht…. (bzw. sie haben den Status disconnected)…

Antworten
1. Martin Ziegler sagt:
  
  6. September 2020 um 20:27 Uhr
  
  Hallo Roland,
  ich vermute, du hast NAT auf dem USG deaktiviert und die Routen in der FritzBox eingerichtet? Wenn du dann den Controller “vor” dem “USG” lassen willst, musst du deinen anderen Geräten seine IP mitteilen und die Firewall des USG richtig konfigurieren.
  
  Oder du dimmst alles “hinter” die USG, resetest deine Accespoints und bindest sie danach neu ein, wenn du es “einfacher” haben willst.
  
  Gruß
  Martin
  
  Antworten
Roland sagt:

7. September 2020 um 7:43 Uhr

Hallo Martin,
vielen Dank für Deine Rückmeldung. Ich habe das NAT deaktiviert. Über SSH habe ich gesehen die 5999 ist aktiv. Die Route in der FB ist auch eingerichtet… aus dem LAN des USG kann ich aber weder auf die Geräte im Netz der FB zugreifen, noch komme ich ins Internet….
Was meinst Du mit Fritzbox als Default Route im Drucker einrichten?
Viele Grüße
Roland

Antworten
Roland sagt:

7. September 2020 um 7:51 Uhr

Hallo Martin, Ergänzung: habe eben die Route auf der FB gelöscht und neu eingerichtet… jetzt komme ich ins Internet.

Antworten
1. Martin Ziegler sagt:
  
  7. September 2020 um 17:15 Uhr
  
  Hallo Roland,
  
  freut mich zu hören. Hat sich damit auch dein Druckerproblem gelöst?
  
  Gruß
  
  Martin
  
  Antworten
Roland sagt:

8. September 2020 um 22:00 Uhr

Hallo Martin,
Noch nicht… es geht um Airprint… ich weiß noch nicht wie ich die Drucker erreichen kann…
mein erster Versuch mdns über die config Datei zu aktivieren hat nicht geklappt… USG wollte nicht provisionieren….

Antworten
1. Martin Ziegler sagt:
  
  10. September 2020 um 20:33 Uhr
  
  Hallo Roland,
  
  das einfachste ist, du hast den Drucker im Netz hinter dem USG. Multicasts (mDNS, UPNP) werden vom USG zwar zwischen den eigenen Netzen ausgetauscht aber nicht ohne Aufwand nach “außen” gegeben.
  
  Siehe auch: Probleme bei der Portfreigabe über UPnP von Systemen hinter einem USG ohne NAT und einer FRITZ!Box Ist zwar nicht ganz vergleichbar, sollte vom Problem aber in die gleiche Richtung gehen.
  
  Gruß
  
  Martin
  
  Antworten
  1. JM sagt:
    
    9. Januar 2021 um 19:20 Uhr
    
    Hallo Zusammen, nachdem ich mein USG mit mein Fritzbox wie Beschrieben eingestellt habe, bekomme ich mit Cloud Key kein Zugang zu Updates und kein Remote-Zugriff auf mein CloudKey, unter Geräte Fingerprint -> Symbol finden bekomme ich auch ein Fehlermeldung.
    Cloudkey befindet sich natürlich in USG Netzwerk (Statische Router 192.168.1.0 demnach USG 192.168.1.1) und Cloudkey IP 192.168.1.26
    
    kennt jemand das Problem? Gibt es eine Lösung?
    
    *Meine Beiträge verschwinden nach einiger Zeit, daher noch mal.
    
    Antworten
    1. Martin Ziegler sagt:
      
      1. Februar 2021 um 18:56 Uhr
      
      Hallo,
      deine Beträge verschwinden nicht – ich muss sie aber manuell freigeben. Dafür hatte ich in letzter Zeit nicht so viel Zeit.
      Zu deinem Problem: Wie ist dein Cloud Key konfiguriert? https:///login -> Konfiguration.
      
      Welche IP-Konfiguration hat den Cloud-Key?
      
      Wenn sich die IP geändert hat, hast du die Inform-URL entsprechend angepasst?
      
      Stimmt die DNS-Konfiguration?
      
      Ich hoffe, die Fragen helfen dir bei der Lösungssuche. Wenn nicht, gerne melden.
      
      Gruß
      Martin
      
      Antworten
Roland sagt:

11. September 2020 um 8:09 Uhr

Hallo Martin,
Vielen Dank für die Infos. Früher oder später wird mein ganzes Netzwerk hinter dem USG stehen… bis dahin muss ich noch weiter experimentieren…:-)
Viele Grüße
Roland

Antworten
Dirk sagt:

1. November 2020 um 17:49 Uhr

Hallo Martin,

danke für die ausführliche Anleitung. Was spricht dagegen, den VPN des USG zu nutzen anstelle des der Fritzbox? Das ist meiner Meinung nach sauberer, da hier die Fritzbox dann lediglich für die DSL Einwahl sowie für die Telefonie genutzt wird. Mit Hilfe der MyFritz!-Adresse kann man sich nämlich auch super in das USG einwählen.

Mein Aufbau:

https://imgur.com/dnpjjW9

Antworten
1. Martin Ziegler sagt:
  
  18. Februar 2021 um 20:48 Uhr
  
  Hallo Dirk,
  es spricht aus meiner Sicht nichts dagegen das VPN des USG zu nutzen. Ursprünglich habe ich es nicht gemacht, da die Einwahl per Fritz!Box schon aktiv war (Gewohnheit macht träge). Zukünftig würde ich es nicht machen, da ich mir eher ein WireGuard VPN einrichten würde (wenn schon hipp, dann richtig).
  
  Da dein Kommentar schon etwas älter ist: hast du schon Gründe, die dafür sprechen den VPN-Endpunkt von der Fritz!Box wegzuziehen? Wenn noch jemand vor der Frage steht, hilft ihm dass unter Umständen bei seiner Entscheidung.
  
  Gruß
  Martin
  
  Antworten
Joe sagt:

12. Dezember 2020 um 14:04 Uhr

Hallo Martin,
ich spiele mich auch grad mit dem USG und Fritzbox 6490 cable, brauche aber etwas Hilfe.
Frage zur Verkabelung: Fritzbox LAN1 (Internet Anschluss) -> USG WAN1 / USG LAN1 -> SWITCH
Richtig so?

Die Fritzbox selbst hat die IP 192.168.0.1 und dient als dhcp server für meine Geräte, die also alle auch die IPs 192.168.0.x haben. Wie muss ich jetzt den USG konfigurieren, dass das Netz 192.168.0.x für meine clients bestehen bleibt? Kann ich dem USG die interne IP 192.168.0.254 geben? Die WAN IP ist dann die “echte” IP vom ISP?
Würde dann weiters über die config das NAT am USG deaktivieren, und diesen dann auf der fritzbox als exposed host einrichten. Passt das so?
Vielen Dank!

Antworten
1. Martin Ziegler sagt:
  
  18. Februar 2021 um 20:35 Uhr
  Hallo Jochen,
  
  wenn ich dich richtig verstehe, sollen deine Client nachdem sie “hinter” dem USG hängen noch immer im 192.168.0.0/24 Netz sein.
  Dafür musst du deine Fritz!Box in ein anderes Netz umziehen.
  Zum Beispiel:
  - Fritz!Box: 192.168.178.1/24
  - USG (WAN): 192.168.178.254/24 (per DHCP von der Fritz!Box)
  - USG (LAN): 192.168.0.1/24
  - Clients am Switch am USG-LAN-Port: 192.168.0.0/24 (wenn die Clients genau die IPs per DHCP wie bei der Fritz!Box bekommen sollen, musst du dir eine Liste der IPs erstellen, bevor du die IP der Fritz!Box änderst und den Cients dann im UniFi Controller die gewünschten Adressen zuordnen)
  Die “echte” WAN IP deines ISP liegt an der Fritz!Box an. Unabhängig davon, ob du NAT am USG deaktivierst, kannst du es als “exposed host” in der Fritz!Box einrichten – es ist aber nicht das was ich im Artikel beschrieben habe und auch nicht die von mir bevorzugte Lösung. Wenn du weißt was du machst, ist es aber unterm Strich recht egal, wie du zu dem von dir gewünschten Ergebnis kommst. Sollte sich deine Lösung nicht ganz so verhalten, wie von dir gewünscht, kannst du sie immer noch anpassen.
  
  Gruß
  Martin
  Antworten
Jan sagt:

22. Dezember 2020 um 13:54 Uhr

Hallo, erst einmal vielen Dank für diesen tollen Artikel.
Ich möchte bei mir das System ähnlich wie bei Ihnen aufbauen.

Sie schrieben, dass im USG dann keine Portweiterleitungen gemacht werden müssen. Müssen diese dann in der FritzBox gemacht werden?
Kann ich die Änderung am NAT der USG wieder rückgängig machen und wenn ja wie?
Verstehe ich das richtig, dass ich für jeden Netz hinter der USG (VLAN 1,2,3) eine statische Route auf der FritzBox einrichten muss (192.168.1.0, 192.168.2.0, 192.168.3.0)?

Viele Grüße Jan

Antworten
1. Martin Ziegler sagt:
  
  1. Februar 2021 um 19:39 Uhr
  Hallo Jan,
  vielen Dank für das Lob zum Artikel. Zu den Fragen:
  Portweiterleitung: Nur deine Fritz!Box hat eine IP-Adresse, die vom Internet erreichbar ist (Im Idealfall per IPv4 und IPv6, wenn dein Provider dir keine öffentliche IPv4-Adresse zuweißt, nur IPv6). Wenn du vom Internet auf einen Dienst in deinem Netzwerk über deine öffentliche IP-Adresse zugreifen willst, muss du auf deiner Fritz!Box den entsprechenden Port weiterleiten. Entweder:
  - USG mit NAT: auf die IP des USG und dort eine 2. Weiterleitung auf die IP “hinter” dem USG”.
  - USG ohne NAT: auf die IP “hinter” dem USG und im USG den Zugriff in der Firewall freigeben.
  NAT auf dem USG wieder aktivieren: Klar, einfach die JSON-Datei löschen und neu provisionieren.
  
  Muss bei deaktiviertem NAT für jedes Subnetz eine eigene statische Route in der Fritz!Box eingerichtet werden? Jain
  - Nein: Wenn du eine Route mit der richtigen Subnetzmaske anlegst, die zu den Netzen hinter deinem USG passt, kann eine Regel mehrere/alle Netze abdecken
  - Ja: Wenn die Antwort bei “Nein” keinen Sinn ergibt 😉
  Ich habe bei mir für jedes Netz hinter dem USG eine eigene Route in der Fritz!Box definiert.
  
  Beantwortet das deine Fragen? Wenn nicht, einfach nochmal melden.
  
  Gruß
  Martin
  Antworten
Stephan sagt:

30. Dezember 2020 um 8:50 Uhr

Guten Morgen,
ich bekomme es nicht gebacken, die Json Datei auf den Unifi controller zu packen. Problem ich komme per SSH nicht auf den Controller. Diese ist auf einen Lxc Container in Proxmox installiert. Muss ich das Nat überhaupt deaktivieren? Laut PS4 habe ich Nat2. Es funktioniert soweit auch alles. Würde halt nur gerne alles in einzelne Vlans packen.
Mein System sieht im Moment so aus.
Fritzbox 7590 Lan1- Wan1 USG Lan-TP Link Switch
Fritzbox 192.168.2.1
USG 192.168.1.1
USG Wan 192.168.2.14

LG
Stephan

Antworten
1. Martin Ziegler sagt:
  
  1. Februar 2021 um 19:26 Uhr
  
  Hallo Stephan,
  wenn du aktuell keine Probleme hast und alles läuft, gibt es für dich aus meiner Sicht keinen Grund das NAT auf dem USG zu deaktivieren. Alle Netze hinter dem USG kannst du auf entsprechenden Switchen als VLANs zur Verfügung stellen – unabhängig davon ob NAT auf dem USG aktiv ist oder nicht.
  
  Gruß
  Martin
  
  Antworten
Hartmut aus Berlin sagt:

30. Dezember 2020 um 18:22 Uhr

Hallo Martin .
Komme aus Berlin bin 78 Jahre.
Wie komme ich vom PC mit filezilla auf meinen Unifi UCKP gen2 um die config.gateway.json
einzufügen habe immer eine Fehlermeldung. Authentifizierung fehlgeschlagen
Was muss ich als Benutzernamen und Passwort eingeben.
So läuft eigendlich alles wollte aber das doppelte NAt ausstelllen wegen Spiele und so.
Alle Geräte eingestellt.

Habe eine Fritzbox 7590 meine eigene Firmware 7.21
Fritzbox -Lan.1 – WAN – Unifi Gateway USG – Lan1 – Switch US-8-60W dann zum PC
Der Unifi UCKP gen2 hängt am Switch US-8-60W und habe am switch noch Unifi ACPRo für mein Wlan.

Bin Neuling
Gruss Hartmut

Antworten
1. Martin Ziegler sagt:
  
  1. Februar 2021 um 19:22 Uhr
  Hallo Hartmut,
  
  der Benutzer für den SSH-Zugriff auf den UniFi Cloud Key ist “ubnt”, das Gerätepasswort solltest du bei der Installation festgelegt haben. Wenn du es nicht mehr weißt, kannst du:
  - ein aktuelles Backup deines UniFi Controllers erzeugen,
  - deinen UniFi Cloud Key auf den Werkszustand zurück setzen,
  - den Cloud Key neu konfigurieren,
  - das Passwort für den Benutzer ubnt setzen & merken und
  - das Anfangs erstellte Backup wieder einspielen.
  Hoffe, das hilft dir weiter.
  
  Grüße nach Berlin
  Martin
  Antworten
Veit sagt:

1. Januar 2021 um 13:20 Uhr

Hallo Martin,
vielen Dank für Deinen guten Artikel. Zuerst einmal ein frohes und gesundes neues Jahr an alle!

Ich bin seit kurzem auch Besitzer einer UDM-Pro. Eigentlich wollte ich meine FB 7590 rausschmeißen, habe aber festgestellt, dass sie doch eine stabilere Internetverbindung aufbaut als das Draytek Vigor 165 Modem.

Außerdem wollte ich nicht auf die Telefonfunktion verzichten.

Da die Fritzbox 7590 aber nun mit in meinen Serverschrank im Keller gewandert ist, ist der DECT Empfang nun nicht mehr sonderlich gut.

Aus diesem Grund möchte ich die Fritz“Fon App auf unseren iOS Geräten nutzen. Leider bekomme ich aber kein Telefonat zu Stande. Weder intern, noch nach extern.

Hier mein aktueller Aufbau:
Telekom VDSL 250 FB 7590 (192.168.178.1) LAN2 UDM-Pro WAN2 (Statische IP 192.168.178.20); LAN (192.168.0.1) Switche, APs, iOS Geräte

Ich kann aus meinem LAN Netz auf die Oberfläche der Fritzbox zugreifen (über IP 192.168.178.1). In der Fritz!Fon App habe ich die IP auch hinterlegt und die App hat sich an der Box registriert. Ich kann aber wie gesagt keine Verbindung aufbauen.

Fehlen mir da noch Firewall Regeln oder Routen um die App nutzen zu können?

Für einen Tipp wäre ich sehr dankbar!

Vielen Dank und schöne Grüße,
Veit

Antworten
1. Martin Ziegler sagt:
  
  1. Februar 2021 um 19:10 Uhr
  Hallo Veit,
  es freut mich, dass dir der Artikel gefallen hat.
  Ich habe eben bei mir einen Test mit “Fritz!App Fon” durchgeführt. Mein iPhone ist ins WLAN über einen UniFi-AP eingebucht, das USG hat NAT deaktiviert und eine Fritz!Box 7490 v07.21 stellt die Verbindung zum Internet her und dient als Telefonanlage.
  - App gestartet (iPhone 6S Plus, iOS 14.3, Fritz!App Fon 4.1.8
  - App sucht und findet Fritz!Box
  - Passwort der Fritz!Box eingegeben
  - VoIP-Telefon wird automatisch eingerichtet
  - Testanrufe ohne Probleme möglich
  Leider kann ich dir nach dem Test nicht mehr sagen, als dass es direkt ohne besondere Einstellungen funktionieren sollte. Hast du eventuell zusätzliche Firewallregeln konfiguriert oder etwas besonderes bei deinen WLAN eingestellt?
  
  Gruß
  Martin
  Antworten
Matija sagt:

11. Januar 2021 um 16:38 Uhr

Hallo Martin,

Ich habe jetzt seit ein paar Wochen mit dem VPN-Problem zu kämpfen: Der Client hinter UDM-Pro kann nicht gepingt werden, wenn eine Verbindung zu Site-to-Site-VPN zwischen 2 Fritzbox-Routern besteht.

Problem: Ich kann von zu Hause aus nicht über eine VPN-Verbindung auf Clients hinter UDM zugreifen.

Mit einer VPN-Verbindung zwischen zwei FritzBoxen ist alles in Ordnung (ich kann über eine VPN-Verbindung von zu Hause aus auf die Clients hinter der FritzBox im Büro zugreifen).

Hat jemand eine Lösung für mein Problem?

Ich habe versucht, das Problem (in den Unifi-Einstellungen) mit dem Festlegen von Firewall-Regeln zu lösen, aber es hat nicht geholfen.

Es muss mir möglich sein, über die VPN-Verbindung zwischen den beiden FritzBoxen auf die Clients hinter UDM-PRO zuzugreifen.

Danke,

Matija

Antworten
1. Martin Ziegler sagt:
  
  31. Januar 2021 um 22:04 Uhr
  Hallo Matija,
  wenn ich dich richtig verstehe, funktioniert das Site-To-Site-VPN und du kannst von beiden Seiten jeweils die Rechner im Netz der anderen FritzBox pingen.
  Auf beiden Seiten (auch hinter dem USG) gibt es keine mehrfach verwendeten IP-Netze. Gehen wir mal davon aus:
  - Netz-Fritz-Büro: 192.168.0.0/24
  - Netz-Fritz-Heim: 192.168.178.0/24
  - Netz-USG: 192.168.12.0/24
  Da du nicht geschrieben hast ob NAT im USG deaktiviert ist, gehe ich davon aus, dass es aktiv ist (default). Wenn nicht, passt die folgende Antwort nicht.
  Dein USG hat im Netz-Fritz-Heim die Adresse: 192.168.178.254/24. Um Zum Beispiel auf den Webserver (Port 443) auf dem Client 192.168.12.34 zugreifen zu können, muss du im USG ein Portforwarding aktivieren (z. B.: 192.168.178.254:8433 -> 192.168.12.34:443). Danach kannst du aus dem Netz-Fritz-Büro auf 192.168.178.8443 zugreifen und landest auf 192.168.12.34:443.
  
  Wenn du NAT deaktiviert hast, solltest du auf dem USG anstelle von Portforwarding mit Firewallfreigaben arbeiten und das Routing in beiden FritzBoxen entsprechend anpassen.
  
  Ich hoffe das hilft dir weiter.
  Gruß Martin
  Antworten
Jens sagt:

14. Januar 2021 um 8:21 Uhr

Guten Tag,

ich bin über diesen interessanten Blog gestolpert, da ich mein Fritz-WLAN abschalten will (die HomePod’s spinnen).
Wie sieht es mit IPTV hinter dem USG aus?

Danke
Jens

Antworten
1. Martin Ziegler sagt:
  
  31. Januar 2021 um 21:52 Uhr
  
  Hallo Jens,
  ich vermute du meinst IPTV zum Beispiel von der Telekom mit eigenem VLAN und Multicast? In Verbindung mit einem USG habe ich das noch nicht gesehen. Die Leute mit dieser Art von IPTV haben in meinem Bekanntenkreis kein USG und die mit USG verteilen meist Satelliten-TV intern zum Beispiel über TVheadend.
  Ich würde sagen es kommt auf einen Versuch an – aber wenn du nur IGMPv3 Komponenten nutzt sollte das eigentlich funktionieren.
  Auch wenn es keine direkte Antwort auf deine Frage ist: Wenn du das Fritz-WLAN durch UniFi Accesspoints ersetzen willst, brauchst du kein USG.
  
  Gruß
  Martin
  
  Antworten
Seb sagt:

20. Januar 2021 um 22:59 Uhr

Hallo,

erst einmal vielen Dank für die tolle Anleitung! Ich habe das Ganze bei mir auch getestet. Grundsätzlich funktioniert alles, jedoch ist mir eins aufgefallen:

Bei aktiviertem Exposee Host + statischen Routen ohne das deaktivierte NAT im USG ist die Performance einwandfrei.

Deaktiviere ich das NAT im USG, (übrigens ein 4 Pro) so steigt der Ping um 80ms bis hin zum Packet-Loss, wenn man die Leitung voll ausreizt (mit mehreren Threads – Z.B. bei einem Download in der Adobe Creative Cloud). Ich habe eine 300/150 FTTH Leitung, bei der eine Auslastung der bereitgestellten Geschwindigkeit normalerweise keinerlei Einfluss auf den Ping hat, da das Medium in Gänze (1Gbit/s Glasfaser) ja nicht ausgelastet ist.

Aktiviere ich das NAT im USG wieder, ist das Phänomen wieder weg. Smart Queue etc im USG hat keinerlei Auswirkung. Hardware Offloading ist aktiv.

Hat jemand eine Idee?

Grüße
Seb

Antworten
1. Martin Ziegler sagt:
  
  31. Januar 2021 um 21:46 Uhr
  
  Hallo Seb,
  bei uns im Dorf sind wir noch mit VDSL2 unterwegs. Ich habe die Geschwindigkeitsmessung in meinem Controller aktiv und bekomme eine Latenz von 7ms angezeigt. NAT auf dem USG ist bei mir deaktiviert.
  Eventuell hat jemand anderes ein vergleichbares Verhalten?
  Gruß
  Martin
  
  Antworten
Simond sagt:

24. Januar 2021 um 16:28 Uhr

Hallo Martin,
danke für deinen Artikel. Habe meine UDM-Pro heute den ersten Tag und habe folgendes gefunden: https://community.ui.com/questions/disable-NAT-in-UDM-pro/f5a97c47-e6bf-4ebf-a899-0c4271e8e6a2
Denke diese Methode ist die bessere Wahl, wollte aber dennoch vorher kurz deine Meinung hören.
Viele Grüße
Simon

Antworten
1. Martin Ziegler sagt:
  
  31. Januar 2021 um 21:39 Uhr
  
  Hallo Simon,
  ich hatte leider noch keine UDM-Pro in den Händen. Da config.gateway.json von der UDM nicht unterstützt wird, ist die in dem verlinkten Beitrag beschriebene Lösung aber sicher einen Versuch wert. Wenn es bei dir klappt, würde ich mich über eine Rückmeldung freuen.
  Gruß
  Martin
  
  Antworten
  1. Simond sagt:
    
    3. Februar 2021 um 16:53 Uhr
    
    War doch leichter einzurichten als gedacht und funktioniert super 🙂
    
    Antworten
    1. Martin Ziegler sagt:
      
      3. Februar 2021 um 18:10 Uhr
      
      Freut mich,
      danke für die Rückmeldung. Eventuell ermutigt es andere, sich die UniFi Dream Machine Pro mal anzuschauen.
      Gruß
      Martin
      
      Antworten
Jörg Ludwig sagt:

6. Februar 2021 um 16:54 Uhr

Hallo Herr Ziegler,
wir wollten eine VPN Verbindung von einem entfernten Windows Rechner mit unserem USG Radius Server daheim herstellen.
An dieser Stelle sind wir auf ihren klasse Beitrag gestoßen, in dem sie auf das doppelte NAT aufmerksam machen.
Ich habe mit FileZilla ihre config.gateway.json übertragen, die Berechtigungen auf 770 gesetzt und
mit putty dann noch den Besitzer unifi:unifi eingetragen.
Mit der Antwort auf “iptables” komme ich nicht klar.
In den Kommentaren zu ihrem Blog steht etwas vollkommen anderes.
Wissen sie einen Rat ?

viele Grüße
Jörg Ludwig

login as: ubnt
ubnt@192.168.1.8’s password:

___ ___ .__________.__
| | |____ |__\_ ____/__|
| | / \| || __) | | (c) 2013-2019
| | | | \ || \ | | Ubiquiti Networks, Inc.
|______|___| /__||__/ |__|
|_/ http://www.ubnt.com

Welcome to UniFi CloudKey!

Last login: Fri Feb 5 09:42:45 2021 from 192.168.1.21
root@UniFi-CloudKey:~# sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 67669 packets, 6371K bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 64395 packets, 6064K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 8213 packets, 1811K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 8213 packets, 1811K bytes)
pkts bytes target prot opt in out source destination
root@UniFi-CloudKey:~#

Antworten
1. Martin Ziegler sagt:
  
  6. Februar 2021 um 20:29 Uhr
  
  Hallo Herr Ludwig,
  
  der iptabels Befehl zum Testen muss auf dem USG abgesetzt werden (hier findet das NAT statt), nicht auf dem Cloud Key.
  “config.gateway.json zum Controller laden” -> “USG über den Controller provisionieren” -> “mit iptables auf dem USG testen”.
  
  Hilft Ihnen das weiter?
  
  Gruß
  Martin Ziegler
  
  Antworten
  1. Jörg Ludwig sagt:
    
    7. Februar 2021 um 11:14 Uhr
    
    Hallo Herr Ziegler ,
    danke für die rasche Hilfe. Leuchtet ein, hatte ich so nicht auf dem Schirm.
    Habe iptables auf dem USG ausgeführt, sieht jetzt besser aus …
    
    105K 11M RETURN all — * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5999 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set corporate_network src /* NAT-6001 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set remote_user_vpn_network src /* NAT-6002 */
    0 0 MASQUERADE all — * eth0 0.0.0.0/0 0.0.0.0/0 match-set guest_network src /* NAT-6003 */
    
    viele Grüße
    
    Antworten
Sebastian sagt:

21. Februar 2021 um 13:25 Uhr

Hi, ich Plane auch gerade einen USG einzusetzen.

Meine aktuelle Config, Fritzbox 7590 -> US-8-60w ->UAP-AC-Pro
->UAP-AC-IW

Jetzt soll zwischen Fritzbox und US-8 ein USG 3P, wie es auch im Blog beschrieben wurde.
Nun hängen aber diverse Smart home Geräte im Netzwerk die ich gerne am einfachsten wieder mit der selben IP laufen lassen möchte. Sobald ich den USG erfolgreich eingerichtet habe vergibt er sicherlich neue IP Adressen?
In der Fritzbox habe ich den Smarthome Geräten eine feste ip angewiesen (also die geräte sollen immer diese selbe Adresse behalten).
Kann ich im USG, sobald ich im USG das NAT deaktiviert habe und an der Fritzbox angeschlossen ist, einfach den Geräten eine statische (die alte Fritzbox ip) ip zuweisen so das sie sich alle wieder finden? Oder kommt es da mit der vorgeschaltete Fritzbox zu Komplikationen?

Achso und noch eine Frage.
Wo liegt der maximale mbit Durchsatz bei dem USG 3p?
Ich habe zurzeit eine Telekom 100/40 Leitung.
Lese das der USG nur 85mbit schaffen kann im ISP DPI mode? Aber andere tests zeigen was von 250mbit.

Gruß
Sebastian

Antworten
1. Martin Ziegler sagt:
  
  4. April 2021 um 14:17 Uhr
  Hallo Sebastian,
  
  wenn deine Geräte bisher ihre IP-Adressen per DHCP bekommen haben und du die IPs in der FritzBox “fixiert” hast, empfehle ich dir folgendes Vorgehen, wenn alle Geräte danach wieder die gleichen IPs haben sollen:
  - Dokumentation aller Geräte & IPs erstellen.
  - Alle Geräte von der FritzBox trennen.
  - FritzBox in anderes Subnet umziehen.
  - USG anschließen.
  - Ein Gerät zum Konfigurieren “hinter” dem USG anschließen (wenn du den UniFi Controller nicht auf dem Laptop hast, auch das Gerät mit dem UniFi Controller anschließen).
  - USG LAN-Subnetz auf das “alte” Subnet deiner FritzBox einstellen.
  - Dafür sorgen, dass der UniFi Controller die gleiche IP wie bisher hat.
  - (Optional) NAT deaktivieren.
  - ein Gerät nach dem anderen ins LAN “hinter” dem USG nehmen und über den UniFi Controller die IP auf den gewünschten Wert festlegen.
  Die vorgeschaltete FritzBox bekommt von den DHCP-Anfragen aus den Netzen “hinter” dem USG nichts mit. Wichtig ist fürs Routing, dass das IP-Netz der FritzBox nicht identisch mit einem der Netzte hinter dem USG ist.
  
  Wegen der Auslastung des USG: ich habe mit aktivem IPS auch schon bei einer 60 MBit-Leitung mein USG zu 100% Auslastung bekommen – mit negativer Auswirkung auf den Datendurchsatz. Das war zu einem Zeitpunkt zu dem 5 PCs mit Windows-Updates beschäftigt waren. Leider kenne ich keine repräsentativen Messungen, bei denen die Auswirkung der verschiedenen IPS Optionen und die “Art” des Traffics auf die Auslastung des USG und des Datendurchsatz aufgeschlüsselt sind. Persönlich würde ich mir für eine 100 MBit-Leitung ein größeres Modell zulegen, wenn IPS für mich wichtig wäre.
  
  Ich hoffe, die Antwort hilft dir – wenn du Fragen zu den einzelnen Schritten hast, gerne nachfragen.
  Gruß
  Martin
  Antworten
Martin sagt:

22. März 2021 um 11:02 Uhr

Hallo Herr Ziegler,

zuerst möchte ich mich bedanken für die super Anleitung! Ich habe Wochen nach sowas gesucht.

Ich habe alles so eingerichtet wie Sie es beschrieben haben. Mein Netz bei der Fritzbox ist 192.168.0.0 Das Netz nach dem USQ ist ein 10.0.0.0.
Nun habe ich an der Fritzbox noch eine WebCam an 192.168.0.8 Dafür habe ich eine Firewall Regel im USG angelegt wie Sie es auch bei VPN gemacht haben. Das funktioniert auch super!

So nun zu meinem Problem: An der Fritzbox habe ich auch VPN, genau so wie Sie es nutzen. Hier habe ich auch ein Regel im USG angelegt, genau so wie ich es mit der WebCam gemacht habe. Nur leider komme ich mit VPN nicht in mein 10.0.0.0 Netz !? Die Ip die ich bekomme ist immer Fix 192.168.0.241. Interessant ist auch dass wenn ich einen Ping aus dem 10-er Netz an die VPN Adresse mache, eine Meldung bekomme Zielhost nicht erreichbar obwohl ich mit VPN verbunden bin. Wenn ich einen Ping auf die Fritzbox oder auf die Webcam mache funktionierts. Irgentwas sperrt mir das VPN Nur was?

Antworten
1. Martin Ziegler sagt:
  
  28. März 2021 um 19:51 Uhr
  
  Hallo Herr Bachmayr,
  es freut mich, dass Ihnen die Anleitung weitergeholfen hat. Vielen Dank für das Feedback.
  
  Haben Sie NAT auf dem USG aktiv oder deaktiviert? Mit der Information wird die Antwort etwas übersichtlicher, da ein paar Optionen entfallen.
  
  Die Webcam (192.168.0.8) und Ihr VPN-Client (192.168.0.241; die Fritz!Box vergibt für jeden VPN Benutzer fest die IP-Adresse hinter der definierten DHCP-Range) sind im gleichen Subnetz und sollten sich bei identischer Firewallkonfiguration auch identisch verhalten. Wie haben Sie getestet? Es könnte Unterschiede geben:
  Wenn Sie aus dem 10.0.0.0/24 Netz auf die Webcam zugreifen, benötigen sie dafür keine eigene Firewallregel. Wenn Sie ein NAS haben, das auf die WebCam zugreift, um Videos zu speichern, geht die Kommunikation vom “sichereren” Netz hinter dem USG ins “unsichere” Netz zwischen Fritz!Box und USG. Das klappt in der Standardeinstellung auch ohne Firewallanpassungen. Wenn Sie hingegen aus dem 192.168.0.0/24 mit dem VPN-Client ins Netz hinter dem USG zugreifen wollen, brauchen Sie hierfür (wenn doppeltes NAT im USG deaktiviert ist) eine Firewallregel oder (wenn doppeltes NAT noch aktiv ist) Portforwarding (und würden die IP des USG im 192.168.0.0/24 Netz ansprechen). Das der Ping nicht funktioniert, kann mehrere Ursachen haben: Zum Beispiel eine fehlende Route auf der Fritz!Box (wenn auf dem USG doppeltes NAT deaktiviert ist) oder eine fehlende Firewallfreischaltung (ping nutz ICMP als Protokoll).
  
  Ich hoffe, die Antwort hilft Ihnen bei der Analyse. Wenn ich etwas unverständlich formuliert habe, einfach nachfragen.
  
  Gruß
  Martin Ziegler
  
  Antworten
Niels sagt:

6. April 2021 um 2:39 Uhr

Vielen herzlichen Dank für die tolle Anleitung Martin! Anhand deiner Beschreibung war mein frisch erstandenes USG im Handumdrehen hinter der Fritzbox im Einsatz. Es funktioniert eigentlich alles wie beschrieben und erwartet, nur mein Pihole funktioniert seit dem “Umzug” hinter das USG nicht mehr.

Per SSH auf dem Pihole sehe ich, dass eigentlich keine IP Verbindungen ins Internet funktionieren ( z.B. kein ping 8.8.8.8 und traceroute -n 8.8.8.8 nur bis zum USG kommt) und somit natürlich auch die DNS Anfragen nicht vom Pihole beantwortet werden. Andere Clients im LAN hinter dem USG haben keine Probleme. Die IP Routes auf dem Pihole sind identisch mit einem anderen Raspberry, der keine Probleme bereitet.

Setze ich Pihole (mit geänderter IP und Router IP) direkt an die Fritzbox, funktioniert ping, traceroute und die Namensauflösung wieder. In diesem Netz und mit dieser IP kann ich es aber nicht als DNS Server für das Netz hinter dem USG nutzen.

Ich nutze bisher keine VLANs und habe auch keine Änderungen an Routes, Firewall Rules und Port Forwarding im USG vorgenommen – alles noch Standard. (In der Fritzbox habe ich natürlich die Route konfiguriert.) Im WAN Netz nutze ich aktuell die Fritzbox als DNS. Im LAN Netz wird per Automatik Einstellung die IP der USG als DNS ausgeliefert. So funktonieren DNS Anfragen, jedoch halt ohne Pihole als Filter.

Wo liegt der Fehler in meiner Konfiguration, um Pihole wieder für die DNS Auflösung nutzen zu können? Nach zig Stunden sind mir die Ideen ausgegangen und jede Anregung ist willkommen. Vielen Dank im Voraus!

Antworten
1. Martin Ziegler sagt:
  
  14. November 2021 um 11:22 Uhr
  Hallo Niels,
  entschuldige die sehr späte Antwort – es kommen mit der Zeit doch mehr Anfragen per Kommentar oder E-Mail, als meine Freizeit Raum bietet. Ich hoffe, du konntest dein Problem inzwischen lösen.
  
  Wenn ich deine Problemstellung richtig verstehe:
  - Du nutzt die FritzBox als Internet Gateway, das USG hängt “dahinter”, NAT auf dem USG ist deaktiviert.
  - Alle Clients “hinter” dem USG bekommen IPs vom USG, Internetzugriff funktioniert problemlos.
  - Nur dein Pi-hole, das du als DNS-Server nutzen möchtest, kommt nicht mehr ins Internet, sobald es “hinter” dem USG hängt.
  - Im IP-Subnetz der FritzBox kommt dein Pi-hole zwar ins Internet aber du kannst es nciht als DNS Server nutzen.
  Im Prinzip sollte alles was du gemacht hast, generell funktionieren – daher vermute ich, dass nur eine Kleinigkeit nicht passt.
  Wenn das Problem noch besteht, kannst du bitte beschreiben:
  - welche IP-Subnetze du mit der FritzBox und dem USG verwendest,
  - welche IP-Adressen die jeweiligen Geräte in den verschiedenen Testszenarien haben und
  - wie die Routing-Regeln in FritzBox, USG und den Clients konfiguriert sind?
  Gruß
  Martin
  Antworten
  1. Niels sagt:
    
    14. November 2021 um 16:26 Uhr
    
    Danke Martín,
    
    inzwischen habe ich ein DSL Modem vor dem Unifi Gateway und die Fritzbox dahinter als IP Client. Ist zwar ein extra Gerät, aber jetzt ist alles sauber getrennt und die Fritzbox in einem VLAN.
    
    Schönen Sonntag!
    
    Antworten
Roland sagt:

18. September 2021 um 17:07 Uhr

Hallo,

ich habe eine FritzBox 7530 (192.168.178.1) bei Vodafone. Dahinter ist die USG (192.168.178.20 WAN und USG LAN 192.168.1.1) und der Controller ist auf der Synology via Docker (192.168.100.3 VLan).
Leider finde ich keinen Ordner, wo ich die Datei hineinschieben könnte.
Muss ich mich auf den Controller (also auf der Synology) anmelden per SSH oder auf der USG selber?

Gruß
Roland

Antworten
1. Martin Ziegler sagt:
  
  16. Oktober 2021 um 14:02 Uhr
  
  Hallo Roland,
  
  die JSON Datei muss auf den Controller (auf das USG bekommst du die Einstellungen dann durchs provisionieren). Im Idealfall hast du das entsprechende Verzeichnis im Dockercontainer so eingebunden, dass es “außerhalb” liegt und ein Update übersteht. Wie das im Detail geht, hängt aber stark von dem von dir verwendeten Container und deiner Umgebung ab.
  
  Gruß
  Martin
  
  Antworten
  1. Roland sagt:
    
    16. Oktober 2021 um 14:46 Uhr
    
    Ich habe nun wieder auf den Cloud Key gewechselt. Da ging es dann ohne Probleme. Ich hatte noch dran zu knacken, dass ich auf die anderen VLans zugreifen konnte trotz richtiger Firewall Einstellungen. Es lag daran, dass ich nur eine Statische Route eingerichtet habe, aber ich in der Fritzbox ja für alle VLans eine Statische Route brauche. 😉 Nun läuft alles bestens. Danke für die super Anleitung. 🙂
    
    Antworten
Ingo Straub sagt:

13. Oktober 2021 um 18:53 Uhr

Hallo Zusammen,
vielen Dank für die tolle Erklärung. Ich finde jedoch keine Lösung, dass mein USG Internet bekommt und dies dann auch in das interne Netz weitergibt. Die JASON Datei habe ich eingelesen. Folgenden Aufbau habe ich:

FB 6490 Cable lgi 192.168.0.1 DHCP WLAN aus -> 192.168.0.2 Exposed Host + Route an 192.168.1.0 WAN -> 192.168.1.1 LAN1 -> SWITCH 192.168.1.2 -> APs

In der Firewall USG sind nur die Standard drin, die nicht geändert werden können.
In der Route USG steht USG -> AVM 192.168.0.0/24 Schnittstelle WAN

Traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 usg-3p (192.168.1.1) 2.093 ms 1.626 ms 2.367 ms
2 usg-3p (192.168.1.1) 727.592 ms !H * 994.934 ms !H

Das USG hat zwar eine IP von der Fritzbox, jedoch kein Internet 🙁

Was kann ich noch tun?

Antworten
1. Martin Ziegler sagt:
  
  16. Oktober 2021 um 14:00 Uhr
  
  Hallo Ingo,
  hatte die verbindung von geräten “hinter” deinem USG im Auslieferungszustand funktioniert? Also ohne JSON Datei, Exposed Host oder Routing-Einstellung ind er Fritz!Box? Das führt zwar dazu, dass nochmal NAT durchgeführt wird, Internetzugriff sollte aber so für alle Geräte möglich sein.
  
  Den “Exposd Host” brauchst du nicht, wenn du dich an der Anleitung im Artikel orientierst. Es gibt andere Möglichkeiten (teilweise in den Kommentaren beschrieben, die einen Exposed Host nutzen). Bei der Route in der Fritz!Box ist wichtig, dass du als Gateway die IP Adresse der USG angibst, die diese im Netz der Fritz!Box bekommt (Netzwerk: 192.168.1.0; Subnetzmaske 255.255.255.0; Gateway: 192.168.0.2 <= wenn ich deinen Kommentar richtig interpretiere). DHCP musst du bei der Fritz!Box nicht deaktivieren. An den Routing Einstellungen im USG musst du nichts manuell anpassen.
  
  Ich hoffe, das hilft dir etwas weiter.
  
  Gruß
  Martin
  
  Antworten
  1. Ingo Straub sagt:
    
    17. Oktober 2021 um 8:13 Uhr
    
    Hallo Martin.
    Vielen Dank für Deine Hilfe. Ich habe nun herausgefunden, dass sich der WAN1 trotz DHCP in der FB keine IP zieht. Ich habe probehalber den WAN2 am USG aktiviert und das LAN von der FB umgesteckt…
    
    Tada… nun habe ich mit den identischen Einstellungen auf einmal Internet… Denke der WAN1 hat einen Defekt. Habe einen RMA erstellt bei UI.
    
    Viele Grüße Ingo
    
    Antworten
Chris sagt:

29. November 2021 um 16:45 Uhr

Hi zusammen,

auch von mir erstmal ein sehr großes Danke für die Anleitung, hat bisher ganz gut seinen Dienst getan.
Und jetzt kommt das Aber:
Seit unserem Umzug sind wir gezwungenermaßen bei der Telekom. Mit dem Aufbau GF-Modem -> FritzBox-> USG -> UniFi Switch -> FritzBox 2 (Telefonie) etc haben wir nun zwei Probleme, die sofort verschwinden, sobald ich das USG aus der Kette entferne und die FritzBox als DHCP-Server nutze:
1. Telefonate brechen nach 8-20 Minuten ab (egal ob ein- oder ausgehend)
2. Mediatheken lassen sich kaum nutzen, ganz besonders vom ZDF. Nach wenigen Minuten ist das Bild schwarz und der Ton beginnt von vorne oder das Bild bleibt hängen und der Ton läuft weiter.
Und wie beschrieben sind die Probleme in dem Moment behoben,

Ich bin langsam echt ratlos. Ohne FritzBox geht es jetzt erstmal, allerdings muss ich so auf mein Gastnetz verzichten.
Hat zufällig jemand schon so eine Erfahrung gemacht und könnte einschätzen, an welchen Einstellungen das liegen könnte?

Danke und viele Grüße
Chris

Antworten
1. Martin Ziegler sagt:
  
  5. Dezember 2021 um 10:18 Uhr
  Hallo Chris,
  freut mich, dass dir die Anleitung geholfen hat. Leider hast du mich beim Workaround abgehängt. Am Anfang schreibst du, dass die das USG aus der Kette entfernst, am Ende, dass es ohne FritzBox geht. Wie sieh dein aktueller Workaround aus? Wenn du die Möglichkeit hast:
  - GF-Modem -> USG -> UniFi Switch -> Unifi APs FritzBox 2 fürs Telefon + “Resliche IP-Geräte” in dieser “Reihenfolge der Verkabelung” zu nutzen und
  - du im USG ein Gastnetz definierst & dieses über die UniFi Accesspoints verteilst
  sollte – zumindest in der Theorie – alles laufen.
  
  Wenn du im USG die Network Address Transpaltion (NAT), wie im Artikel beschrieben, deaktiviert hast, solltest du die Änderungen ohne FritzBox zwischen GF-Anschluss und USG wieder rückgängig machen.
  
  Hilft dir das weiter?
  
  Gruß
  Martin
  Antworten
  1. Chris sagt:
    
    5. Dezember 2021 um 10:50 Uhr
    
    Hi Martin,
    danke für die Antwort. Du hast völlig Recht, da habe ich am Ende FritzBox und USG vertauscht. UAPs sind zusätzlich hinter dem Switch vorhanden.
    Meine bisherigen Konfigurationen waren/sind:
    
    V1:
    GF-Modem -> FritzBox-> USG (NAT aus, DHCP-Server ein, Gast-LAN ein) -> UniFi Switch -> FritzBox 2 (Telefonie)
    -> beschriebene Abbrüche bei Telefonie und einigen Mediatheken
    V2:
    GF-Modem -> USG (NAT ein, DHCP-Server ein, Gast-LAN ein) -> UniFi Switch -> FritzBox 2 (Telefonie)
    -> beschriebene Abbrüche bei Telefonie und einigen Mediatheken
    V3 (aktuell genutzt):
    GF-Modem -> FritzBox (DHCP-Server ein, Gast-LAN ein über Port 4)-> UniFi Switch -> FritzBox 2 (Telefonie)
    -> alles bestens
    Inzwischen habe ich es auch mit dem Gastnetz der FritzBox hinbekommen und kann über die UAP AC Pros auch mein Gäste-WLAN und für meinen dienstlichen Rechner das Gäste-LAN nutzen.
    
    Somit sind meine zuvor beschriebenen Einschränkungen erstmal beiseite geräumt. Allerdings frage ich mich tatsächlich, wo der Fehler im USG ist, bzw. besser in meiner Konfiguration des USG.
    
    Viele Grüße
    
    Chris
    
    Antworten
    1. Martin Ziegler sagt:
      
      5. Dezember 2021 um 21:19 Uhr
      
      Hallo Chris,
      aus der Ferne ist es schwer zu sagen. Generell sollte deine Variante 2 funktionieren. Zur Analyse kannst du versuchen, in den Log-Dateien des USG etwas zu finden, was zeitlich zu deinen Problemen passt. Hattest du zum Beispiel mit IGMP, Firewallregeln oder IPv6 mal etwas ausprobiert? Vieleicht auch schon vor längerer Zeit & die Konfiguration ist nicht 100% standard?
      
      Gruß
      Martin
      
      Antworten
Sascha sagt:

5. Dezember 2021 um 22:22 Uhr

Hallo zusammen,

bin vor kurzem mit meinem Wlan bei einem Unifi AP gelandet. Muss schon sagen, der funktioniert echt gut. Besser als das WLAN der FB. Natürlich hat mich das ganze neugierig gemacht.
Da ich in ein paar Wochen von einem DSL auf einen Glasfaseranschluß wechsel, habe ich mir überlegt, eine USG in Verbindung mit meiner FB 7590 (DHCP|Telefonie) zu wechseln.
Die Konfiguration wüde ich nach der Anleitung versuchen, das sollte kein Probelm sein. Momentan weiß ich noch nicht welchen Glasfaseranschlußart mein neuer Anbieter mir zur Verfügung stellt. Das muss ich noch in Erfahrung bringen.
Sollte es ein FTTH sein, kann ich doch die POE Einwahl über die USG konfigurieren oder nicht? Wenn ich die FB nutzen möchte, macht das dann Sinn die POE Einwahl übder die USG zu konfigurieren?
Bin mir nicht sicher.
Den Rest der Konfiguration kann ich dann aus der Anleitung übernehmen?
Vielen Dank im Voraus.

Viele Grüße
Sascha

Antworten
1. Martin Ziegler sagt:
  
  18. Dezember 2021 um 18:07 Uhr
  
  Hallo Sven,
  
  wenn du dein USG direkt am Glasfaseranschluss betreibst, kannst du dir die ganze Anleitung sparen – sie ist nur eine Möglichkeit das doppeltes-NAT-Problem zu lösen. Das hast du bei direkter Anbindung gar nicht erst.
  
  Ich hoffe ich habe dein Szenario richtig verstanden, sonst einfach nachfragen.
  Gruß
  Martin
  
  Antworten
Reinhard Ballay sagt:

21. Dezember 2021 um 19:48 Uhr

Hallo Martin,

kann man aus dem Subnetz der USG auf die Fritzbox zugreifen um diese zu konfigurieren bzw. die Verbindungsdaten zu sehen?

Viele Grüße
Reinhard

Antworten
1. Martin Ziegler sagt:
  
  27. Dezember 2021 um 15:52 Uhr
  
  Hallo Reinhard,
  ja, aus den Subnetzen des USG kommst du auf alle Geräte im Subnetz der Fritzbox und auch auf die Fritzbox selbst.
  Gruß
  Martin
  
  Antworten