Umstieg von 3390 auf Vigor 130 + USG

Hallo zusammen,

ich bin derzeit ziemlich ratlos. Ich möchte meine alte Fritzbox (und ihre furchtbaren lokalen Namen mit fritz.box) endlich mal loswerden.

Das Netz läuft schon länger mit der Ubiquiti Hardware, hauptsächlich zum Versorgen des WLANs. Das ganze Konzept überzeugt mich, sodass ich mich mehr in Richtung Ubiquiti bewegen will.

Hierzu hatte ich vor einiger Zeit schon einen Vigor 130 mit besorgt, welcher als Modem dienen soll. Kürzlich kam endlich die USG ins Haus.

Das Setup soll die Fritzbox ablösen und ohne Doppel-NAT arbeiten. Sobald die normale v4 Verbindung geht, soll wieder v6 wieder im Heimnetz Einzug halten.

Das Netzwerk ist wie folgt konfiguriert:

Telekom - Vigor 130 - USG - Netzwek

Das Heimnetzwerk läuft unter 192.168.56.0/24 . Im Vorfeld habe ich temporär v6 deaktiviert um mich iterativ der Umstellung auf die USG zu nähern.

Zwischen Vigor Und USG läuft 192.168.156.0/24 , Vigor ist x.1 , USG wird statisch x.10 (Routen sind konfiguriert)

Über den SSH Zugang habe ich zunächst zusätzlich auf dem WAN Port die 192.168.156.10 ergänzt (Über die Provisionierung kommt das wenn alles läuft).

Den Vigor habe ich nach mehreren Anleitung im Netz konfiguriert.

USG übernahm Skynet mäßig beim Kontakt zum Kontroller mein Heimnetz. die USG hat im Heimnetz die 192.168.56.1 (Gleichzeitig wird die FB abgeklemmt). Ich habe die (bisher deaktivierte) DHCP Einstellung konfiguriert (gleiche Ranges, Fixes IPs waren größtenteils schon in den Client Konfigurationen definiert), Port Forwards aus der FB nach Ubiquiti übertragen.

Der Vigor synchronisiert sauber und stellt seine Dienste als Passthrough bereit.

Der Form halber: Vigor Steckt in WAN1 , Netzwerk im LAN Port.

Die USG hat die Telekom-Zugangsdaten im Bauch, verbindet sich und bekommt eine IP Adresse. Ich suggeriere, dass die PPPoe-Passthrough option arbeitet, da der pppd keine Fehler in /var/log/messages liefert. nur eine Meldung von Zebra Jan 12 05:28:55 ubnt zebra[753]: warning: PtP interface ppp0 with addr 46.94.119.197/32 needs a peer address

Hier fängt nun das Problem an, gedebugged via SSH vom USG:

• Es kommt keine Antwort von der Telekom Gegenstelle zurück. (tcpdump auf pppoe)
• Es kommt kein Ping, Traceroute, nichts.
• PPPD meldet keine Fehler

Ich sehe im tcpdump die ausgehenden Pakete, keine Rückmeldungen.

Was ich dann noch ohne Erfolg getestet habe:

• VLAN 7 Tag auf dem Vigor setzen, USG nicht. (Verbindung ok, keine Rückmeldung)
• VLAN 7 Tag Vigor nicht, USG setzen (Verbindung ok, keine Rückmeldung)
• Gemischt (keine Verbindung, Negativtest)
• Bei laufender Verbindung den MTU Wert vom pppoe0 Interface runtersetzen - keine Änderung
• Iptables geflushed bei laufender Verbindung, keine eingehenden Pakete
• Zugangsdaten in den Vigor eingegeben, als PPPoE Client aktiviert, USG via DHCP sich versorgen lassen, statt PPPoE -> Verbindung im Vigor, Zugriff aus USG und Heimnetz geht. (Konfiguration als Fallback über WAN2 des USG).

Ich habe wirklich schon einige Jahre mit dem Zeug auf dem Buckel, aber PPPoe, MTU und die Probleme hier, lassen mich ratlos zurück.

Ich habe von den verschiednene Panels (Vigor und Controller) Screenshots gemacht, ebenso auch vom log aus dem Test der USG.

Kann mir bitte jemand einen Tipp geben was ich umstellen muss?

Braucht ihr noch Infos?

Liebe Grüße

Matthias

Hallo,

vielen Dank für die Rückmeldung. Ich bin im Moment schon etwas verzweifelt, weil ich Stunden um Stunden mit Try&Error Zeit aus dem Fenster werfe.

Zitat

So habe ich das auch laufen...Du bekommst ne IP, Einwahl ist damit eigentlich fein.

Auch schön Test von der USG selber was dann „irgendwas“ dahinter ausschließt wie falsche IP.

Danke.

Zitat

Was mich verwirrt.. warum nennt die Büchse das ppp0 interface nach der Einwahl in pppoe2 um

also nicht das umbenennen selber sondern das „2“ es sollte eigentlich pppoe0 „0“ sein.

Lass dich davon bitte nicht verwirren. Wenn ich mit dem Test anfange, dann ist das in der Regel auf pppoe0 und nicht 2. Beim Rumspielen kommt es hin und wieder vor, dass es zum pppoe2 wird.

Zitat

Versteckt sich da irgendwo ein FailOver ?

FailOver ist inzwischen konfiguriert als DHCP auf dem zweiten WAN Port. Der Port ist nicht verbunden, ich war nur zu Faul um den Failover zu löschen.

Ob mit oder ohne Failover macht bisher keinen Unterschied im Verhalten.

WAN1 ist für PPPoE , LAN1 geht Richtung Heimnetz, LAN2/WAN2 ist nicht belegt.

FactoryReset und neu adaptieren habe ich heute morgen versucht. Ohne Erfolg.

Zitat

Irgendwelche Firwall Settings ? oder config.gateway.json Gespiele ?

Nur das was ich gepostet habe. config.gateway.json wird im Anschluss für das 192.168.156.0/24 Netz für WAN1 ergänzt. Derzeit füge ich eine neue IP via ip addr add dev eth0 192.168.156.10/24 hinzu. Ob die Adresse gesetzt ist oder nicht, macht keinen Unterschied. Selbst der ping direkt auf dem pppoe0 Device macht keinen Unterschied.

Zitat

Du sagtest zwar das du ein Fluss der Firwall gemacht hast aber je nachdem hat das nicht lange Bedeutung

oder da steckt auch viel kram in der mangle und nat Table.

Korrekt. Ich hatte einfach mal einen Flush gemacht und dann direkt mit dem ping & tcpdump auf dem ausgehenden Interface geschaut ob sich eine Änderung ergeben hat. Hat es nicht, ich habe dann dafür gesorgt, dass die iptables-Regeln wieder aufs System kommen. (Ich versuche möglichst immer wieder von einem Grundzustand aus wieder mit einem Test zu starten).

Zitat

WARUM die 4.4.4 Firmware ? die ist DREI Jahre alt... die aktuelle 4.4.56 nur ein Jahr...

Das liegt nur daran, dass das Gerät & Controller eigenständig nicht in der Lage waren ein Update durchzuführen (Das Internet ist ja down). Bisher hatte ich die Updates immer dem Ubiquiti System überlassen. Ich ziehe mir gleich die Firmware mal auf den Rechner und mache das Update morgen mit der Hand.

Ich habe heute noch versucht mit unterschiedlichen MTU Werten (Modem, USG-eth0, USG-pppoe) etwas zu erreichen. Ohne Erfolg.

VLAN7 im Modem oder USG brachte auch keinen Unterschied (persönlich würde ich es auch lieber im USG setzen).

Offloads auf die Hardware ja/nein haben auch keinen Unterschied gebracht.

Zitat

Schuss ins blaue: das sollte im Vigor dann auf disabled stehen und nicht enabled.

Ja, das ist mir auch schon aufgefallen. Das habe ich heute morgen durchprobiert. Ohne Erfolg. Ich packe das aber auf die Liste für den Test für morgen früh.

Zitat

Völlig sekundär, jedenfalls bei dingen wie PING, da kommt du never ever an 1492 byte ran die

der payload+IP werden darf bei „normalen“ PPPOE Geschichten.

Ja stimmt, ich hatte aber auch die Ping-Size angepasst.

ip rule kannte ich noch nicht. Ich hatte mir die "ip route" informationen angeschaut. Diese suggerierten mir, dass die default route über das pppoe0 (pppoe2) raus geht. Unabhängig davon sollte ein ping -I pppoe0  auch rausgehen unabhängig von den restlichen Routen.

Zitat

nen traceroute 1.1.1.1 endet auch am interface WAN oder ?

Traceroute 8.8.8.8 endet leider auf meiner Seite am WAN interface (also pppoe*) .

Für morgen steht an:

- FW Update

- VLAN Tagging-Einstellungen nochmal anschauen und verifizieren

- ip rule printout erzeugen

So, es hat mir keine Ruhe gelassen. Kumpel hat auch 4 Augen Prinzip mitgemacht.

1. FW Update durch, keine Besserung.

2. VLAN Tagging im Vigor ist deaktiviert, Tagging im USG ist an

3. ip rule

Zitat

matze@ubnt:~$ ip rule

0: from all lookup local

32766: from all lookup main

32767: from all lookup default

matze@ubnt:~$ ip route

default dev pppoe2 proto zebra scope link

62.155.246.13 dev pppoe2 proto kernel scope link src 46.94.116.25

127.0.0.0/8 dev lo proto kernel scope link src 127.0.0.1

192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.1

192.168.156.0/24 dev eth0 proto kernel scope link src 192.168.156.10

matze@ubnt:~$

Alles anzeigen

Mich beschäftigt jetzt doch das pppoe2 , das war ganz am Anfang (wo es auch nicht ging) nicht so. Könnte ein Artefakt sein.. vom vielen Herumspielen.

edit: Zur ergänzung, ich habe die 192.168.156.0/24 route über den Controller gesetzt.

interfaces {

ethernet eth0 {

description WAN

vif 7 {

description WAN

firewall {

in {

ipv6-name WANv6_IN

name WAN_IN

}

local {

ipv6-name WANv6_LOCAL

name WAN_LOCAL

}

out {

ipv6-name WANv6_OUT

name WAN_OUT

}

}

pppoe 2 {

default-route none

firewall {

in {

ipv6-name WANv6_IN

name WAN_IN

}

local {

ipv6-name WANv6_LOCAL

name WAN_LOCAL

}

out {

ipv6-name WANv6_OUT

name WAN_OUT

}

}

name-server none

password ****************

user-id ************************@t-online.de

}

}

}

ethernet eth1 {

address 192.168.56.1/24

description LAN

firewall {

in {

ipv6-name LANv6_IN

name LAN_IN

}

local {

ipv6-name LANv6_LOCAL

name LAN_LOCAL

}

out {

ipv6-name LANv6_OUT

name LAN_OUT

}

}

}

ethernet eth2 {

disable

}

loopback lo {

}

}

port-forward {

auto-firewall disable

hairpin-nat enable

lan-interface eth1

wan-interface pppoe2

}

protocols {

static {

interface-route 0.0.0.0/0 {

next-hop-interface pppoe2 {

distance 1

}

}

route 192.168.156.0/24 {

next-hop 192.168.56.1 {

distance 1

}

}

}

}

edit: Beim Wechsel von VLAN7 nach "ohne in USG" ist aus dem pppoe2 wieder pppoe0 geworden

Also vernachlässigbar.

Moin,

ich hatte vor dem Start das Update auf die neuste Firmware gemacht. Laut meinem Download Ordner ist das 3.8.5_m7 .

Heute morgen will ich nochmal eine Stunde investieren, folgendes steht auf dem Zettel:

• FW des Vigors kontrollorieren.
• FritzBox als PPPoE Client
• Factory Reset Vigor und nochmal neu

Lg Matthias

Firmware ist die 3.8.5_m7

Fritzbox baut die Verbindung mit dem externen Modem reibungslos auf (VLAN Tag in Vigor disabled)

Boah ey…

Ich versuche mich heute Abend vielleicht nochmal.. langsam zwacke ich zu viel Zeit für das Thema ab :-o

Seit heute früh läuft der Vigor jetzt mit der Fritzbox zusammen. Ohne Probleme. Ich hab im Laufe des Vormittags den DHCP Dienst noch von der Fritzbox "runtergenommen" und hier auf eine virtuelle Maschine ausgelagert... damit das Netzwerk hier nicht immer auf "halb 8" hängt, wenn ich rumbastel.

Ja, ich habe einen managed Switch mit Monitor Funktion, der hängt hier voll bestückt im Arbeitszimmer... ich könnte den dafür nehmen. Das ist dann aber schon eine abendfüllende Aktion. Die USG steht zudem in einem anderen Kellerraum als der DSL Endpunkt.

Ich ziehe die USG mal nach vorne, wo auch aktuell die Fritzbox steht. Bisher läuft für das USG Szenario das DSL Kabel beim Vigor im Hauswirtschaftsraum rein, und ganz normal Ethernet dann gepatcht auf eine zweite Dose im 2. Kellerraum wo die USG, mein NAS und noch mehr Spielzeug ist. Das wäre noch eine Option um Fehler auszuschließen.

Ich sehe gerade, dass ich den tcpdump auf dem pppoe Interface gezogen habe. Alternativ kann ich das auch auf dem eth0 Interface machen, dann sehe ich im Dump, dass der PPP/POE Header (aus dem Kopf nicht ganz sicher) vorne ansteht, aber es kommen keine PPP geflaggten Daten zurück. Was ich sehe sind nur die LC-irgendwas Meldungen wo quasi ein "alive" gemacht wird. Ich kann den Dump hierzu auch mal ziehen.

Die Liste für heute Abend wäre zunächst:

• iptables output ziehen
• WAN2 als Port versuchen
• USG in Hauswirtschaftsraum stellen

Das Projekt "wir machen einen Dump via Monitor-Port, muss ich vermutlich am Wochenende dann machen.

Alternativ kann ich auch mal einen OpenWrt Router rausziehen und mit dem Rumspielen

Was ich noch auf der Liste habe, ist im Zweifel mal Ubiquiti selbst anschreiben und sagen was für ein sc**** Produkt das ist ... natürlich um Hilfe bitten.

edit: Ich werde es heute nicht mehr schaffen, der WAF ist zu niedrig.

Also wir (4 Augen Prinzip)sind gestern um kurz nach 23:00 Uhr alle Reiter des Vigors nochmal durch. Und ist nichts aufgefallen.

Dann dürfte eigentlich auch die Fritzbox keine Verbindung aufbauen.

Ja, factory reset habe ich heute morgen, nachdem es mit der Fritzbox ging, nicht gemacht.

Kann es sein, dass die Ursache ist, dass er das pppoe2 Interface nicht als WAN alias anlegt?

edit: nein, gerade getestet.. :-/

Iptables output im Anhang.

root@ubnt:/home/matze# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 70:a7:41:f7:6e:5c brd ff:ff:ff:ff:ff:ff
    alias WAN
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 70:a7:41:f7:6e:5d brd ff:ff:ff:ff:ff:ff
    alias LAN
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
    link/ether 70:a7:41:f7:6e:5e brd ff:ff:ff:ff:ff:ff
5: imq0: <NOARP,UP,LOWER_UP> mtu 16000 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 11000
    link/void
13: eth0.7@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 70:a7:41:f7:6e:5c brd ff:ff:ff:ff:ff:ff
    alias WAN
14: pppoe2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 100
    link/ppp

edit2:

Ok.. Ihr glaubt es nicht. Ich selbst glaube es kaum.

Ich habe den Fehler gefunden. Ich hatte das Passwort der ISP Verbindung falsch! Es stand vorne dran "passwd=". Das muss scheinbar beim Umkopieren aus dem Fritzbox-Konfigurationsexport passiert sein. Entweder lügt die Telekom hier mit dem "PAP authentication succeeded" oder der ppp-Dienst kommt dann mit den Parametern irgendwie durcheinander.

holy crap.

Gefunden, weil ich gerade den WAN Port wechseln wollte. Das hat der Kontroller aber irgendwie nur mit einem Fehler quittiert. Dann dachte ich mir: "Sichere dir die Logindaten und lösche den Eintrag ganz".. und beim Anschauen vom Passwrot sind mir die Augen aus dem Kopf gefallen.

Oh Gott wie peinlich.

-------

edit3: Was jetzt noch ansteht ist das einstellen der configuration.json, damit das 192.168.156.0/24 er Netz auf dem WAN anliegt und ich möchte IPv6 wieder aktivieren und nutzbar machen.

Und da ich es gestern Abend total vergessen habe:

Vielen Dank für die technische, seelische und moralische Unterstützung bei der Analyse!

Inzwischen läuft das Netz stabil, v6 ist auch wieder aktiv.

Ich muss jetzt nur nochmal schauen, ob man die Kommandos

configure
set interfaces ethernet eth0 dhcpv6-pd prefix-only
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd prefix-only
commit;save;exit

von https://hochwald.net/ubiquiti-…l-and-vigor-130-as-modem/

Nicht noch sinnvoll in der json ablegen kann, damit der USG hier nicht so viel CPU verbrennen muss.

Tatsächlich ist mir gestern aufgefallen, dass es regelmäßig PADO(?) (Kommunikation zum Modem) gibt.

Vielleicht macht der Umstieg ja Sinn..

v6 ging heute morgen auch wieder nicht mehr 🙄