IPv6 fehlerhaft seit 20.1.7 (PPPoE + Routing?)

[robgnu]

Hallo Zusammen,

seit dem Update auf 20.1.7 habe ich ein neues Problem mit meiner neuen OPNsense:

Clients aus dem VLAN können keine keine stabile IPv6 Verbindung ins Internet aufbauen. Hier die Netzstruktur (grob):

Code: [Select]


     WAN / Internet
            :
            : Telekom (feste IP)
            :
      .-----+-----.
      |  Gateway  |  Vigor 165 Modem (Bridge)
      '-----+-----'
            |
        WAN | IPv4/IPv6 Dualstack PPPoE Einwahl
            |
      .-----+------.
      |  OPNsense  +
      '-----+------'
            |
            | Diverse VLANs (3 Stück); IPv4 Lokal und separate IPv6 Prefixe
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (Clients/Servers)


Es stellt sich wie folgt dar:

- Aus dem VLAN: Ein Ping6 auf das VLAN-Interface der OPNsense funktioniert mit <1ms konstant.

Code: [Select]

$> ping 2003:a:143:1f20::1
PING 2003:a:143:1f20::1(2003:a:143:1f20::1) 56 data bytes
64 bytes from 2003:a:143:1f20::1: icmp_seq=1 ttl=64 time=0.444 ms
^C
--- 2003:a:143:1f20::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.444/0.444/0.444/0.000 ms

- Aus dem VLAN: Ein Ping6 vom VLAN auf das WAN-Interface der OPNsense schlägt fehl:

Code: [Select]

$> ping 2003:a:17f:c31f:20d:b9ff:fe4b:f990
connect: Das Netzwerk ist nicht erreichbar

- Aus dem VLAN: Ein Ping6 auf google.de sieht wie folgt aus: Manchmal gibt es auch längere Phasen von Funktion und Paketverlust:

Code: [Select]

$> ping google.de
PING google.de(fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003)) 56 data bytes
ping: sendmsg: Das Netzwerk ist nicht erreichbar
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=2 ttl=55 time=27.1 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=3 ttl=55 time=26.6 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=4 ttl=55 time=26.8 ms
64 bytes from fra15s16-in-x03.1e100.net (2a00:1450:4001:81b::2003): icmp_seq=5 ttl=55 time=27.4 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 368ms
rtt min/avg/max/mdev = 26.618/27.000/27.416/0.326 ms

Bis vor dem Update lief es einwandfrei. Ich habe auch schon mehrfach das System neu gestartet - leider ohne Erfolg.

Dieses System ist meine erste OPNsense, vorher habe ich einige Jahre mit pfSense gearbeitet (selbe Hardware (APU2C4). Nach der ersten Installation fiel mit auf, dass ich das WAN-Interface der OPNsense von außen nicht erreiche (nur IPV6). Nachdem ich unter "System -> Gateways" das Gateway "WAN_DHCP6" deaktiviert hatte, lief alles einwandfrei. Eine erneute Aktivierung des Gateways führt wieder zur Nichterreichbarkeit der WAN-Schnittstelle. An meinem Problem ändert sich dadurch nichts.

Hat jemand eine Idee oder einen Ratschlag für mich?

Viele Grüße
Robert.

[JeGr]

Kurze Nachfrage dazu:

> Eine erneute Aktivierung des Gateways führt wieder zur Nichterreichbarkeit der WAN-Schnittstelle. An meinem Problem ändert sich dadurch nichts.

Aber eine Regel auf dem WAN, die IP6-ICMP (zumindest echo request) erlaubt auf Ziel "This Firewall" oder "WAN Address" hast du gesetzt? Was sagen denn die Logs dazu, kommt da ein IP6-ICMP überhaupt an oder tauchen die Requests gar nicht auf?

[mimugmail]

Schau mal ob dich das auch betrifft:

https://github.com/opnsense/core/issues/4128

Sollte eigentlich nicht sein aber wer weiß ...

[robgnu]

Hallo, danke für die Antworten. Ich werde die Rückfragen mal kurz beantworten. Vielleicht hat jemand noch eine Idee.

Kurze Nachfrage dazu:

Aber eine Regel auf dem WAN, die IP6-ICMP (zumindest echo request) erlaubt auf Ziel "This Firewall" oder "WAN Address" hast du gesetzt? Was sagen denn die Logs dazu, kommt da ein IP6-ICMP überhaupt an oder tauchen die Requests gar nicht auf?

Ja, ich habe auf dem WAN-Interface eine ICMPv6 Regel, die ANY to ANY jegliche ICMP-Pakete erlaubt.

Schau mal ob dich das auch betrifft:

https://github.com/opnsense/core/issues/4128

Sollte eigentlich nicht sein aber wer weiß ...

So wie ich das sehe, betrifft es bei dem Issue ja nur IPv4 - ich habe ja IPv6 Probleme. Ob das zusammenhängt kann ich aber nicht richtig beurteilen.

[robgnu]

Hallo,

ich habe noch eine kleine Ergänzung: Wenn ich vom VLAN auf das VLAN-Interface der OPNsense pinge, dann bekomme ich ein reply, sobald ich auf ein anderes Interface hinter der OPNsense pinge, bekomme  ich einen Fehler. Dabei ist es egal, ob ich ein anderes VLAN, LAN oder die WAN-Schnittstelle anpinge.

Code: [Select]

C:\Users\Service>ping 2a01:4f8:c2c:898c::1

Ping wird ausgeführt für 2a01:4f8:c2c:898c::1 mit 32 Bytes Daten:
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.

Ping-Statistik für 2a01:4f8:c2c:898c::1:
    Pakete: Gesendet = 2, Empfangen = 0, Verloren = 2
    (100% Verlust),
STRG-C

Über "Interfaces: Diagnostics: Ping" kann ich von allen Interfaces (VLAN, LAN, WAN) ins Internet pingen - ohne Paketverlust. Also scheint es am Routing zu liegen? Vielleicht hängt es auch mit meinem anderen Problem zusammen? https://forum.opnsense.org/index.php?topic=16825.0

Ich habe gerade noch folgende Fehler im Protokoll unter "System: Routes: Log File" gefunden. Das Log ist voll davon...

Code: [Select]

2020-05-27T17:18:25 radvd[41199]: returning from radvd main
2020-05-27T17:18:25 radvd[41199]: removing /var/run/radvd.pid
2020-05-27T17:18:25 radvd[41199]: sending stop adverts
2020-05-27T17:18:25 radvd[41199]: exiting, 1 sigterm(s) received
2020-05-27T17:18:23 radvd[25347]: version 2.18 started
2020-05-27T17:18:23 radvd[15197]: returning from radvd main
2020-05-27T17:18:23 radvd[15197]: removing /var/run/radvd.pid
2020-05-27T17:18:23 radvd[15197]: sending stop adverts
2020-05-27T17:18:23 radvd[15197]: exiting, 1 sigterm(s) received
2020-05-27T17:18:21 radvd[77040]: version 2.18 started
2020-05-27T17:18:21 radvd[34586]: returning from radvd main
2020-05-27T17:18:21 radvd[34586]: removing /var/run/radvd.pid
2020-05-27T17:18:20 radvd[34586]: sending stop adverts
2020-05-27T17:18:20 radvd[34586]: exiting, 1 sigterm(s) received
2020-05-27T17:18:18 radvd[75001]: version 2.18 started

Gruß
Robert.

[robgnu]

Hallo,

heute Vormittag hatte ich ein wenig Zeit um dem Problem auf die Sprünge zu kommen. Leider ohne Erfolg. Hier aber meine Schritte, die ich versucht habe. Falls jemand eine Idee hat, wäre ich dankbar.

1. Sicherung der Config erstellt.
2. Neuinstallation 20.1.0 (Image) > Config eingespielt > Problem besteht weiterhin.
2. Update auf 20.1.7 > Problem besteht weiterhin > Update auf 20.7_Beta über die GUI > Problem besteht weiterhin.
3. Neuinstallation 20.7_BETA inkl. FreeBSD 12.1 > Config eingespielt > Problem besteht weiterhin.
4. Update auf 20.7._BETA (aktueller Stand von heute) > Problem besteht weiterhin.
5. BIOS Update der APU2 auf aktuelle Version > Problem besteht weiterhin.
6. Neuinstallation 20.1.0 > Config eingespielt > Update auf 20.1.7 > Problem besteht weiterhin.

Ich bin also nicht wirklich weiter gekommen. Ich habe dann noch ein wenig mit dem Wireshark gelauscht und habe folgendes festgestellt:
- Ca. alle 1-2 Sekunden werden Router Advertisements gesendet. Die Ursache ist unklar, hängt aber vielleicht mit dem Dienst (siehe vorheriger Post) zusammen.
- Wenn ich vom LAN oder VLAN in Richtung WAN pinge, erhalte ich öfters eine Fehlermeldung sobald der Ping mit dem Router Advertisement zusammenfällt.

Ich scheue eine Neuinstallation, da ich die OPNsense erst vor wenigen Wochen eingerichtet habe und seit Anfang an läuft IPv6 nicht optimal. Ich möchte auch nicht so gerne zur pfSense zurück - die haben ja auch ihre Probleme...

Gruß
Robert.

[robgnu]

Hallo Zusammen,

gestern Abend habe ich mich nochmal in die OPNsense eingeloggt um dem Fehler auf die Spur zu kommen. Seit dem Update auf 20.1.7 habe ich bei meiner PPPoE Verbindung mit IPv6 Probleme, zuvor lief es. Leider bin ich nicht sicher, ob das Problem durch das Update nur getriggert wurde, oder ob es erst dazu gekommen ist.

Folgender Log-Block erscheint alle 2-3 Sekunden im system.log ("clog -f /var/log/system.log"). In einer anderen pfSense Installation habe ich eine solche Flut nicht. Die Load der APU steht auch bei 1, was im Leerlauf nicht ok ist...

Code: [Select]

May 28 19:31:12 sense dhcp6c[67533]: script "/var/etc/dhcp6c_wan_script.sh" terminated
May 28 19:31:12 sense dhcp6c[67533]: removing an event on pppoe0, state=REQUEST
May 28 19:31:12 sense dhcp6c[67533]: removing server (ID: 00:02:00:00:05:83:34:30:3a:37:31:3a:38:33:3a:61:38:3a:63:38:3a:30:30:00:00:00)
May 28 19:31:12 sense dhcp6c[67533]: got an expected reply, sleeping.
May 28 19:31:12 sense dhcp6c[67533]: Sending Solicit
May 28 19:31:12 sense dhcp6c[67533]: a new XID (15754b) is generated
May 28 19:31:12 sense dhcp6c[67533]: set client ID (len 14)
May 28 19:31:12 sense dhcp6c[67533]: set identity association
May 28 19:31:12 sense dhcp6c[67533]: set elapsed time (len 2)
May 28 19:31:12 sense dhcp6c[67533]: set option request (len 4)
May 28 19:31:12 sense dhcp6c[67533]: send solicit to ff02::1:2%pppoe0
May 28 19:31:12 sense dhcp6c[67533]: reset a timer on pppoe0, state=SOLICIT, timeo=0, retrans=1016
May 28 19:31:12 sense dhcp6c[67533]: receive advertise from fe80::200:ff:fe00:0%pppoe0 on pppoe0
May 28 19:31:12 sense dhcp6c[67533]: get DHCP option client ID, len 14
May 28 19:31:12 sense dhcp6c[67533]:   DUID: 00:01:00:01:21:39:d6:87:00:0d:b9:54:2b:6c
May 28 19:31:12 sense dhcp6c[67533]: get DHCP option server ID, len 26
May 28 19:31:12 sense dhcp6c[67533]:   DUID: 00:02:00:00:05:83:34:30:3a:37:31:3a:38:33:3a:61:38:3a:63:38:3a:30:30:00:00:00
May 28 19:31:12 sense dhcp6c[67533]: get DHCP option identity association, len 59
May 28 19:31:12 sense dhcp6c[67533]:   IA_NA: ID=0, T1=0, T2=0
May 28 19:31:12 sense dhcp6c[67533]: get DHCP option status code, len 43
May 28 19:31:12 sense dhcp6c[67533]:   status code: no addresses
May 28 19:31:12 sense dhcp6c[67533]: get DHCP option DNS, len 32
May 28 19:31:12 sense dhcp6c[67533]: server ID: 00:02:00:00:05:83:34:30:3a:37:31:3a:38:33:3a:61:38:3a:63:38:3a:30:30:00:00:00, pref=-1
May 28 19:31:12 sense dhcp6c[67533]: reset timer for pppoe0 to 0.979450
May 28 19:31:13 sense dhcp6c[67533]: picked a server (ID: 00:02:00:00:05:83:34:30:3a:37:31:3a:38:33:3a:61:38:3a:63:38:3a:30:30:00:00:00)
May 28 19:31:13 sense dhcp6c[67533]: Sending Request
May 28 19:31:13 sense dhcp6c[67533]: a new XID (ac85ba) is generated
May 28 19:31:13 sense dhcp6c[67533]: set client ID (len 14)
May 28 19:31:13 sense dhcp6c[67533]: set server ID (len 26)
May 28 19:31:13 sense dhcp6c[67533]: set status code
May 28 19:31:13 sense dhcp6c[67533]: set identity association
May 28 19:31:13 sense dhcp6c[67533]: set elapsed time (len 2)
May 28 19:31:13 sense dhcp6c[67533]: set option request (len 4)
May 28 19:31:13 sense dhcp6c[67533]: send request to ff02::1:2%pppoe0
May 28 19:31:13 sense dhcp6c[67533]: reset a timer on pppoe0, state=REQUEST, timeo=0, retrans=1059
May 28 19:31:13 sense dhcp6c[67533]: receive reply from fe80::200:ff:fe00:0%pppoe0 on pppoe0
May 28 19:31:13 sense dhcp6c[67533]: get DHCP option client ID, len 14
May 28 19:31:13 sense dhcp6c[67533]:   DUID: 00:01:00:01:21:39:d6:87:00:0d:b9:54:2b:6c
May 28 19:31:13 sense dhcp6c[67533]: get DHCP option server ID, len 26
May 28 19:31:13 sense dhcp6c[67533]:   DUID: 00:02:00:00:05:83:34:30:3a:37:31:3a:38:33:3a:61:38:3a:63:38:3a:30:30:00:00:00
May 28 19:31:13 sense dhcp6c[67533]: get DHCP option identity association, len 59
May 28 19:31:13 sense dhcp6c[67533]:   IA_NA: ID=0, T1=0, T2=0
May 28 19:31:13 sense dhcp6c[67533]: get DHCP option status code, len 43
May 28 19:31:13 sense dhcp6c[67533]:   status code: no addresses
May 28 19:31:13 sense dhcp6c[67533]: get DHCP option DNS, len 32
May 28 19:31:13 sense dhcp6c[67533]: Received REPLY for REQUEST
May 28 19:31:13 sense dhcp6c[67533]: nameserver[0] 2003:180:2:7000::53
May 28 19:31:13 sense dhcp6c[67533]: nameserver[1] 2003:180:2:9000::53
May 28 19:31:13 sense dhcp6c[67533]: make an IA: NA-0
May 28 19:31:13 sense dhcp6c[67533]: status code for NA-0: no addresses
May 28 19:31:13 sense dhcp6c[67533]: IA NA-0 is invalidated
May 28 19:31:13 sense dhcp6c[67533]: remove an IA: NA-0
May 28 19:31:13 sense dhcp6c[67533]: reset a timer on pppoe0, state=INIT, timeo=0, retrans=113
May 28 19:31:13 sense dhcp6c[67533]: executes /var/etc/dhcp6c_wan_script.sh
May 28 19:31:13 sense dhcp6c: dhcp6c REQUEST on pppoe0 - running newipv6
May 28 19:31:14 sense opnsense: /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
May 28 19:31:14 sense opnsense: /usr/local/etc/rc.newwanipv6: On (IP address: 2003:a:xxxx:xxxx:20d:b9ff:fe54:2b6c) (interface: WAN[wan]) (real interface: pppoe0).

Unter System -> Log Files -> Backend sieht es so aus:

Code: [Select]

2020-05-29T04:43:52 configd.py: [cacb795f-24af-4173-a656-aa7fa6a1838c] New IPv6 on pppoe0
2020-05-29T04:43:49 configd.py: [1fe23ce9-8fb7-4bdd-9340-57c58a814a6e] New IPv6 on pppoe0
2020-05-29T04:43:47 configd.py: [b54d8ffd-4291-495f-bcd0-100027878dce] New IPv6 on pppoe0
2020-05-29T04:43:44 configd.py: [8a9db60e-0f1c-4e86-ba4f-983126c2ee97] New IPv6 on pppoe0
2020-05-29T04:43:42 configd.py: [f1b8d1a1-f2af-4dd5-bfc8-31893bdbabf4] New IPv6 on pppoe0

Da ich hier eine Static-IP von der DTAG habe, stimmt doch etwas nicht. Ich brauche hier leider echt Hilfe und verzweifle so langsam....

Gruß
Robert

[mimugmail]

Welche Version lief davor sauber?

[Droppie391]

bei uns haben wir keine Probleme mit diese Version und PPPoE. Auch in den Log-Files finden wir solche Einträge nicht. Die default (ausgeblendete) ICMPv6 Freigabe-Regeln sind (neu?) unter Floating zu finden. Vage errinnere ich mich, dass sie in frühere Versionen auf die jeweilige Schnittstellen zu finden waren, kann mich aber täuschen...

Kann es sein, dass deine manuell eingetragene Regeln mit den defaults von OPNsense kollidieren?

[robgnu]

Hallo,

ich war heute in der Lage das Problem zu lösen. Die Ursache war einfacher und unkomplizierter als ich dachte.

Die Lösung: Bei der PPPoE Konfiguration / DHCPv6-Client im WAN war der Haken "Request only an IPv6 prefix" nicht gesetzt. Offenbar hat sich hier etwas bei der Version 20.1.6 zu 20.1.7 geändert, denn vor dem Update lief alles einwandfrei und auch die pfSense habe ich zuvor einwandfrei mit dieser Einstellung betrieben. Nun ist das Häkchen raus und alles läuft wie geschmiert.

Ein Dank trotzdem an alle, die versucht haben mir zu helfen. Ich werde das nächste mal etwas strukturierter vorgehen.

Gruß
Robert.

[mimugmail]

Cool, schreib doch Mal im Howto Forum einen Guide mit paar Screenshots, dann festigt sich dein Wissen und andere profitieren auch

[franco]

Hallöchen,

> "Request only an IPv6 prefix" [...] Offenbar hat sich hier etwas bei der Version 20.1.6 zu 20.1.7 geändert

Ist eher unwahrscheinlich. Wir haben vermehrt Problemmeldungen wenn der Kernel gewechselt wird, was zu Reboots führt die dann solche Probleme triggern, weil das DHCP(v6) dann "aus dem Kalten" erneuert werden muss. Und das wohl bemerkt wenn keine relevanten Änderungen am Interface Code vorgenommen werden.


Grüsse
Franco