OPNSense hat keine Route zu delegiertem dynamischen IPv6-Prefix.

[ph0llux]

Hi,

ich baue gerade ein Netz auf, hierzu habe ich ein kleines Diagramm mit den entsprechenden Komponenten skizziert und angehangen.

Der Draytek "Router" hängt an einer VDSL-Leitung und läuft im Bridge-Mode - dient somit also nur als Modem. Den VLAN-Tag musste ich über den Draytek konfigurieren, da der Full-Bridge-Mode bei diesem Modell in der Router-Konfiguration nicht angeboten wird - macht aber nichts, die IP-Adresse(n) kann ich trotzdem über den OPNSense beziehen.

Die dahinterliegende OPNSense bezieht über das WAN-Interface eine IPv4 Adresse (dynamische Adressvergabe, keine statische Adresse) und einen entsprechenden /56er-Prefix aus dem Telekom-Adressraum mittels PPPoE (IPv4) bzw. DHCPv6 (IPv6). Die IPv4 erwähne ich nur, weil die Option "Use IPv4 connectivity" bei dem Interface ausgewählt wurde.

Das LAN-Interface der OPNSense ist als Track-Interface mit der Prefix-ID 0x0 konfiguriert.
Für das LAN-Interface wurde die virtuelle IP fd00:1::1/64 vergeben.
Für das LAN-Interface wurde ein radvd im "assisted" Mode konfiguriert, so dass Client1 und Client2 per SLAAC eine ULA aus dem Bereich fd00:1::/64 und eine GUA aus dem von der Telekom zugewiesenen Adressraum konfigurieren können.
Das klappt soweit auch gut. Google ist pingbar von Client1 und Client2 aus.
Als Firewall-Regel habe ich für das LAN Interface jetzt erstmal alles zugelassen, um besser debuggen zu können.

Auf der OPNSense wurde ein Gateway zum Router2 konfiguriert (Router2 hat auf dem entsprechenden Interface die statische Adresse fd00:1::2/64). Das klappt auch soweit, das Gateway wird als Online angezeigt und ist von der OPNSense heraus auch pingbar auf der fd00:1::2.
Die OPNSense delegiert über DHCPv6 auf dem LAN-Interface den Prefix mit der Prefix-Range ::1:0:0:0:0 - ::1:0:0:0:0 /64.
Das klappt auch soweit - unter Services -> DHCPv6 -> leases wird hier unter "Delegated Prefixes" ein entsprechender lease angezeigt.

Der Router2 bekommt den Prefix delegiert, auch hier werden entsprechend RAs an den Client3 und Client4 verteilt.
Client3 und Client4 erhalten sowohl eine fd00:2::/64er Adresse als auch eine GUA aus dem delegierten Prefix.
Cient3 kann Client4 pingen. Client3 kann Client1 und Client2 auf der fd00:1::er Adresse problemlos pingen. Client3 kann die OPNSense auf der fd00:1::1 pingen.
Client3 kann die GUA auf Router2 auf dem Interface1 pingen.
Was nicht mehr geht:
- Client3 kann Client1 nicht auf der GUA pingen
- Client3 kann Google nicht pingen.
- OPNSense kann Client3 auf der GUA nicht pingen.


Ich habe jetzt mal auf Client 1 Wireshark laufen lassen, während Client3 versucht hat, Client1 zu pingen:
Der Ping-Request von Client3 kommt bei Client1 an, Client1 versucht auch zu antworten, schickt aber seine Antwort an sein Gateway - und das ist das LAN-Interface der OPNSense. Die OPNSense hat aber scheinbar keine Route zu dem Prefix, den sie delegiert hat. Da der Prefix aber seitens der Telekom dynamisch vergeben wird, kann ich keine statische Route festlegen.
Mein Ziel ist es, dass ich mit Client3 nachher mit dem delegierten Prefix auch wirklich nach draußen kommunizieren kann. Das geht leider derzeit nicht.

Habe ich ggf. irgendwo was falsch konfiguriert oder ist es normal das OPNSense bei delegiertem Prefix keine Route vergibt?
Da der ursprüngliche /56er Prefix blöderweise dynamisch von der Telekom vergeben wird, kann ich leider auch keine statische Route festlegen. 


Ich hoffe, ich habe es detailliert genug beschrieben...falls etwas fehlt, gebt mir Bescheid, dann reiche ich es gerne nach.

Viele Grüße
ph0llux

[franco]

Hi,

In /var/dhcpd/var/db/dhcpd6.leases müsste der delegierte Prefix stehen. Kannst du den Eintrag bitte mal zeigen?

Das Problem scheint mir zu sein, dass isc-dhcp keine Router IP kennt und dann auch keine Route setzen kann...

https://github.com/opnsense/core/blob/b0b34c586683186660dc4997d8debafa8b89c40a/src/opnsense/scripts/dhcp/prefixes.php#L80


Grüsse
Franco

[franco]

> Router2 hat auf dem entsprechenden Interface die statische Adresse fd00:1::2/64

Also kein DHCP? Static Mapping zumindest? Vielleicht können wir das damit lösen, aber die DUID muss gesetzt sein.


Grüsse
Franco

[ph0llux]

Hallo Franco,

In /var/dhcpd/var/db/dhcpd6.leases müsste der delegierte Prefix stehen. Kannst du den Eintrag bitte mal zeigen?

Klar, kein Problem:

Code: [Select]

# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.4.3-P1

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\001,\021\267\307\344=\032\370\021\027";

[...]

ia-pd "3\351&\235\000\002\000\000\253\0215\0261-\246\371\203\245" {
  cltt 1 2023/06/12 10:58:40;
  iaprefix 2003:xxxx:xxxx:a701::/64 {
    binding state active;
    preferred-life 312;
    max-life 500;
    ends 1 2023/06/12 11:07:00;
  }
}

(Bei [...] sind eigentlich noch mehr Einträge, aber da es sich aufgrund der von mir niedrig eingestellten Lifetime sowieso um diesselben Einträge nur mit anderen Uhrzeiten handelt, habe ich diese der Übersicht halber rausgenommen...).

Also kein DHCP? Static Mapping zumindest? Vielleicht können wir das damit lösen, aber die DUID muss gesetzt sein.

Ja und nein. Ich habe die fd00:1::2/64 statisch vergeben, damit ich den Router einfacher erreichen kann. Er berechnet sich trotzdem über SLAAC eine weitere fd00-er EUI64 Adresse.
Zusätzlich eine GUA. 

Das Interface 1 von Router2 wird mittels systemd-networkd also wie folgt konfiguriert:
- statische fd00:1::2/64
- EUI64 SLAAC fd00:1::/64-er Adresse
- EUI64 SLAAC GUA Adresse

Zusätzlich erhält Router2 einen /64-er GUA Prefix zur Weiterverteilung auf Interface2.

Sorry falls ich das eingangs unklar erläutert habe. 

Meinst du damit, ich soll managed RAs statt assisted versenden und die Adressen per DHCPv6 vergeben?

[franco]

SLAAC bringt ja dem DHCP nichts bei der Lokalisierung des Routers mit dem übergebenen Prefix.

Leider ist das so, dass man einen Prefix bekommen kann ohne zu wissen wo der dann tätig ist. Lösen kann man das in dem man noch eine dynamische Adresse verlangt am Router. Das müsste auch gehen mit den Boardmitteln.

Und ich hab mal was gebastelt: https://github.com/opnsense/core/commit/a73813684721a

So muss man in deinem Fall nichts ändern, aber die statisch vergebene Adresse zumindest bekannt geben im DHCP (mit der korrekten DUID vom Prefix). Dann kann diese auch verwendet werden für die Zielroute.

# opnsense-patch a73813684721a

Benötigt mindestens einen neuen Lease-Versuch des Routers, vielleicht auch einen Neustart der OPNsense wenn die Lease Datei sich nicht ändert (wird per Hash abgefragt und bei Änderung wird versucht die Routen zu setzen).


Grüsse
Franco

[ph0llux]

Hallo Franco,

danke dir für die Mühe.

Ich habe den Patch eingespielt, unter Services->DHCPv6->[LAN]->DHCPv6 Static Mappings for this interface meine statische fd00:1::2 eingetragen und die OPNSense neu gestartet.
Es wird auch unter leases angezeigt dass der Router2 online ist, leider ist noch immer keine passende Route vorhanden.
Zudem erhalte ich folgende "Crash report" Fehlermeldungen:

Code: [Select]

[12-Jun-2023 14:24:53 Europe/Berlin] Error: Call to undefined function interfaces_primary_address6() in /usr/local/etc/inc/plugins.inc.d/dhcpd.inc:1871
Stack trace:
#0 /usr/local/etc/inc/plugins.inc(330): dhcpd_staticmap()
#1 /usr/local/opnsense/scripts/dhcp/prefixes.php(109): plugins_run('static_mapping')
#2 {main}

Muss ich da noch irgendwas anders konfigurieren?

[franco]

Mein Fehler. Das hier fehlt noch https://github.com/opnsense/core/commit/c868a2e4bf

# opnsense-patch c868a2e4bf

Ggf. klappt das mit dem Expire-Wert noch nicht, aber ein Schritt nach dem anderen


Grüsse
Franco

[ph0llux]

Ah super, mit dem letzten Patch hat es dann auch geklappt und ich kann von Client3 aus auch Google pingen:

Code: [Select]

PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=59 time=9.10 ms
Vielen Dank dir für das schnelle patchen.

Ggf. klappt das mit dem Expire-Wert noch nicht, aber ein Schritt nach dem anderen

Ich weiß nicht genau welchen Expire-Wert du ansprichst, sofern ich aber noch irgendwas nachprüfen soll, gib mir einfach Bescheid, ein wenig Debugger spielen ist meinerseits drin.

[franco]

Ok, prima.

Mit Expire meine ich:

https://github.com/opnsense/core/blob/master/src/opnsense/scripts/dhcp/prefixes.php#L147-L152

Es kann sein, dass es einen gültigen Prefix löscht weil er schon mal als "expired" geloggt wurde. Ich schaue mir das morgen noch an.


Grüsse
Franco

[ph0llux]

Moin,

es ist leider doch noch ein Fehler aufgetreten, ich bin aber nicht sicher, ob das jetzt an deinem patch liegt oder nicht.

Ich habe heute morgen festgestellt dass der DHCPv6 Server für das LAN Interface deaktiviert ist. Das lässt sich auch provozieren, indem ich auf dem WAN interface ein DHCPv6 reload anstoße (sprich, mir einen neuen Prefix vom Provider zukommen lasse).
Der DHCPv6 hat dann keine IP-Range/Prefix-Range mehr und sagt auch beim Versuch, diesen zu starten "No available address range for configured interface subnet size."
Ich kann dann allerdings hingehen und das LAN-Interface neustarten ("Save" und "Apply changes" obwohl keine Änderungen gemacht wurden). Dann läuft der DHCPv6 Server wieder und die Delegation geht weiter.
Könnte aber auch hiermit zusammen hängen: https://forum.opnsense.org/index.php?topic=26832.0 ?
Da ich vorher keine funktionierende Delegation hatte, kann ich leider nicht genau sagen, ob es am Patch liegt oder nicht.

Hier sind die entsprechenden Log-Einträge dazu:

Code: [Select]

2023-06-13T09:27:46 Error opnsense /usr/local/etc/rc.restart_webgui: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '1', the output was ''
2023-06-13T09:27:46 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Resource deadlock avoided'
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Resource deadlock avoided'
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '2078'' returned exit code '1', the output was 'kill: 2078: No such process'
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '2078'' returned exit code '1', the output was 'kill: 2078: No such process'
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '2078'' returned exit code '1', the output was 'kill: 2078: No such process'
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/bin/protect -i /usr/local/sbin/sshd' returned exit code '15', the output was ''
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:45 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Resource deadlock avoided'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Resource deadlock avoided'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Resource deadlock avoided'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '9359'' returned exit code '1', the output was 'kill: 9359: No such process'
2023-06-13T09:27:40 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
2023-06-13T09:27:27 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:27 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:25 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:23 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:23 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:21 Error opnsense /usr/local/etc/rc.newwanipv6: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'
2023-06-13T09:27:19 Error dhcp6c transmit failed: Can't assign requested address
2023-06-13T09:27:19 Error dhcp6c transmit failed: Can't assign requested address
2023-06-13T09:27:19 Error opnsense /usr/local/etc/rc.configure_interface: The command '/bin/kill -'TERM' '31741'' returned exit code '1', the output was 'kill: 31741: No such process'

btw.: ich fahre derzeit ohnehin die aktuellste 23.1.9. Das hatte ich eingangs vergessen zu erwähnen, gehe aber davon aus, dass du ohnehin von der aktuellsten stable ausgegangen bist.

[franco]

Deaktiviert oder gestoppt? Meistens liegt das gestoppt daran, dass beim Reload auf dem WAN kein PD mitgegeben wurde. Das passiert manchmal... kommt auf den Upstream-Router an.

Jedenfalls gab es hier einen Event der die alten Adressen invalidiert hat:

> 2023-06-13T09:27:19   Error   dhcp6c    transmit failed: Can't assign requested address

Zwangstrennung? LAN IPv6 auf Tracking gestellt?


Grüsse
Franco

[ph0llux]

Hi,

Deaktiviert oder gestoppt?

Gestoppt.
Restart geht auch erst, wenn ich das LAN Interface halt über 'save' und 'apply changes' neu starte/initialisiere/[was genau er dann auch immer damit macht].

Zwangstrennung? LAN IPv6 auf Tracking gestellt?

Das LAN Interface steht auf Tracking und trackt das WAN Interface.

[franco]

Ok,

Interfaces: Settings: Log level auf "Info" setzen.

Interfaces: Settings: Prevent release ist aus?

Der Log Level braucht einen Neustart bei Gelegenheit. Dann gibt es auch die "dhcp6c" Log Einträge und wir sehen was der Upstream-Router sagt wenn es noch mal passiert.


Grüsse
Franco

[ph0llux]

Interfaces: Settings: Prevent release ist aus?

Nein, war natürlich bei allen Interfaces angeschaltet. 

Ich kann es mittlerweile zumindest nicht mehr manuell provozieren. Ich warte mal die nächtliche Zwangstrennung ab und melde mich dann wieder, sobald es auftritt. 

[franco]

Das Problem beim "Prevent release" ist, dass man dann den Server ignoriert in der Hoffnung der Präfix darf weiter verwendet werden. Das ist aber manchmal nicht so einfach wenn man kein fixes IPv6 hat.


Cheers,
Franco