Speedport Smart im DSL Modem Modus + Unifi Security Gateway Pro

Gelöst

Hallo, 

 

Der Speedport Smart hat einen DSL-Modem Modus. Wenn dieser aktiviert ist übernimmt das Unifi USG die Einwahl und stellt die Internetverbindung her. 

Im Modem Modus können dem Speedport noch DSL Informationen entlockt werden, wenn man ein Gerät an LAN 1-3 anschließt. Hier hört der Speedport nur auf die IP 169.254.2.1. 

Ich möchte natürlich jetzt gerne LAN1 ebenfalls an das USG anschließen damit ich die Infoseite aus meinem Netzwerk aufrufen kann.

 

Hat zufällig jemand diese Kombination getestet? Funktioniert das bzw. kann mir jemand sagen wie er das USG überredet hat mit dem Speedport zu reden?

 

Danke und viele Grüße

 

Dominik

1 AKZEPTIERTE LÖSUNG
Lösung

Hallo,

 

auch wenn die Frage schon etwas älter ist...

Ich stand jetzt vor selbigem Problem, mit ein wenig Herumprobieren war es gar nicht so schwer:

 

Das USG hat ja ein zweites LAN/WAN-Interface. Dieses verbindet man mit einem der noch freien LAN-Ports des Speedports. Dann richtet man im Unifi-Controller einfach ein weiteres Netzwerk ein mit der Adresse 169.254.2.2/16 (169.254.2.2/30 würde auch gehen, damit lässt man sich den restlichen APIPA-Bereich frei, falls man ihn für was-auch-immer brauchen sollte) und weist diese dem LAN2-Port zu.

Nach erfolgter Provisionierung müsste das USG den Speedport unter 169.254.2.1 schon anpingen können.

Damit das auch von den Systemen aus dem LAN funktioniert, muss nun nur noch dafür gesorgt werden, daß die entsprechenden Datenpakete maskiert (also mit der Adresse des LAN-Interfaces des USG ausgetattet) werden.

Die Kommandos dafür über ssh/console auf dem USG sind:

configure
set service nat rule 5000 destination address 169.254.2.1
set service nat rule 5000 outbound-interface eth2
set service nat rule 5000 type masquerade
commit;exit

Nach nem Neustart/Provisionierung ist das natürlich weg, also muss man das noch in eine config.gateway.json giessen:

{
"service": {
"nat": {
"rule": {
"5000": {
"destination": {
"address": ["169.254.2.1"]
},
"outbound-interface": ["eth2"],
"type": "masquerade"
}
}
}
}
}

Damit sollte das dann funktionieren.

 

Allerdings... ist da noch Windows. Seit Vista hat Windows das "Feature", bei Existenz von mehr als einem Netzwerkinterface genau den vom Speedport als Modem verwendeten APIPA-IP-Bereich nicht korrekt zu routen. Hat ne ganze Weile gedauert, bis ich dahinter kam, deutlich länger als den Kram oben zu erstellen. Und ich wunderte mich, wieso es einfach nicht klappen will... Wütend

Das Problem umgeht man durch die Einrichtung einer statischen Route auf dem eigenen Windows-Rechner:

route add 169.254.0.0 mask 255.255.0.0 <IP des USG> -p

Und dann sollte es endlich klappen.

 

Wie man trotz des Modem-Modus an erweiterte Infos kommt, kann man hier nachlesen (ist für den Entry 2, sollte aber bei SP Smart auch klappen):

https://www.onlinekosten.de/forum/showthread.php?p=2432917#post2432917

Lösung in ursprünglichem Beitrag anzeigen  

Lösung

Hallo,

 

auch wenn die Frage schon etwas älter ist...

Ich stand jetzt vor selbigem Problem, mit ein wenig Herumprobieren war es gar nicht so schwer:

 

Das USG hat ja ein zweites LAN/WAN-Interface. Dieses verbindet man mit einem der noch freien LAN-Ports des Speedports. Dann richtet man im Unifi-Controller einfach ein weiteres Netzwerk ein mit der Adresse 169.254.2.2/16 (169.254.2.2/30 würde auch gehen, damit lässt man sich den restlichen APIPA-Bereich frei, falls man ihn für was-auch-immer brauchen sollte) und weist diese dem LAN2-Port zu.

Nach erfolgter Provisionierung müsste das USG den Speedport unter 169.254.2.1 schon anpingen können.

Damit das auch von den Systemen aus dem LAN funktioniert, muss nun nur noch dafür gesorgt werden, daß die entsprechenden Datenpakete maskiert (also mit der Adresse des LAN-Interfaces des USG ausgetattet) werden.

Die Kommandos dafür über ssh/console auf dem USG sind:

configure
set service nat rule 5000 destination address 169.254.2.1
set service nat rule 5000 outbound-interface eth2
set service nat rule 5000 type masquerade
commit;exit

Nach nem Neustart/Provisionierung ist das natürlich weg, also muss man das noch in eine config.gateway.json giessen:

{
	"service": {
		"nat": {
			"rule": {
				"5000": {
					"destination": {
						"address": ["169.254.2.1"]
					},
					"outbound-interface": ["eth2"],
					"type": "masquerade"
				}
			}
		}
	}
}

Damit sollte das dann funktionieren.

 

Allerdings... ist da noch Windows. Seit Vista hat Windows das "Feature", bei Existenz von mehr als einem Netzwerkinterface genau den vom Speedport als Modem verwendeten APIPA-IP-Bereich nicht korrekt zu routen. Hat ne ganze Weile gedauert, bis ich dahinter kam, deutlich länger als den Kram oben zu erstellen. Und ich wunderte mich, wieso es einfach nicht klappen will... Wütend

Das Problem umgeht man durch die Einrichtung einer statischen Route auf dem eigenen Windows-Rechner:

route add 169.254.0.0 mask 255.255.0.0 <IP des USG> -p

Und dann sollte es endlich klappen.

 

Wie man trotz des Modem-Modus an erweiterte Infos kommt, kann man hier nachlesen (ist für den Entry 2, sollte aber bei SP Smart auch klappen):

https://www.onlinekosten.de/forum/showthread.php?p=2432917#post2432917

Klappt perfekt!

Lediglich an die erweiterten Infos bin ich nicht ran gekommen. Auch das Shellskript auf der verlinkten Seite gibt eine leere Ausgabe aus.

Wenn man neben dem Masquerade noch ein Destination NAT einbaut und der USG eine weitere IP Adresse spendiert bekommt man es hin, dass man diese nach RFC nicht routbaren Adressen  169.254.x.x umgeht. So spart man sich auch die Windows Route.

 

Zusätzliche IP am USG

 

 

configure
set interfaces ethernet eth1 address 192.168.0.2/24
commit ; save

 

 

 

Destination NAT (Überschreibt die Zieladresse mit 169.254.2.1 auf USG)

 

 

configure
set service nat rule 3000 "DNAT DSL Modem Console"
set service nat rule 3000 destination address  192.168.0.2
set service nat rule 3000 inbound-interface eth1
set service nat rule 3000 inside-address address 169.254.2.1
set service nat rule 3000 protocol all
set service nat rule 3000 type destination
commit; save

 

 

 

Masquerade (Überschreibt die Sender-IP mit 169.254.2.2 aus dem USG)

 

 

configure
set service nat rule 5000 description "MASQ DSL Modem Console"
set service nat rule 5000 destination address 169.254.2.1
set service nat rule 5000 outbound-interface eth1.10
set service nat rule 5000 type masquerade
commit; save

 

 

 

Ich habe das DSL-Modem in ein eigenes VLAN 10 gehängt, deshalb eth1.10. Somit kann man das auf denselben LAN Port hängen und muss nicht LAN2 belegen. Dies geht natürlich nur, wenn man einen Managed Switch hat und die VLAN Konfig machen kann.

Vom Rechner erreicht man das Modem nun via http://192.168.0.2

 

Man muss das ganze noch in die config.gateway.json packen, damit es das provisioning überlebt:

 

 

{
	"interfaces": {
		"ethernet": {
			"eth1": {
				"address": [
                                        "192.168.0.1/24",
					"192.168.0.2/24"
				]
			}
		}
	},
	"service": {
		"nat": {
			"rule": {
				"3000": {
					"description": "DNAT DSL Modem Console",
					"destination": {
						"address": "192.168.0.2"
					},
					"inbound-interface": "eth1",
					"inside-address": {
						"address": "169.254.2.1"
					},
					"log": "disable",
					"protocol": "all",
					"type": "destination"
				},
				"5000": {
					"description": "MASQ DSL Modem Console",
					"destination": {
						"address": "169.254.2.1"
					},
					"log": "disable",
					"outbound-interface": "eth1.10",
					"type": "masquerade"
				}
			}
		}
	}
}

 

 

 

Hi! Ich habe die Hilfestellung von @hacki111  befolgt. Wenn ich die IP-Adresse aufrufe, lande ich aber immer auf dem Webinterface des USG statt des Smartports. Ich würde mich sehr freuen, wenn jemand einen Tipp für mich hätte!

 

Ich habe im Unifi Controller ein neues Netzwerk angelegt:

VLAN: 10, Gateway 169.254.2.2/24, DHCP range 169.254.2.2 - 169.254.2.254

 

Dann habe ich das Modem an mein Switch angeschlossen, den Port dem Netzwerk zugewiesen und das Modem die statische IP 169.254.2.1 zugewiesen. Danach habe ich die Regeln eingespielt (192.168.10.2 zu 169.254.2.1 + masq 169.254.2.2):

 

configure
set interfaces ethernet eth1 address 192.168.10.2/24
set service nat rule 3000 description "DNAT DSL Modem Console"
set service nat rule 3000 destination address  192.168.10.2
set service nat rule 3000 inbound-interface eth1
set service nat rule 3000 inside-address address 169.254.2.1
set service nat rule 3000 protocol all
set service nat rule 3000 type destination
set service nat rule 5000 description "MASQ DSL Modem Console"
set service nat rule 5000 destination address 169.254.2.1
set service nat rule 5000 outbound-interface eth1.10
set service nat rule 5000 type masquerade
commit
save

 

Zur Kontrolle:

 

$ show nat rules
rule   type  intf     translation
----   ----  ----     -----------
3000   DST   eth1     daddr 192.168.10.2 to 169.254.2.1
    proto-all         dport ANY

5000   MASQ  eth1.10  saddr ANY to 169.254.2.2
    proto-all         sport ANY
                      when daddr 169.254.2.1, dport ANY
$ show interfaces ethernet
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description
---------    ----------                        ---  -----------
eth0         -                                 u/u  WAN
eth0.7       -                                 u/u  WAN
eth1         192.168.1.1/24                    u/u  LAN
             192.168.10.2/24
eth1.10      169.254.2.2/24                    u/u
eth1.666     192.168.2.1/24                    u/u
eth1.777     192.168.4.1/24                    u/u
eth2         192.168.0.1/24                    u/D  LAN2

 

Wenn ich dann die ip 192.168.10.2 aufrufe, lande ich auf dem Webinterface des USG, statt auf dem Modem. Vom USG aus kann ich das Modem auf 169.254.2.1 anpingen!

 

Mir ist aufgefallen, dass ich von meinem Rechner (vlan 666) über die Adresse 169.254.2.2 nicht auf den Router zugreifen kann, auch wenn ich in der Firewall den Zugang zu VLAN 10 zulasse. Ist das normal und hat das ggf. etwas mit dem Problem zu tun?

 

2004  accept   all       0        0
  condition - match-SRC--GROUP NETv4_eth1.666 match-set NETv4_eth1.10 dst

 

 

Habe ich noch etwas vergessen/übersehen? Über Tipps würde ich mich sehr freuen...