eripek diese Link-Local-Unicast-Adressen sind Teufelswerk; 
Was hätte netcup denn getan, um diese hervorragenden Mechanismen zu unterbinden?
diese fe80::1 default Gateway, welches wir lt. Anleitung auf unseren vServern eintragen,
ist nicht immer das Selbe; 
des kommt im gesamten netcup-Netzwerk x-fach vor; ich würd fast meinen auf jedem Host einmal; 
Es genügt ja, wenn NDP funktioniert und router advertisement vorhanden ist.
Nur gibt es das RA nicht. Oder willst du dir das selber auf deinem Server generieren? Den radvd mit dem statischen Subnetz einrichten, nur damit man das Netzwerk nicht direkt damit einrichten muss? Ist das dein Plan? Was hätte das für einen Vorteil?
Wenn ich dann allerdings auf dem LAN interface versuche zu pingen, schlägt der Ping mit 100% Packetloss fehl
Du hast im Ping Befehl das Interface angegeben? Oder die Source Adresse? Beim Interface schlägt es natürlich fehl. Das LAN Interface hat keine Verbindung zum WAN. Wenn du nur die Source Adresse setzt, sähe das anders aus, aber dann würde das Paket trotz der source Adresse über das WAN Interface fließen.
Ich kann vom LAN aus nicht mal das Default Gateway pingen O_o
Auch das ist normal, denn das Gateway hängt nicht am LAN Interface, und das LAN Interface hat sein eigenes fe80:: Netz.
Nur gibt es das RA nicht. Oder willst du dir das selber auf deinem Server generieren? Den radvd mit dem statischen Subnetz einrichten, nur damit man das Netzwerk nicht direkt damit einrichten muss? Ist das dein Plan? Was hätte das für einen Vorteil?
Du hast im Ping Befehl das Interface angegeben? Oder die Source Adresse? Beim Interface schlägt es natürlich fehl. Das LAN Interface hat keine Verbindung zum WAN. Wenn du nur die Source Adresse setzt, sähe das anders aus, aber dann würde das Paket trotz der source Adresse über das WAN Interface fließen.
Auch das ist normal, denn das Gateway hängt nicht am LAN Interface, und das LAN Interface hat sein eigenes fe80:: Netz.
Macht Sinn, Denkfehler meinerseits. Ist beim IPv4 Lan ja auch nicht anders. Danke. Ich hab jetzt mal meiner VM manuell eine statische IPv6 Adresse verpasst aus dem Zusatzsubnetz mit dem Gateway des LAN-Interfaces (::1 aus dem Zusatzsubnet). Das Interface kommt hoch, allerdings ist bei der Firewall Schluss. Von aussen ist die IP nicht erreichbar (IPv6 Pings sind erlaubt). Das IPv6 Gateway auf der pfsense kann ich von der VM pingen.
EDIT: In der FW selbst tauchen bei der Regel, die IPv6 durchlässt, dann lauter NO_TRAFFIC:NO_TRAFFIC states auf. Für mich sieht das nach einem Routingproblem aus...
Es erscheinen neue Netcup Mitarbeiter im Forum und KB19 hat es nicht vorausgesagt oder erwähnt?!
Weil das bereits whoami0501 gemacht hat 
Von aussen ist die IP nicht erreichbar (IPv6 Pings sind erlaubt).
IPv6 Forwarding (sysctl) und die Firewall Regeln fürs Forwarding sind die Punkte, die ich prüfen würde. Kannst du die Pings mit tcpdump auf dem WAN Interface sehen?
IPv6 Forwarding (sysctl) und die Firewall Regeln fürs Forwarding sind die Punkte, die ich prüfen würde. Kannst du die Pings mit tcpdump auf dem WAN Interface sehen?
Jep, allerdings kommen keine Antworten zurück. Forwarding auf der VM ist aktiviert, oder meintest du jetzt auf der pfsense? Dort ist das imho standardmässig aktiv.
Jep, allerdings kommen keine Antworten zurück.
Dann ist das das sicherste Zeichen, dass das Forwarding nicht funktioniert. Entweder das IP-Forwarding vom Kernel, oder die Firewall blockt. Da wirst du jetzt ran müssen.
Wie sehen die Regeln denn aus? Am besten low-level auf System-Ebene, nicht in der Oberfläche. Es ist nicht sicher, dass da alles angezeigt wird.
Wird vermutlich so sein, ich werd mir das am Wochenende genauer ansehen.
eripek diese Link-Local-Unicast-Adressen sind Teufelswerk;
diese fe80::1 default Gateway, welches wir lt. Anleitung auf unseren vServern eintragen,
ist nicht immer das Selbe;
des kommt im gesamten netcup-Netzwerk x-fach vor; ich würd fast meinen auf jedem Host einmal;
Das ist ja die Idee hinter HSRP und VRRP. Und Du verwechselst, denke ich, gerade ::1 (loopback) mit fe80::1 (beliebige linklokale Adresse, nicht EUI64).
Und ja frank_m linklokale Adressen werden in der Tat von jedem Gerät (mit dem prefix fe80:/10 und der MAC-Adresse selbst erzeugt, wobei ein paar Füllbits dazukommen, was in einer Adresse in fe80::/64 mündet. Sie sind das IPv6-Äquivalent zu APIPA.
In den Anleitungen haben wir früher die Variante der statischen Eintragung bevorzugt, weil es offenbar Probleme mit RA, respektive der Neighbor Lifetime gegeben hat. Was da die Ursache war, habe ich mir nicht gemerkt. Jedenfalls kann man SLAAC aber auch feiner granulieren, als es ganz abzuschalten. Duplicate Address Detection (DAD) sollte man jedenfalls drinnen lassen.
Ich werd das auf einem meiner VPS mal wieder testen.
BTW: Haben wir mal wieder eine Spam-Welle wegen der Microsoft gehäuft seien S3150-Liebenswürdigkeiten der Geiselhaftnahme auf uns niederlässt?
Das ist ja die Idee hinter HSRP und VRRP. Und Du verwechselst, denke ich, gerade ::1 (loopback) mit fe80::1 (beliebige linklokale Adresse, nicht EUI64).
ne ne ich meine schon die fe80::... Adressen;
..., was in einer Adresse in fe80::/64 mündet.
Sie sind das IPv6-Äquivalent zu APIPA.
das APIPA würd ich eher mit SLAAC vergleichen; nicht mit den Link-Lokalen Adressen;
sagte ja die Link-Lokalen Adressen sind Teufelswerk 
Und ja frank_m linklokale Adressen werden in der Tat von jedem Gerät (mit dem prefix fe80:/10 und der MAC-Adresse selbst erzeugt, wobei ein paar Füllbits dazukommen, was in einer Adresse in fe80::/64 mündet. Sie sind das IPv6-Äquivalent zu APIPA.
Ja, ich weiß. Ich mach das auch nicht erst seit gestern. Aber
In den Anleitungen haben wir früher die Variante der statischen Eintragung bevorzugt, weil es offenbar Probleme mit RA, respektive der Neighbor Lifetime gegeben hat. Was da die Ursache war, habe ich mir nicht gemerkt. Jedenfalls kann man SLAAC aber auch feiner granulieren, als es ganz abzuschalten. Duplicate Address Detection (DAD) sollte man jedenfalls drinnen lassen.
Ich werd das auf einem meiner VPS mal wieder testen.
Woraus willst du hinaus? Geht es wirklich noch um die Konfiguration des mitgelieferten /64 auf dem eth0 des VPS? Da kann ich dir versichern: aus der Netcup Infrastruktur kommt diesbezüglich gar nichts. Ich hab kürzlich noch auf einem VPS ein Ubuntu über eine ISO installiert, wo dann die Default Netzwerkkonfiguration auf "Auto" sowohl für IPv4 und IPv6 steht. Eine IPv4 Adresse gibts sofort, bei IPv6 tut sich nichts. Ein tcpdump auf meinem aktuellen VPS zeigt RAs, die aber keine Prefixes verteilen, siehe Screenshot. Ansonsten nur NDP Pakete.
Ja, ich weiß. Ich mach das auch nicht erst seit gestern. Aber
- was hat das mit der Fragestellung zu tun
- warum sollte das Einfluss auf SLAAC im Netcup Netz haben?
Woraus willst du hinaus? Geht es wirklich noch um die Konfiguration des mitgelieferten /64 auf dem eth0 des VPS? Da kann ich dir versichern: aus der Netcup Infrastruktur kommt diesbezüglich gar nichts. Ich hab kürzlich noch auf einem VPS ein Ubuntu über eine ISO installiert, wo dann die Default Netzwerkkonfiguration auf "Auto" sowohl für IPv4 und IPv6 steht. Eine IPv4 Adresse gibts sofort, bei IPv6 tut sich nichts. Ein tcpdump auf meinem aktuellen VPS zeigt RAs, die aber keine Prefixes verteilen, siehe Screenshot. Ansonsten nur NDP Pakete.
pfsense und OPNsense sind meiner Erfahrung nach ein wenig eigen, wenn Du statische Konfigurationen am WAN machst. Im Fall meines DSL-Providers kommt etwa - anders als bei netcup immer ein anderer Gateway zum Zug. Da habe ich mir angewöhnt, dass ich SLAAC fahre, damit das Interface sich einmal stateless konfiguriert und seinen Gateway per RA übernimmt. Den statischen /48er-Präfix trage ich als IP-Alias für WAN oder loopback ein.
Damit habe ich den Prefix, der mir ja aufs WAN geroutet wird und daher nicht selber nochmal announct werden muss, immer statisch auf der Firewall, während ich bei den Gateways den RAs meines Providers vertrauen kann. Und dabei sollte es völlig egal sein, ob es nun um das mitgelieferte, ein zusätzliches oder ein failover prefix geht, solange ich ein router advertisement hinsichtlich des Gateways bekomme.
Und die bekomme ich auch laut
tcpdump -n -i eth0 icmp6
18:24:58.128083 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24
richtiger wäre aber wohl:
tcpdump -n -i eth0 icmp6 and ip6[40] == 134
Yep:
18:26:22.241816 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24
18:28:21.895010 IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 24
Wie geschrieben, verwechsle SLAAC und RA nicht mit DHCPv6. SLAAC weist Dir nicht zwangsläufig ein (Host-)Prefix zu, das ist Aufgabe von einem entsprechend konfigurierten RA und/oder DHCPv6. Siehe https://www.networkacademy.io/…s-autoconfiguration-slaac
Im Fall meines DSL-Providers kommt etwa - anders als bei netcup immer ein anderer Gateway zum Zug.
Ok, wenn das Gateway sich ändert, macht das natürlich Sinn.
Ich bin kurz davor das Thema einfach sein zu lassen.
Konfiguriere ich das Netz statisch über das nicht-VLAN funktioniert alles perfekt, sprich an IPv6 Forwarding kann’s auf der VM nicht liegen, sonst ginge das direkt auch nicht. Ich werd einfach noch etwas Googlen, ob man bei Pfsense vielleicht etwas spezielles machen muss, damit das geht. Beim roten H funktionierts problemlos mit DHCPv6 und im LAN dann einfach das Subnet zugewiesen - tada, feddich.
Konfiguriere ich das Netz statisch über das nicht-VLAN funktioniert alles perfekt, sprich an IPv6 Forwarding kann’s auf der VM nicht liegen, sonst ginge das direkt auch nicht.
Was genau meinst du damit? Nutzt du sonst VLANs?
Ich habe gerade ein gutes Angebot für ein angeblich unbenutztes Fairphone 3+ bekommen.
Hat sich erledigt, ich war sowieso zu langsam. Ist vielleicht eh besser so
Was genau meinst du damit? Nutzt du sonst VLANs?
Die PFsense hängt natürlich zum einen am normalen Uplink und das LAN am Cloud VLAN von Netcup.
Das heisst der Aufbau; VPS mit Pfsense, einmal am WAN Uplink ins Internet, einmal im Cloud VLAN bei Netcup mit dem LAN Port. VM mit Cloud VLAn mit dem Lan der pfsense VM verbunden. Das heisst die VM hat keine öffentliche Netzwerkkarte aktiv. Das zusätzliche Subnet ist auf die Pfsense geroutet, nicht auf den VPS.
Ah, ok. So mach ich das auch für Windows Server. Allerdings mit einer Linux Firewall, nicht mit pfSense. Kommt aber aufs gleiche raus.
doofe Frage: ist es in Stein gemeisselt, wieviele Leerschritte ein Tab in text/plain E-mails bei der Darstellung durch Mailagents entspricht?
ich glaub die Menschheit evolutioniert sich in den Kindergarten
https://geizhals.at/lego-technic-ferrari-488-gte-af-corse-51-42125-a2446545.html
da heißt es ab 18 Jahren 
und wir hatten damals Autos - etwas kleiner, aus einem anderen Material - im Kindergarten
