Messages

Upgrade from 23.1.7_3 to 23.1.8 appeared to be stuck at:

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 23.1.7_3 at Thu May 25 15:04:32 CEST 2023
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (82 candidates): .......... done
Processing candidates (82 candidates): .... done
The following 33 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
py39-tzdata: 2023.3_1

Installed packages to be UPGRADED:
ca_root_nss: 3.89 -> 3.89.1
crowdsec: 1.4.6_2 -> 1.5.1
crowdsec-firewall-bouncer: 0.0.23.r2_12 -> 0.0.27
curl: 8.0.1 -> 8.1.0
dhcp6c: 20200512_1 -> 20230523
easy-rsa: 3.1.2 -> 3.1.3
lighttpd: 1.4.69 -> 1.4.70
mpd5: 5.9_14 -> 5.9_16
nss: 3.89 -> 3.89.1
openvpn: 2.6.3 -> 2.6.4
opnsense: 23.1.7_3 -> 23.1.8
opnsense-update: 23.1.6 -> 23.1.8
os-crowdsec: 1.0.4 -> 1.0.5
php81: 8.1.18 -> 8.1.19
php81-ctype: 8.1.18 -> 8.1.19
php81-curl: 8.1.18 -> 8.1.19
php81-dom: 8.1.18 -> 8.1.19
php81-filter: 8.1.18 -> 8.1.19
php81-gettext: 8.1.18 -> 8.1.19
php81-ldap: 8.1.18 -> 8.1.19
php81-mbstring: 8.1.18 -> 8.1.19
php81-pdo: 8.1.18 -> 8.1.19
php81-session: 8.1.18 -> 8.1.19
php81-simplexml: 8.1.18 -> 8.1.19
php81-sockets: 8.1.18 -> 8.1.19
php81-sqlite3: 8.1.18 -> 8.1.19
php81-xml: 8.1.18 -> 8.1.19
php81-zlib: 8.1.18 -> 8.1.19
py39-numpy: 1.24.1_1,1 -> 1.24.1_4,1
py39-pandas: 1.5.3_1,1 -> 2.0.1_1,1
py39-requests: 2.29.0 -> 2.30.0
suricata: 6.0.11_1 -> 6.0.12

Number of packages to be installed: 1
Number of packages to be upgraded: 32

The process will require 31 MiB more space.
71 MiB to be downloaded.
[1/33] Fetching php81-sqlite3-8.1.19.pkg: ... done
[2/33] Fetching php81-sockets-8.1.19.pkg: ..... done
[3/33] Fetching lighttpd-1.4.70.pkg: .......... done
[4/33] Fetching opnsense-update-23.1.8.pkg: ..... done
[5/33] Fetching os-crowdsec-1.0.5.pkg: ... done
[6/33] Fetching nss-3.89.1.pkg: .......... done
[7/33] Fetching py39-numpy-1.24.1_4,1.pkg: .......... done
[8/33] Fetching easy-rsa-3.1.3.pkg: ....... done
[9/33] Fetching crowdsec-1.5.1.pkg: .......... done
[10/33] Fetching openvpn-2.6.4.pkg: .......... done
[11/33] Fetching php81-filter-8.1.19.pkg: ... done
[12/33] Fetching php81-8.1.19.pkg: .......... done
[13/33] Fetching py39-pandas-2.0.1_1,1.pkg: .......... done
[14/33] Fetching dhcp6c-20230523.pkg: ......... done
[15/33] Fetching py39-requests-2.30.0.pkg: .......... done
[16/33] Fetching crowdsec-firewall-bouncer-0.0.27.pkg: .......... done
[17/33] Fetching py39-tzdata-2023.3_1.pkg: .......... done
[18/33] Fetching ca_root_nss-3.89.1.pkg: .......... done
[19/33] Fetching php81-ctype-8.1.19.pkg: . done
[20/33] Fetching php81-simplexml-8.1.19.pkg: ... done
[21/33] Fetching php81-session-8.1.19.pkg: ..... done
[22/33] Fetching curl-8.1.0.pkg: .......... done
[23/33] Fetching php81-zlib-8.1.19.pkg: ... done
[24/33] Fetching php81-dom-8.1.19.pkg: ........ done
[25/33] Fetching suricata-6.0.12.pkg: .......... done
[26/33] Fetching mpd5-5.9_16.pkg: .......... done
[27/33] Fetching php81-ldap-8.1.19.pkg: ..... done
[28/33] Fetching php81-xml-8.1.19.pkg: ... done
[29/33] Fetching php81-pdo-8.1.19.pkg: ....... done
[30/33] Fetching php81-curl-8.1.19.pkg: ..... done
[31/33] Fetching php81-mbstring-8.1.19.pkg: .......... done
[32/33] Fetching opnsense-23.1.8.pkg: .......... done
[33/33] Fetching php81-gettext-8.1.19.pkg: . done
Checking integrity... done (0 conflicting)
[1/33] Upgrading py39-numpy from 1.24.1_1,1 to 1.24.1_4,1...
[1/33] Extracting py39-numpy-1.24.1_4,1: .......... done
[2/33] Upgrading php81 from 8.1.18 to 8.1.19...
[2/33] Extracting php81-8.1.19: .......... done
[3/33] Installing py39-tzdata-2023.3_1...
[3/33] Extracting py39-tzdata-2023.3_1: .......... done
[4/33] Upgrading ca_root_nss from 3.89 to 3.89.1...
[4/33] Extracting ca_root_nss-3.89.1: ...... done
[5/33] Upgrading nss from 3.89 to 3.89.1...
[5/33] Extracting nss-3.89.1: .......... done
[6/33] Upgrading easy-rsa from 3.1.2 to 3.1.3...
[6/33] Extracting easy-rsa-3.1.3: .......... done
[7/33] Upgrading py39-pandas from 1.5.3_1,1 to 2.0.1_1,1...
[7/33] Extracting py39-pandas-2.0.1_1,1: .......... done
[8/33] Upgrading crowdsec-firewall-bouncer from 0.0.23.r2_12 to 0.0.27...
[8/33] Extracting crowdsec-firewall-bouncer-0.0.27: ...... done
crowdsec_firewall is running as pid 39371.
Stopping crowdsec_firewall.
Waiting for PIDS: 39371.
[9/33] Upgrading php81-session from 8.1.18 to 8.1.19...
[9/33] Extracting php81-session-8.1.19: .......... done
[10/33] Upgrading curl from 8.0.1 to 8.1.0...
[10/33] Extracting curl-8.1.0: .......... done
[11/33] Upgrading php81-pdo from 8.1.18 to 8.1.19...
[11/33] Extracting php81-pdo-8.1.19: .......... done
[12/33] Upgrading php81-mbstring from 8.1.18 to 8.1.19...
[12/33] Extracting php81-mbstring-8.1.19: .......... done
[13/33] Upgrading php81-sqlite3 from 8.1.18 to 8.1.19...
[13/33] Extracting php81-sqlite3-8.1.19: ......... done
[14/33] Upgrading php81-sockets from 8.1.18 to 8.1.19...
[14/33] Extracting php81-sockets-8.1.19: .......... done
[15/33] Upgrading lighttpd from 1.4.69 to 1.4.70...
===> Creating groups.
Using existing group 'www'.
===> Creating users
Using existing user 'www'.
[15/33] Extracting lighttpd-1.4.70: .......... done
[16/33] Upgrading opnsense-update from 23.1.6 to 23.1.8...
[16/33] Extracting opnsense-update-23.1.8: .......... done
[17/33] Upgrading crowdsec from 1.4.6_2 to 1.5.1...
[17/33] Extracting crowdsec-1.5.1: .......... done
crowdsec is running as pid 66369.
Stopping crowdsec.
Waiting for PIDS: 66369.
[18/33] Upgrading openvpn from 2.6.3 to 2.6.4...
===> Creating groups.
Using existing group 'openvpn'.
===> Creating users
Using existing user 'openvpn'.
[18/33] Extracting openvpn-2.6.4: .......... done
[19/33] Upgrading php81-filter from 8.1.18 to 8.1.19...
[19/33] Extracting php81-filter-8.1.19: ......... done
[20/33] Upgrading dhcp6c from 20200512_1 to 20230523...
[20/33] Extracting dhcp6c-20230523: ........ done
[21/33] Upgrading py39-requests from 2.29.0 to 2.30.0...
[21/33] Extracting py39-requests-2.30.0: .......... done
[22/33] Upgrading php81-ctype from 8.1.18 to 8.1.19...
[22/33] Extracting php81-ctype-8.1.19: ........ done
[23/33] Upgrading php81-simplexml from 8.1.18 to 8.1.19...
[23/33] Extracting php81-simplexml-8.1.19: ......... done
[24/33] Upgrading php81-zlib from 8.1.18 to 8.1.19...
[24/33] Extracting php81-zlib-8.1.19: ........ done
[25/33] Upgrading php81-dom from 8.1.18 to 8.1.19...
[25/33] Extracting php81-dom-8.1.19: .......... done
[26/33] Upgrading suricata from 6.0.11_1 to 6.0.12...
[26/33] Extracting suricata-6.0.12: .......... done
[27/33] Upgrading mpd5 from 5.9_14 to 5.9_16...
[27/33] Extracting mpd5-5.9_16: .......... done
[28/33] Upgrading php81-ldap from 8.1.18 to 8.1.19...
[28/33] Extracting php81-ldap-8.1.19: ........ done
[29/33] Upgrading php81-xml from 8.1.18 to 8.1.19...
[29/33] Extracting php81-xml-8.1.19: ......... done
[30/33] Upgrading php81-curl from 8.1.18 to 8.1.19...
[30/33] Extracting php81-curl-8.1.19: .......... done
[31/33] Upgrading php81-gettext from 8.1.18 to 8.1.19...
[31/33] Extracting php81-gettext-8.1.19: ........ done
[32/33] Upgrading os-crowdsec from 1.0.4 to 1.0.5...
[32/33] Extracting os-crowdsec-1.0.5: .......... done

I checked my crowdsec processes:

Code Select Expand

root@opnsense01:~ # ps aux | grep crowdsec
root    43578   0.0  0.0   13504   2768  -  I    15:05       0:00.00 /bin/sh -c set -- os-crowdsec-1.0.4\n#!/bin/sh\n\n# need to temporarily stop the bouncer to remove all the rules\nservice crowdsec_firewall stop >/dev/nul
root    43757   0.0  0.0   13504   3140  -  I    15:05       0:00.01 /bin/sh /usr/local/etc/rc.d/crowdsec_firewall stop
root    88726   0.0  0.7  914324 121868  -  I    15:04       0:03.12 /usr/local/bin/crowdsec -c /usr/local/etc/crowdsec/config.yaml
root    90891   0.0  0.2  722256  28864  -  I    15:04       0:00.19 /usr/local/bin/crowdsec-firewall-bouncer -c /usr/local/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml (crowdsec-firewall-b)


and manually did a 'kill -9 90891' after which the update immediately proceeded and finished successfully.

"Have you tried turning it off and on again?"
Just got it solved by restarting my modem. Sorry for the noise.

That command shows "ls: No match.".
I have a igc0_router file containing the IP4 gateway only.

Not sure when this started but my WAN_DHCP6 gateway appears to not get configured correctly:

My WAN is configured with DHCPv6 and I set a Prefix delegation size of 59 in its options.
Interface Overview shows an address (/128), a link-local address (/64), a delegated prefix (/59) and 2 IPv6 DNS servers but no IPv6 gateway.

The "IP address" field in the default created WAN_DHCP6 gateway is set to "dynamic" but the gateway field stays empty.

The log file shows the following:

Code Select Expand


/system_gateways.php: ROUTING: not a valid default gateway address: ''
/system_gateways.php: ROUTING: configuring inet6 default gateway on wan


Not sure if this is an issue with my ISP (Vodafone Cable Germany) who did some non-standard IPv6 in the past.

For now I check my WAN's neighbors via NDP and use the listed CMTS IP (fe80:...) as a manually added IPv6 gateway which works but I am wondering why it is not detected/used by DHCP6.

Any suggestions how to better debug this? Thank you.

I think this is the issue I ran into:

My WAN_DHCP6 gateway was empty. netstat showed no default ipv6 route. I get a /59 prefix from my ISP and set one /64 for LAN and one /64 for WLAN.

My workaround is looking at the NDP table, taking the gateway's link local IP from WAN and manually adding an IPv6 gateway using that (and disabling the auto created one).

Auf der Suche nach einer Lösung bin ich über diesen Thread gestolpert. Da ich auch sonst nichts gefunden habe, habe ich das Folgende geschrieben:

Das folgende Skript überprüft, ob sich die öffentliche IPv4 (des Standardgateways) oder das IPv6 Prefix geändert hat und verschickt in diesem Fall eine Email:
(/tmp/igc0_prefixv6 anpassen auf die richtige Datei/Interface)

Code Select Expand


mkdir /usr/local/custom_scripts
vi /usr/local/custom_scripts/checknewip.sh

#!/bin/sh

CURRENT_IP=`curl -s https://ipv4.icanhazip.com/`
OLD_IP="${CURRENT_IP}"
CURRENT_PREFIX=$(cat /tmp/igc0_prefixv6)
OLD_PREFIX="${CURRENT_PREFIX}"

WORKDIR="/usr/local/custom_scripts"
cd "${WORKDIR}"

SUBJECT="opnsense01 - new ip detected"
CHANGED=0

echo "current ip: ${CURRENT_IP}"
if [ -f "${WORKDIR}/old_ip.txt" ]; then
  echo "old_ip.txt found"
  OLD_IP=$(cat "${WORKDIR}/old_ip.txt")
else
  echo "no old_ip.txt found"
  echo "${CURRENT_IP}" > "${WORKDIR}/old_ip.txt"
fi
echo "old ip: ${OLD_IP}"

if [ "${OLD_IP}" != "${CURRENT_IP}" ]; then
  CHANGED=1
  echo "ip changed"
  echo "${CURRENT_IP}" > "${WORKDIR}/old_ip.txt"
fi

echo "current prefix: ${CURRENT_PREFIX}"
if [ -f "${WORKDIR}/old_prefix.txt" ]; then
  echo "old_prefix.txt found"
  OLD_PREFIX=$(cat "${WORKDIR}/old_prefix.txt")
else
  echo "no old_prefix.txt found"
  echo "${CURRENT_PREFIX}" > "${WORKDIR}/old_prefix.txt"
fi
echo "old prefix: ${OLD_PREFIX}"

if [ "${OLD_PREFIX}" != "${CURRENT_PREFIX}" ]; then
  CHANGED=1
  echo "prefix changed"
  echo "${CURRENT_PREFIX}" > "${WORKDIR}/old_prefix.txt"
fi

MSG="old ip: ${OLD_IP}
new ip: ${CURRENT_IP}

old prefix: ${OLD_PREFIX}
new prefix: ${CURRENT_PREFIX}"

if [ "${CHANGED}" == 1 ]; then
  "${WORKDIR}"/mailsender.py "${SUBJECT}" "${MSG}"
fi

exit 0


Das Python Skript zum Versenden der Email:

Code Select Expand


vi /usr/local/custom_scripts/mailsender.py

#!/usr/local/bin/python3

import smtplib
from email.message import EmailMessage
from email.utils import localtime
import sys

msg = EmailMessage()
msg.set_content(sys.argv[2])
msg['Subject'] = sys.argv[1]
msg['From'] = 'from@mailserver.xy'
msg['To'] = 'to@mailserver.xy'
msg['Date'] = localtime()

server = smtplib.SMTP('mailserver.xy', 25)
server.ehlo()
server.starttls()
server.ehlo()
server.login('from@mailserver.xy', 'mailpassword')
server.send_message(msg)
server.quit()


Dann noch für das OPNsense WebGUI einen Eintrag für die "Command"-Auswahl unter System->Settings->Cron anlegen:

Code Select Expand


vi /usr/local/opnsense/service/conf/actions.d/actions_own_checknewip.conf

[checknewip]
command:/usr/local/custom_scripts/checknewip.sh
parameters:
type:script
message:checking if ip4 or ip6 prefix has changed
description:check if ip4 or ip6 prefix has changed

und ein "service configd restart" durchführen, damit der neue Eintrag auch als Auswahl erscheint.

Dann einen neuen Cronjob angelegt mit "*/5" bei den Minuten (alle 5 Minuten ausführen) und als command "check if ip4 or ip6 prefix has changed". Description irgendwas eintragen (erforderlich).

Das Skript werde ich noch erweitern auf eine IPv4 / IPv6 Regex Üperprüfung und dann per API noch meine DNS Einträge bei OVH aktualisieren.

Hoffe das hilft jemandem.

Vodafone in Germany has been doing the same thing since ~2022-04.

Code Select Expand

em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        options=481059b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,NOMAP>
        ether ab:cd:ef:12:34:56
        inet6 fe80::x%em0 prefixlen 64 scopeid 0x1
        inet6 2a02:908::x prefixlen 64 autoconf
        inet6 2a02:3102::x prefixlen 64 detached autoconf
        inet6 2a02:3102::x prefixlen 64 autoconf
        inet6 2a02:908::x prefixlen 128
        inet 84.119.xxx.xxx netmask 0xfffffc00 broadcast 84.119.171.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

The /64 autoconf IPs are not routed only the /128 works as a source. Clients using dhcp6 delegated prefixes work fine but local ipv6 requests from opnsense fail.
Currently I use a cronjob based on https://blog.veloc1ty.de/2021/02/28/opnsense-prefer-source-address/ to set the working address as prefer_source:

Code Select Expand


#!/bin/sh

INTERFACE=$(ifconfig | grep -B1 'description: WAN' | head -n1 | cut -w -f 1 | tr -d ':,')
IPv6=$(ifconfig "${INTERFACE}" | grep inet6 | grep -v autoconf | grep -v "inet6 fe80" | cut -w -f 3)

/sbin/ifconfig "${INTERFACE}" inet6 prefer_source "${IPv6}"


I had to check System->Gateways->Single->WAN_DHCP->Upstream Gateway manually before I could connect outbound (maybe disable / enable gateway afterwards).

Falls noch jemand das Problem hat:
Damit ich wieder IPv6 direkt in Opnsense (Updates prüfen/ausführen, ping, traceroute,gateway monitor) nutzen konnte, habe ich nun manuell die "prefer_source" Option auf die funktionierende IPv6 Adresse gesetzt:

Code Select Expand

ifconfig em0 inet6 2a02:908:xxxx::xxxx prefer_source

IPv6 geht an und für sich. Einzige Problem, das ich noch habe, ist, dass IPv6 Pings über das WAN Interface nicht gehen (und somit auch das Gateway Monitoring).

Das WAN Interface bezieht über DHCPv6 die folgenden Einstellungen:

Code Select Expand

em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        options=481059b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,NOMAP>
        ether aa:bb:cc:dd:ee:ff
        inet6 fe80::xxxx:xxxx:xxxx:xxxx%em0 prefixlen 64 scopeid 0x1
        inet6 2a02:3102:aaaa::aaaa prefixlen 64 autoconf
        inet6 2a02:908:bbbb::aaaa prefixlen 64 autoconf
        inet6 2a02:908:bbbb::bbbb prefixlen 128
        inet6 2a02:3102:aaaa::bbbb prefixlen 64 autoconf
        inet 176.xxx.xxx.xxx netmask 0xfffffe00 broadcast 255.255.255.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Das Dashboard zeigt mir für das WAN die 2a02:3102:aaaa::aaaa Adresse an (vermutlich einfach die erste nicht-lokale Adresse?). Diese wird auch für den Ping Befehl unter Interfaces Diagnostics genutzt. Wenn ich den Ping nun im Terminal ausführe mit allen WAN Adressen als Quelle, sieht es wie folgt aus:

Code Select Expand


/sbin/ping6 -S '2a02:3102:aaaa::aaaa' -c '3' 'heise.de' --> timeout
/sbin/ping6 -S '2a02:908:bbbb::aaaa' -c '3' 'heise.de' --> timeout
/sbin/ping6 -S '2a02:908:bbbb::bbbb' -c '3' 'heise.de' --> Funktioniert
/sbin/ping6 -S '2a02:3102:aaaa::bbbb' -c '3' 'heise.de' --> timeout

Das bedeutet nur bei der WAN Adresse, die nicht "autoconf" als Merkmal hat, funktioniert es. Wenn ich es richtig verstanden habe, ist dies die Adresse, die ich über DHCPv6 erhalte und die  anderen drei über SLAAC? Siehe auch dieser Thread im Unitymediaforum (nur das ich zusätzlich die nicht-autoconf IP erhalte).

Und letzter Nachtrag: Nach den Wartungsarbeiten am Montag und den IPv6 Problemen geht es nun wieder, ohne dass ich etwas ändern musste. Das LAN Interface hat nun ein (neues) Prefix.

Noch eine Ergänzung, da man sich anmelden muss, um die Beiträge im VF Forum zu lesen (?):

Das Ticket ist geschlossen worden und ich kann wieder einen Präfix über dhcpv6 beziehen und über ipv6 auf das Internet zugreifen. Allerdings werden 3 Präfixe immer noch über Router Advertisements im Vodafone-Netz verteilt (SLAAC, siehe den 1. Beitrag oben). Diese Präfixe sind aber gar nicht nutzbar, ich kann über sie auf das Internet nicht zugreifen, nur über den Präfix, den ich über dhcpv6 beziehe. Da aber die ipv6 auf der WAN-Netzwerkkarte in mathematischer Reihenfolge verteilt werden, besteht die Möglichkeit, dass der von mir über dhcpv6 bezogene Präfix in der Liste der zugewiesenen Adressen auf der WAN-Netzwerkkarte unterhalb der Präfixe landet, die durch RAs des Vodafone RA-Servers verteilt werden:

ipconfig /all

IPv6-Adresse. . . . . . . . . . . : 2a02:908:XXX:XXX:XXX:XXX:XXX:XXX(Bevorzugt) <<< SLAAC
IPv6-Adresse. . . . . . . . . . . : 2a02:3102:XXX:XXX:XXX:XXX:XXX:XXX(Bevorzugt) <<< SLAAC
IPv6-Adresse. . . . . . . . . . . : 2a02:3102:XXX:XXX:XXX:XXX:XXX:XXX(Bevorzugt) <<< SLAAC
IPv6-Adresse. . . . . . . . . . . : 2a02:8071:XXX:XXX:XXX:XXX:XXX:XXX(Bevorzugt) <<< dhcpv6

Standardgateway . . . . . . . . . : fe80::f27c:c701:2cab:fb4%4
Standardgateway . . . . . . . . . : fe80::f27c:c701:30ab:fb4%4
Standardgateway . . . . . . . . . : fe80::f27c:c701:31ab:fb4%4

Außerdem, wenn ich mal meinen Präfix ändern will, bringt das nichts, es sei denn der dhcpv6-Präfix landet in der Liste auf dem 1. Platz, weil beim Zugriff auf das Internet immer die erste Adresse verwendet wird (im Beispiel oben: 2a02:908, weil 908 < 8071)

Ich habe die Routersuche (Router Discovery) auf der WAN-Netzwerkkarte abgeschaltet:

Windows:

netsh interface ipv6 set interface "XXX" routerdiscovery=disabled

Debian:

autoconf in /etc/sysctl.conf

damit keine SLAAC-Präfixe über den Vodafone RA-Server zugewiesen werden. Aber wenn ich die Routersuche abschalte, wird naturgemäß das Standardgateway (oben: fe80::f27c:c701:2cab:fb4) nicht zugewiesen. Das nervt, ich muß jetzt das Gateway manuell zuweisen, und weil das Gateway sich ab und zu ändert, musste ich mein dhcpv6-Script erweitern, um die dhcpv6-Server-Adresse auszulesen und ggf. das Standardgateway auf der WAN-Netzwerkkarte updaten, wenn das Gateway sich ändert.

Im Vodafone-Netz laufen 3 RA-Server:

fe80::f27c:c701:2cab:fb4
fe80::f27c:c701:30ab:fb4
fe80::f27c:c701:31ab:fb4

Allerdings funktioniert nur der erste (fe80::f27c:c701:2cab:fb4), das ist auch derjenige, der auf dhcpv6-Anfragen antwortet. Wenn ich das 2. Gateway z.B. zuweise (fe80::f27c:c701:30ab:fb4) statt des ersten, lässt mich das Gateway nicht durch.

Ich begreife nicht, warum es 3 RA-Server gibt (früher gab es nur einen), und warum nicht funktionierende Präfixe über SLAAC verteilt werden, ist mir ebenfalls unklar. Früher wurde über RAs nur das Gateway verteilt, der Präfix wurde über dhcpv6 bezogen, damit wurde nur das Gateway über SLAAC automatisch zugewiesen und ich konnte die Routersuche anlassen.

Das Standardgateway lässt sich ebenfalls nicht anpingen (obwohl es funktioniert, wenn ich auf globale ipv6-Adressen zugreife), also:

ping -6 fe80::f27c:c701:2cab:fb4

Zeitüberschreitung der Anforderung.

Früher ging das, und das war hilfreich, wenn man schnell testen musste, ob man Zugriff auf das Gateway hat.

Könntet Ihr Euer Netz fixen, damit die Router Advertisements wie früher funktionieren? Also nur 1 RA-Server für Standardgateway-Zuweisung, und keine Präfix-Verteilung über SLAAC. Oder erklärt uns zumindest, wozu 3 RA-Server und die Präfix-Verteilung über SLAAC gut sind, denn, wie gesagt, 2 der 3 Gateways funzen nicht und keiner der 3 SLAAC-Präfixe

Noch nicht sicher, wie ich das in opnsense "fixen" soll...

Hallo,

bei mir in NRW gab es gestern auch Unitymedia/Vodafone Wartungsarbeiten und seitdem funktioniert IPv6 nicht mehr. Ich nutze ein TC4400 Modem. Unter Interfaces->LAN wird statt einer IPv6 nur noch "track6" angezeigt. Den von franco genannten Patch habe ich angewandt und neu gestartet, macht aber leider keinen Unterschied.
Das WAN Interface bekommt eine (drei in der Übersicht) IPv6 zugewiesen.
Die Log-Ausgabe vom Patch "ignoring not implemented authentication protocol: reconfig" bzw. vor Patch "unsupported authentication protocol" sehe ich auch nicht unter "System->Log Files->General" (alle Stufen ausgewählt). Bedeutet dies, dass es sich hier wohl um ein anderes Problem handelt?
Laut Log bekomme ich einen Prefix:

Code Select Expand

IA_NA address: 2a02:908:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx pltime=604800 vltime=1209600
IA_PD prefix: 2a02:908:xxxx:xxxx::/59 pltime=604800 vltime=1209600

...aber track6 scheint dies nicht zu erkennen/akzeptieren?
Wäre für jede Hilfe dankbar, dies zu debuggen.

Edit:
ich bekomme auch ein (link local) WAN_DHCP6 Gateway angezeigt, welches ich anpingen kann (fe80::f27c:c701:2cb0:7fb4). Allerdings funktionieren andere ipv6 pings zu externen Hosts über diagnostics nicht (timeout). Evtl. ein Vodafone Problem?

Edit2:
https://forum.vodafone.de/t5/St%C3%B6rungsmeldungen-Internet-TV/Kann-seit-11-04-2022-ipv6-Standardgateway-nicht-anpingen/td-p/2904082
Ist wohl ein Vodafone Problem.

[f]

One other thing I found. When going to the ipv4 ip of opnsense box I can login. That was also with ipv6, but when I go now to the ipv6 ip of opnsense on 22.1 I get this error:
Warning: array_pop() expects parameter 1 to be array, null given in /usr/local/etc/inc/authgui.inc on line 74

Appears to be a typo in that line? "hfttp_host_port" instead of "http_host_port".
edit: "fixed" it manually and no more error on ipv6 login.
Created a Pull Request: https://github.com/opnsense/core/pull/5514 - Hope I did it right.

Edit: Wohl nicht das gleiche Problem - Unbound funktioniert wohl beim OP.

Hatte das gleiche Problem. Unbound beendete sich immer wieder sofort nach Start des Dienstes. Habe den Server dann nochmal komplett neugestartet und ab da ging es.