Hallo zusammen!
Bin Appliance neuling und nutze seit ein paar Monaten das OPNsense System - bisher auch sehr Happy!
Aber, seit ein paar Tagen (oder Wochen?) tut das IPv6 router advertisement nicht mehr im LAN.
Zuerst ist es gar nicht aufgefallen, aber jetzt bekomme ich es trotz X facher Neukonfiguration der LAN/WAN/PPPoE-Schnittstelle und sogar wechseln der Hardware nicht mehr hin das es überhaupt tut.
Es ist ein 1und1/DTAG Anschluss mit Dual-Stack, ergo dyn. IPv4 und einer IPv6-Adresse mit separater PD.
Am WAN-Interface ist alles gut, alle Daten sind da, aber über das Tracking am LAN-Interface (DHCPv6) tut sich nichts mehr im LAN. Auch gut möglich das es sich mit den letzten Updates eingeschlichen hat.
Hatte schon mehrfach die Konfiguration aller Interfaces entfernt und neu angelegt, zig varianten aus dutzenden Foren-Einträgen der letzten 10 Jahre getestet und auch Rollbacks auf 3-4 Versionen zurück versucht, aber am IPv6 im LAN tut sich überhaupt nichts mehr - bin ratlos. Auch eine ähnliche Konfiguration auf einer anderen Hardware tut nicht.
Vielleicht hat jemand einen Tipp!
VG
Läuft der radvd? Und sicherheitshalber mal in die /var/etc/radvd.conf schauen, ob die LAN-Interfaces drinstehen und mit den richtigen Prefixen versorgt sind.
Vllt. https://github.com/opnsense/core/issues/6962 -- da wird noch nach der Ursache gesucht, aber PPPoE ist definitiv der gemeinsame Nenner.
Grüsse
Franco
Hi!
Dem radvd gehts aus meiner Sicht gut gut, Dienst läuft,siehe Conf.
root 42030 0.0 0.0 12696 2432 - Is 04:02 0:00.07 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var
# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface igc0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1492;
AdvDefaultPreference medium;
AdvManagedFlag off;
AdvOtherConfigFlag on;
prefix 2003:da:XXXX:6f00::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2003:da:XXXX:6f00:2f0:cbff:fefe:c242 {
};
DNSSL lan {
};
};
Beim WAN Interface, denke ich, passt auch alles. Also würde es nicht mit dem Issue passen, siehe Bild.
VG
Ok sieht gut aus... und was sagt "ifconfig igc0" ?
Grüsse
Franco
Hai!
Sieht so aus:
root@fw2:~ # ifconfig igc0
igc0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN (lan)
options=4e0202b<RXCSUM,TXCSUM,VLAN_MTU,JUMBO_MTU,WOL_MAGIC,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
ether 00:f0:cb:fe:c2:42
inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255
inet6 fe80::2f0:cbff:fefe:c242%igc0 prefixlen 64 scopeid 0x1
inet6 2003:da:XXXX:2e00:2f0:cbff:fefe:c242 prefixlen 64
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
VG
Sieht auch gut aus. Weiss nicht so recht... Clients haben kein IPv6? Einfacher Test ist https://test-ipv6.com/ öffnen.
Grüsse
Franco
Leider nicht,
Egal ob Mobiltelefon oder verschiedene PCs.
Manuelles anfordern endet immer im Timeout.
Gefühlt gehen gar keine Pakete an der FW für RA ins LAN..
Müsste es genauer debuggen, aber macht letztendlich keinen Unterschied.
Ich spiele es gleich mal frisch auf eine zweite HW und lasse alles soweit Standard wie es geht.
VG
Mit einem Linux-Client kann man mit radvdump die RAs checken, nicht, dass die nicht ankommen wegen Firewall-Regeln o.ä.
Ich würde mir auch die Routen und den DNS of den Clients ansehen. Ich selbst verwende immer "assisted" in den Einstellungen, lasse aber den DHCPv6 nicht laufen. DNS verteile ich nur per IPv4, daher sieht die resultierende radvd.conf bei mir so aus:
# Automatically generated, do not edit
# Generated RADVD config for manual assignment on opt7
interface ax0_vlan4 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1492;
AdvDefaultPreference medium;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix 2001:xxxx:49e:yyyy::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
};
Irgend etwas anderes am Netzwerk umgebaut, neuer Switch oder so? RAs werden gerne mal aus Sicherheitsgründen geblockt. Ansonsten die üblichen Diagnose-Schritte: Packet Capture und nach Router Solicitations und Advertisements schauen.
@meyergru Die korrekte RA-Einstellung bei deaktiviertem DHCPv6-Server ist "Unmanaged".
Grüße
Maurice
Das weiß ich. Manchmal brauche ich aber DHCPv6 und es läuft auch ohne.
Ohh man, dass ist mir jetzt peinlich ;D
Hatte vor Wochen das "drop unknown multicast" auf einem Switch aktiv genommen.
Vorhin deaktiviert -> keine Änderung.. Darauf hin dem Switch ein Factory-Reset spendiert - tut!
Also ich bin mir noch nicht sicher was "normales" "unknown multicast" damit zu tun hat da sich das ja idr. auf IPv4 bezieht, aber dass hat wohl gegriffen. Wenn ich wieder an den Switch komme schaue ich mal nach dem exakten Wortlaut und schlage in der Doku nach. (Ich meine, eigentlich dürfte es keinen Einfluss darauf haben - aber ich lasse mich gerne belehren).
VG und trotzdem Danke! :D War sehr hilfreich!!
Router Solicitations und auch die meisten Router Advertisements sind Multicasts. Was genau dein Switch unter "unknown" Multicast versteht wirst Du in der Tat mal nachschlagen müssen. Viele Switches haben aber Features, um RAs zu filtern, um zu verhindern, dass ein rogue device den ganzen Traffic an sich zieht.
Moin.
Ich klink mich mal hier mit ein.
Ich habe in etwa den gleichen Fehler.
Mein ISP macht seit ein paar Wochen auch DHCPv6 am WAN Interface (also vollen Dual-Stack).
Also hab ich mich die Woche hingesetzt und die Einrichtung begonnen.
Ich bekomme bei allen Clients eine IPv6 Adresse (auch mit der Aufteilung auf mehrere internen Netze).
Am Anfang alles schön aber nach etwa 4 Stunden (geschätzt), hat kein Client mehr eine IPv6 Adresse.
Der RA Dienst läuft...
Ich habe nun schon versucht nach und nach alle Dienste neu zu starten > kein Erfolg.
Gehe ich aber auf die CLI und sage mit dem Menüpunkt 11 (Reload all services) > läuft alles wieder rund.
Bis zum nächsten Ausfall.
Meine Switche / APs sind alles Mikrotik und da ist in der Konfiguration 'Firewall disabled', 'IPv6 forward' und 'Accept Router Advertisements' aktiviert.