IPv6 mit PPPoE passthrough bei My KMU Office

fiberguy

Hallo zusammen,

Ich habe ein My KMU Office M mit 8 fixen IPv4 Adressen über Kupfer. Als Router habe ich den Centro Business im Einsatz. Den Router habe ich mit PPPoE passthrough konfiguriert: Local security gateway on LAN1 - PPPoE passthrough

Dahinter steht ein Linux Firewall mit pppd. IPv4 hat so schon immer funktioniert.

Neu habe ich nun einen /48 IPv6 Prefix zugeteilt bekommen. Wenn ich PPPoE passthrough deaktiviere wird dem Router die <my-prefix>::1 zugeteilt. Nun möchte ich aber wie bei IPv4 meinen Firewall als Endpunkt einsetzen. Dazu habe ich meine ppp config entsprechend mit +ipv6 ipv6cp-use-ipaddr ergänzt.

Mit aktiviertem Debugging sehe ich nun das übers Internet Protocol Control Protocol (IPCP) die mir zugeteilte IPv4 Adresse ausgehandelt wird. Weiter ist auch das IPV6CP Protokoll aktiv und handelt eine IPv6 Adresse aus. Dabei handelt es sich allerdings um eine Link Local Adresse:

Apr 21 08:53:21 fw1 pppd[28287]: CHAP authentication succeeded
Apr 21 08:53:21 fw1 pppd[28287]: peer from calling number E8:74:E6:6F:**:** authorized
Apr 21 08:53:21 fw1 pppd[28287]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
Apr 21 08:53:21 fw1 pppd[28287]: sent [IPV6CP ConfReq id=0x1 <addr fe80::8d15:fe4c:619f:cb6f>]
Apr 21 08:53:21 fw1 pppd[28287]: rcvd [IPCP ConfReq id=0x1 <addr 213.3.210.67>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 59 ac c4 f0 26 4e 14 00 00 00 02...
Apr 21 08:53:21 fw1 pppd[28287]: sent [IPCP ConfAck id=0x1 <addr 213.3.210.67>]
Apr 21 08:53:21 fw1 pppd[28287]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::ca4c:75ff:fed9:af00>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fb 7e 45 ff f0 00 4e 1a 00 00 61 9a 02 00 00 00
Apr 21 08:53:21 fw1 pppd[28287]: sent [IPV6CP ConfAck id=0x1 <addr fe80::ca4c:75ff:fed9:af00>]
Apr 21 08:53:21 fw1 pppd[28287]: rcvd [IPCP ConfNak id=0x1 <addr 84.253.**.***>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 38 b5 69 13 16 4e 14 00 00 05 dc...
Apr 21 08:53:21 fw1 pppd[28287]: sent [IPCP ConfReq id=0x2 <addr 84.253.**.***>]
Apr 21 08:53:21 fw1 pppd[28287]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::8d15:fe4c:619f:cb6f>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ca 45 7d 17 30 00 4e 10 09 09 09 72 65 74 75 72
Apr 21 08:53:21 fw1 pppd[28287]: local LL address fe80::8d15:fe4c:619f:cb6f
Apr 21 08:53:21 fw1 pppd[28287]: remote LL address fe80::ca4c:75ff:fed9:af00
Apr 21 08:53:21 fw1 pppd[28287]: Script /etc/ppp/ipv6-up started (pid 28323)
Apr 21 08:53:21 fw1 pppd[28287]: Script /etc/ppp/ipv6-up finished (pid 28323), status = 0x0
Apr 21 08:53:21 fw1 pppd[28287]: rcvd [IPCP ConfAck id=0x2 <addr 84.253.**.***>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6b b0 dd f0 8b 24 e5 a8 00 00 05 dc...
Apr 21 08:53:21 fw1 pppd[28287]: replacing old default route to eth1.101 [84.253.**.***]
Apr 21 08:53:21 fw1 pppd[28287]: local IP address 84.253.**.***
Apr 21 08:53:21 fw1 pppd[28287]: remote IP address 213.3.210.67
Apr 21 08:53:21 fw1 pppd[28287]: Script /etc/ppp/ip-up started (pid 28325)
Apr 21 08:53:21 fw1 pppd[28287]: Script /etc/ppp/ip-up finished (pid 28325), status = 0x0

Soweit so gut. Die Link Local Adresse sehe ich dann auf dem Interface ppp0:

# ip a show dev ppp0
37: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 84.253.**.*** peer 213.3.210.67/32 scope global ppp0
valid_lft forever preferred_lft forever
inet6 fe80::8d15:fe4c:619f:cb6f/10 scope link
valid_lft forever preferred_lft forever

Ein ping6 auf die remote Link Local Adresse ergibt aber keine Antwort:

ping6 -I ppp0 fe80::ca4c:75ff:fed9:af00
PING fe80::ca4c:75ff:fed9:af00(fe80::ca4c:75ff:fed9:af00) from fe80::8d15:fe4c:619f:cb6f ppp0: 56 data bytes

Ich hätte nun erwartet das ich via SLAAC (Stateless Address Autoconfiguration) Router Advertisement meine globale IPv6 Config bekommen würde. Laut tcpdump kommt da aber nichts daher:

# tcpdump -i ppp0 -n -s 0 -v ip6 and icmp6
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

Weiss jemand wie das technisch gelöst ist? Muss ich DHCPv6 verwenden? Ein kurzer Versuch brachte auch damit keinen Erfolg.

@Tux0ne

Ich bin für alle Tipps dankbar!

Merci und Gruss

Luke

Tux0ne

_Neu habe ich nun einen /48 IPv6 Prefix zugeteilt bekommen. Wenn ich PPPoE passthrough deaktiviere wird dem Router die <my-prefix>::1 zugeteilt. Nun möchte ich aber wie bei IPv4 meinen Firewall als Endpunkt einsetzen. Dazu habe ich meine ppp config entsprechend mit +ipv6 ipv6cp-use-ipaddr ergänz_t

Eben und das ist doch falsch? Wenn man den Passthrough aktiviert, so sollte v6 auch auf der Firewall terminiert werden und der CB sollte alles freigeben. Du hast einen Centro Business 1.0 mit ipv6 tauglicher Firmware.

Beim Centro Business 2.0, welcher noch nicht v6 tauglich ist, funktioniert das Vorgehen wie du beschreibts aber.

Ich habe das der Swisscom gemeldet. Es ist kompliziert. So all Schaltjahr versuchen sie mich anzurufen, erreichen mich aber nie. Der Fall ist immer noch offen.

Korrekt wäre bisher:

Prefix Bezug über DHCPv6-PD, (WAN nur link-local)

LAN stateless oder statisch nach Gusto. Aber auch hier... Es gibt keine Anleitungen wie was überhaupt funktionieren sollte. Auch das habe ich gemeldet...

Die einzigste Anleitung ist diese hier:

http://documents.swisscom.com/product/1000260-Connectivity_Geraete_/Documents/Spezifikationen/Centro_Business_Einstellungen_der_IP-Adresseriung_im_LAN-de.pdf

Aber auch dies entspricht nicht dem Use case. Und zudem auch hier. Wieso kann man nicht das /48 Netz durchgehend so verwalten wie man möchte? Nein die generierten 64 Netze sind vorgegeben. Bereits auch mal hinterfragt bei Swisscom. Noch keine Antwort, aber eben bin auch schlecht erreichbar 🙂

Tux0ne

hast du in der Zwischenzeit noch etwas herausbekommen @fiberguy?

fiberguy

@Tux0ne

Ich habe noch einen zweiten Standort mit einem Fiber Anschluss und einem Centro Business 2. Dort kann ich nach der Einwahl mittels ppp die Remote Link Local Adresse pingen. Zudem bekomme ich Router Advertisements was mir dann die IPv6 Default Route konfiguriert. Nach etwas rumprobieren mit dhcpcd5 habe ich dann tatsächlich meinen Prefix erhalten und konnte per IPv6 kommunizieren. Die WAN IP Adresse setzte ich nun per ppp/ip-up.local Script auf was ich will.

Am Standort mit dem Kupfer Anschluss und dem Centro Business 1 komme ich nicht weiter.

Merci und Gruss

Luke

Tux0ne

Bezüglich CB 1 habe ich noch folgende Antwort erhalten:

Die unten beschriebene Problematik betreffend Centro Business und IPv6 im Mode PPP-Passthrough konnte ich nun noch einmal testen. Ich habe Ihnen im Anhang einen Draft der Konfigurations-Beschreibung für eine Zywall beigelegt. Generell ist es so dass bei aktiviertem PPP-Passthrough der Centro Business keinen Zugriff auf die PPPoE Session hat. Das funktioniert auch korrekt.

Dank Ihrer Meldung konnten wir aber noch einen Fehler im Centro finden. Wenn ein CB auf einem Anschluss mit fixen IP Adressen betrieben wird, ist der Prefix im Router-GUI ersichtlich. Wenn nun PPP-Passthrough aktiviert wird darf der Prefix im Router-GUI nicht mehr ersichtlich sein. Auf das Subnet /48 ist selbstverständlich falsch. Bei Anschlüssen mit fixen IP Adressen wird ein /48er Subnet zugeteilt, bei Anschlüssen ohne fixen IP Adressen ein /60 Subnet. Diese Fehler werden mit einem Folgerelease behoben.

Achtung: Bei Centro Business 2.0 steht IPv6 erst ab der FW 8.02.06 vollumfänglich zur Verfügung.

Ich hoffe Ihnen mit diesen Angaben dienen zu können.

Habe aber noch Probleme mit pfsense. Da funzt etwas noch nicht wirklich toll.

Tux0ne

@fiberguy

Funktioniert am Standort mit CB 2.0 der IPv6 Traffic problemlos oder nur icmp?

Werden alle Seiten komplett und ohne murren zügig geladen? zB. Google, Youtube und Facebook?

hosebei

@fiberguy@"x"#939

hatte/habe dieselbe Konfiguration am laufen gehabt an einem Kupferanschluss mit CB2.

DHCPv6-PD lief einwandfrei, konnte mein /48 nutzen und entsprechend Routen, alles ohne Problem. Seit gestern ist aber dunkel, und ich wüsste nicht, was ich verändert haben sollte.

Eine Anleitung seitens Swisscom wäre schon nicht verkehrt, da musste man nun schon so lange darauf warten...

Werde mich wohl am Mittwoch telefonisch melden, falls es bis da noch nicht wieder gehen sollte. Ist für mich zum Glück nicht allzu kritisch, IPv4 funktioniert ja noch 🙂

Tux0ne

Ja melde dich doch falls es wieder läuft.

Welches System hast du verwendet?

Ich warte derweilen mal eine Antwort der Swisscom ab ob das alles tatsächlich so läuft wie sie es denken.

Gedult ist dabei gefragt 🙂

Bei mir funktioniert es weder mit einem Linux System noch mit pfsense. Ich bekomme zwar schon die korrekten IPv6. Ausser ICMP ist aber keine wirkliche Kommunikation möglich.

fiberguy

@Tux0ne @hosebei

Hallo zämä,

Ich betreibe an meinem CB2 mit Fibre zurzeit nur ein DNS Server über IPv6 und der läuft stabil. Alles andere läuft grösstenteils noch über IPv4. Auf die Frage von Tux0ne habe ich mir das aber nun mal genauer angeschaut. Starte ich ein wget über IPv6 legt er ziemlich gut los:

luke@fw1:/tmp$ wget -6 http://mirror.switch.ch/ftp/mirror/debian-cd/current/amd64/iso-cd/debian-8.4.0-amd64-netinst.iso
--2016-05-27 08:27:47-- http://mirror.switch.ch/ftp/mirror/debian-cd/current/amd64/iso-cd/debian-8.4.0-amd64-netinst.iso
Resolving mirror.switch.ch (mirror.switch.ch)... 2001:620:0:8::20
Connecting to mirror.switch.ch (mirror.switch.ch)|2001:620:0:8::20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 258998272 (247M) [application/x-iso9660-image]
Saving to: 'debian-8.4.0-amd64-netinst.iso.1'

debian-8.4.0-amd64-netinst.iso.1 17%[===============> ] 42.17M 14.5MB/s ^

Nach ca. 30-40 MBytes stockt der Download komplett. Starte ich einen neuen Download, stockt der schon früher. Immer so bei 10-15Mbytes. Laut tcpdump passiert in dieser Zeit überhaupt nichts. Mir ist dann aufgefallen, dass wenn ich den Download laufen lasse, dass es nach ziemlich genau 60 Sekunden wieder weiter geht. Allerdings nur für ca. 5 MBytes, dann ist wieder Schluss für 60 Sekunden.

Für mich sieht das ein bisschen nach einem Traffic-Shaper verhalten aus. Initial wird ein etwas grösserer Burst zugelassen, dann nur noch 5MBytes alle 60 Sekunden. Kann mir das Verhalten jedenfalls sonst nicht erklären.

Werde das bei Gelegenheit noch mit dem Upload testen um zu sehen, ob das Verhalten dort gleich ist.

Betreffend DHCPv6-PD muss man mit Packetfiltern wie ip6tables aufpassen damit man nichts in dem Zusammenhang blockt. Sonst geht IPv6 plötzlich nicht mehr und keiner weiss wieso. Habe da auch ein paar Erfahrungen gemacht. Auch die folgende sysctl Werte werden gerne einmal überschrieben wenn sich der Zustand eines Interfaces verändert:

root@fw1:/etc/ppp# sysctl net.ipv6.conf.ppp0.accept_ra
net.ipv6.conf.ppp0.accept_ra = 2
root@fw1:/etc/ppp# sysctl net.ipv6.conf.ppp0.forwarding
net.ipv6.conf.ppp0.forwarding = 2

Könnte bei Interesse vielleicht eine kurze Anleitung schreiben wie ich das auf Linux konfiguriert habe.

Es bleibt spannend!

Merci und Gruss

Luke

hosebei

@fiberguy @Tux0ne

Hallo zäme,

Habe ein Centro Business (der wie ich heute erfahren habe, letzte Woche mit einem Firmware Update beglückt wurde -> 7.10.18), als PPPoE passthrough konfiguriert.

hatte bisher pfSense so eingerichtet, dass die WAN Schnittstelle für IPv6 ein DHCPv6 konfiguriert ist, und das Netz via den IPv6 link anfordern soll. Die Konfiguration hat stabil bis letzten Montag so funktioniert.

Auf der WAN Schnittstelle habe ich eine fe80 Adresse mit entsprechendem Gateway erhalten. Die LAN Schnitstelle habe ich als "Track Interface" konfiguriert, mit einem Präfix wunsch von "1", und ich erhielt eine entsprechende IPv6 Adresse aus meinem zugewiesenen Range zugeteilt. Diese war nicht konfigurierbar, aber leitete sich von der MAC Adresse ab. Ebendiese LAN IPv6 Adresse habe ich hinter der DMZ dann als Gateway für die Geräte in der DMZ verwendet.

Lief alles flott, bis eben auf letzten Montag. Habe nun mit Swisscom Kontakt aufgenommen, und konnte mein Problem schildern. Nun warte ich auf eine entsprechende Rückmeldung, würde mich hier dann auch wieder melden wenn ich mehr weiss.

Gruess

Tux0ne

@fiberguy

Dies deckt sich mit meinen Beobachtungen. Der Download startet und stoppt ziemlich abrupt.

Bei Youtube kann man das auch beobachten. Der Clip wird zu einigen Prozent geladen, aber es lädt nicht weiter. Der Clip läuft nun bis er keine Daten mehr hat. Dann startet ein neuer Request und dieser lädt wieder einen Teil.

v6 Downloads können auch nicht geladen werden. Speedtest's ziehen an und stoppen nach 1-2 Sekunden. ICMP Request's kannst du aber froh und munter generieren. Da sieht alles i.O aus.

hosebei

Da ich immer aktuellste Firmwares habe, hatte ich mit CB 1 schon seit mir native v6 geschaltet wurde keinen Erfolg.

Ich nehme an das bei dir pfsense das Gateway schon gar nicht mehr erreichen kann.

Ich habe hier mal eine Anfrage gestartet: https://forum.pfsense.org/index.php?topic=111908.0

Muss aber wohl melden, dass das Problem eher beim Provider liegt 😉

2016-05-27 12_25_54-IPv6 speed test - Test your IPv6 broadband speed - ipv6-speedtest.net.png

hosebei

@fiberguy

Das ist korrekt, ich kann seit zwei Wochen den Gateway nicht mehr erreichen. Ich kann nicht verstehen, warum meine Konfiguration nun etwas mehr als einen Monat fehlerfrei funktionierte, und es nun Swisscom nicht wieder zum laufen bringt. Oder mir zumindest sagen kann, was ich eigentlich konfigurieren sollte, der Fehler könnte ja auch bei mir liegen...

Ich habe von einem Tunnelanbieter, mit welchem ich nun über Jahre erfolgreich opereierte, zur Swisscom gewechselt, und bin über den Stand der Technik und der Angebotenen Dokumentation mehr als ernüchtert 😕

Ich hoffe die liefern da bald mal was nach, schliesslich ist dies als normales Abo zu erstehen, und nicht als Beta mit geringerem Preis ausgeschrieben.

Tux0ne

Ehm mein Problem besteht nun seit März.

Die v6 Testphase war im Herbst letzten Jahres. Es wäre also cool man würde die Probleme nun in der produktiven Phase endlich mal lösen!

Der Witz an den fixen IP's wäre, das man eben eigenes Equipement verwenden kann. Setzt natürlich voraus, dass auch die nativen v6 Geschichten darauf funktionieren.

Sonst kann ich gleich auf die Vivo Angebote wechseln, wären etwas günstiger...

Tux0ne

Firmware 8.02.10, Problem weiterhin pendent.

hosebei

Ich habe Firmware 7.10.18 und das Problem ist nachwievor nicht gelöst 😞

Tux0ne

Heute Update auf 8.02.12 gemacht.

Problem nicht gelöst. Fall aber nun bei Swisscom geschlossen, bzw. muss wohl annehmen das dies bei Swisscom nun auf gelöst gebucht wird.

In der Länge dieses Problems und der sogenannten 0 Kommunikation buche ich es als " Nicht empfehlenswert!"

fiberguy

@Tux0ne Das Problem besteht immer noch aber Swisscom hat das Ticket geschlossen?? Ich zahle ziemlich viel Geld monatlich für mehrere Standorte und habe auch wegen IPv6 zu Swisscom gewechselt. Nun funktioniert das nach Monaten immer noch nicht und keiner kümmert sich darum?! Wo kann ich das bitte eskalieren?

Tux0ne

Bei mir ist es einfach versandet.

Ich habe auch keine Lust nochmals der Hotline anzurufen um dann Anweisung zu erhalten ich solle doch ein Mail an eine bestimmte Adresse senden, da man hier beim Support keine IPv6 Spezialisten hat.

Ich habe durchaus Verständnis, dass es sicher verschiedene Prioritäten gibt.

So soll der Router alle Rollen einnehmen können, vom KMU mit Privatansprüchen über den Ersatz von BIL und BIS Anschlüssen in diversen Konstellationen und Ausprägungen. Also vom DAU Gerät was irgendwie doch VPN, super WLAN AC, Guest Network usw. haben soll, bis zum Durchlauferhitzer mit mehreren fixen IP's an einem Business Connect Hosted oder Trunk (und da noch die Kompatibilität zu SIP Direkt, SBC oder SIP-ISDN). Das da v6 im PPPoE Modus relativ weit hinten liegen mag, ist mir schon noch irgendwo klar...

Aber bitte: Gebt hier mal Feedback.

Löst das Problem und schiebt mal wieder eine nette Gutschrift rüber 😄

RicoS

Hallo Community

Ja da habt Ihr recht, mit IPv6 im Kontext mit PPP-Passthrough (terminierung auf einer Firewall resp. SecuirtyGateway) scheint ein Problem zu bestehen. Danke für euer Feedback!

Diese Funktion hat zu Beginn einmal funktioniert, leider hat ein aktuell noch unbekannter Umstand das Problem verursacht.

Das Thema ist bei den verantwortlichen Personen/Projekt etwas unter den Radar gerutscht aufgrund einiger anderen Prioritäten... Entschuldigung.

Wir starten die Analyse des Sachverhalts nochmals neu und streben eine möglichst rasche Fehlerbehebung an.

Bisdahin gilt es leider mit PPPPassthrough wird nur IPv4 unterstützt. Bei dringenden Bedarf kann die DMZ-Konfiguration allenfalls Abhilfe schaffen.

Danke für euer Verständnis

Tux0ne

Ich glaube nicht mal das funktioniert. Habe jetzt 4 IP Adressen gelöst damit ich die DMZ konfigurieren kann.
Wir erhalten auf dem Centro Business ein 48 Netz. Daraus macht er ein 64 Netz fürs LAN und ein 64 Netz für die DMZ.
Aber was will ich damit auf der Firewall in der DMZ?
Da brauche ich doch mind. ein 62 Netz via PD. Besser ein 56 Netz. Nur so kann ich ja ein v6 Netz im LAN der Firewall verteilen. Das 64 Netz auf der WAN Schnittstelle nützt mir nichts.
Also entweder funktioniert auch das nicht oder ich habs nicht verstanden.

Nächste Seite »