Was wollen wir?
Ein vor dem USG betriebenes Modem aus dem UniFi-LAN erreichen
Warum wollen wir das?
Es gibt nicht mehr genug Ports auf den Switches und ihr wollt dennoch Zugriff auf das Modem am WAN-Anschluss des USGs haben?
Dann lest weiter.
Und wie geht das genau?
Immer wieder stehen auch andere User vor dem Problem, dass die HIER beschriebene Lösung, welche allerdings auch Vorlage zu meinen Versuchen war, nicht zum gewünschten Ziel führt.
Daher habe ich mich nun auch dazu entschlossen einen aktiven Beitrag zu unserem Wiki beizusteuern.
Ich suche auch jedes Mal wieder meinen Beitrag - hier wird es nun sehr einfach ihn wiederzufinden. 
Mein Setup sieht folgendermaßen aus:
- DrayTek Vigor 165 im Modem-Betrieb (Standard bei Auslieferung), Firmware: 4.2.3_STD
- USG-Pro-4 mit PPPoE-Einwahl
- USG mit PPPoE-Einwahl
Ich habe mich zur folgenden Konfiguration entschieden, um nicht mit Standard-AVM-IP-Adressen bei einem möglichen VPN-Szenario in Konflikt zu geraten. Ihr könnt euch selbstverständlich jede zulässige private IPv4-Adresse nach der RFC 1918 heraussuchen. Es darf allerdings keine Überschneidung zu einer LAN- oder einer möglichen via VPN erreichbaren IP-Adresse geben, denn dann könnte entweder das Modem oder das andere Netz nicht zu erreichen sein.
Let's go for...
Konfiguration des Modems
Nachdem das Gerät ja nun als Modem konfiguriert ist, kommen wir dennoch mit der unter LAN >> General Setup konfigurierten IP-Adresse auf die GUI - noch direkt an einen Rechner angeschlossen:
Wenn diese Einstellungen übernommen werden, wird das Modem neustarten. Nun kann man es wieder ans USG (WAN-seitig
) anschließen, denn der Rest muss in der UniFi-Welt passieren. Auch die Verbindung zum Internet kann man schon wieder herstellen.
Konfiguration des Gateways
Nachdem nun das Modem konfiguriert ist muss ein sogenanntes virtuelles Interface (pseudo-ethernet) auf dem USG angelegt werden. Dieser Schnittstelle muss nun meinem Beispiel folgend die Adresse 192.168.178.2/30 zugewiesen werden, damit Modem und USG miteinander kommunizieren können. Bitte beachtet die nun unterschiedlichen Konfigurationen
USG-Pro-4:
{
"interfaces": {
"pseudo-ethernet": {
"peth2": {
"address": ["192.168.178.2/30"],
"description": "Zugriff auf Vigor 165",
"link": ["eth2"]
}
}
},
"service": {
"nat": {
"rule": {
"5000": {
"destination": {
"address": ["192.168.178.1"]
},
"outbound-interface": ["peth2"],
"type": "masquerade"
}
}
}
}
}USG:
{
"interfaces": {
"pseudo-ethernet": {
"peth0": {
"address": ["192.168.178.2/30"],
"description": "Zugriff auf Vigor 165",
"link": ["eth0"]
}
}
},
"service": {
"nat": {
"rule": {
"5000": {
"destination": {
"address": ["192.168.178.1"]
},
"outbound-interface": ["peth0"],
"type": "masquerade"
}
}
}
}
}Dem aufmerksamen Leser werden die Unterschiede in den Zeilen 4, 7 & 18 aufgefallen sein. Diese gibt es, da sich hier die beiden USG-Modelle unterscheiden. (Irgendwie muss der Preisunterschied ja auch argumentiert werden können 
)
Die Formatierung sollte unbedingt VOR dem Upload ins USG (Provisioning) geprüft werden, zum Beispiel hier: JSON Formatter & Validator.
Wenn alles OK ist, dann kann das Config-File an der entsprechenden Stelle im Controller abgespeichert und das USG darauf folgend provisioniert werden.
Ab sofort kann nun die Web-GUI des Modems unter 192.168.178.1 aufgerufen, auch per https. 
Damit ist es nun ohne Probleme möglich, von jedem LAN-Client aus auf die Modem-GUI unter der IP-Adresse 192.168.178.1 durch das USG zuzugreifen.
Kein Routing, Masquerading heißt das Zauberwort.
Prüfung
Die beiden o.g. IP-Adressen sollten im Standard von allen Clients im LAN zu erreichen sein und auch auf ein ping antworten.
C:\Users\razor>ping 192.168.178.1
Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:
Antwort von 192.168.178.1: Bytes=32 Zeit=24ms TTL=254
Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=254
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=254
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=254
Ping-Statistik für 192.168.178.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 24ms, Mittelwert = 6ms
C:\Users\razor>ping 192.168.178.2
Ping wird ausgeführt für 192.168.178.2 mit 32 Bytes Daten:
Antwort von 192.168.178.2: Bytes=32 Zeit=30ms TTL=64
Antwort von 192.168.178.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.178.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.178.2: Bytes=32 Zeit<1ms TTL=64
Ping-Statistik für 192.168.178.2:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 30ms, Mittelwert = 7msUm die aktuelle USG-Konfiguration anzuzeigen ist auf der Console der u.g. Befehl auszuführen.
Das Ergebnis:
root@USG:~# ip -f inet addr show peth2
25: peth2@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.178.2/30 brd 192.168.178.3 scope global peth2
valid_lft forever preferred_lft foreverroot@USG:~# ip -f inet addr show peth0
25: peth0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.178.2/30 brd 192.168.178.3 scope global peth2
valid_lft forever preferred_lft foreverNetter Nebeneffekt: im Menü unter System Maintenance >> Time and Date kann man nun auch das USG als Zeit-Server konfigurieren und hat so auch die korrekte Zeit für seine Logs:
Anmerkung: Bei einer UDM* könnte der Link weiterhelfen: UDM-PRO-SE | DSL-Modem erreichen.
Disclaimer:
Alle Anleitungen/Tutorials sind nach bestem Wissen und Gewissen verfasst, gehen immer von den definierten Software/Firmware-Versionen aus und sind auf das englische GUI ausgelegt.
Es gibt keine Garantie auf Erfolg. Im Falle eines Misserfolges hilft aber die Community hier sicherlich weiter.
Keiner der Autoren oder der Betreiber des Forums ist für die aus der Nutzung resultierenden Probleme/Herausforderungen verantwortlich.
Jegliche hier beschriebenen Schritte erfolgen ausnahmslos in eigener Verantwortung des Durchführenden.
Eltern haften für ihre Kinder.