OPNsense - Routing eines zusätzlich gebuchten IPv6-Subnetzes

  • Ein freundliches Hallo in die Runde,


    ich habe für meinen Root-Server ein zusätzliches IPv6-Subnetz gebucht, komme aber beim Routing geneu dieses Subnetzes nicht wirklich weiter.

    Im SCP werden die Daten wie folgt angegeben:


    XXXX:XXXX:a:XXX::/64 -> Gateway / Routing auf fe80::1 (Standard-IPv6-Subnetz)

    XXXX:XXXX:b:XXX::/64 -> Gateway / Routing auf XXXX:XXXX:a:XXX:XXXX:XXXX:XXXX:XXXX (zusätzlichen IPv6-Subnetz)


    Zur Einrichtung habe ich in der OPNsense folgende Schritte unternommmen:


    WAN-Interface:

    IPv6-Address: XXXX:XXXX:a:XXX:XXXX:XXXX:XXXX:XXXX/64

    Gateway: fe80::1


    LAN-Interface:

    IPv6-Address: XXXX:XXXX:b:XXX::1/64

    Gateway: ? (bisher hahe ich hier nichts eingetragen)


    Von der OPNsense aus kann ich über die Konsole und über das Webinterface alle möglichen IPv6-Adressen "anpingen".

    Von meinen VM aus dem entsprechend konfigurierten LAN geht das allerdings nicht.


    Für mich würde das auf ein Routing-Problem hindeuten ....


    In der /etc/network/interfaces einer VM habe ich diese Einstellungen vorgenommen:


    a)

    iface ens4 inet6 static

    address XXXX:XXXX:b:XXX::10/64

    gateway XXXX:XXXX:b:XXX::1


    Hier erhalte ich Fehlermeldungen:


    icmp_seq=1 Destination unreachable: Address unreachable

    icmp_seq=2 Destination unreachable: Address unreachable

    icmp_seq=3 Destination unreachable: Address unreachable

    icmp_seq=4 Destination unreachable: Address unreachable

    icmp_seq=5 Destination unreachable: Address unreachable


    b)

    iface ens4 inet6 static

    address XXXX:XXXX:b:XXX::10/64

    gateway fe80::1


    Hier erhalte ich Fehlermeldungen:


    icmp_seq=1 Destination unreachable: Address unreachable

    icmp_seq=2 Destination unreachable: Address unreachable

    icmp_seq=3 Destination unreachable: Address unreachable

    icmp_seq=4 Destination unreachable: Address unreachable

    icmp_seq=5 Destination unreachable: Address unreachable


    Muss ich in der OPNsense noch einen spezifische Route setzen?

    Ich bin für jeden Tipp dankbar.


    Viele Grüße

  • ywolynsky

    Hat den Titel des Themas von „OPNsense - Routing eines zusätzlichen gebuchten IPv6-Subnetzes“ zu „OPNsense - Routing eines zusätzlich gebuchten IPv6-Subnetzes“ geändert.
  • Was sind denn bei dir LAN und WAN Interface?

    Von meinen VM aus dem entsprechend konfigurierten LAN geht das allerdings nicht.

    Was sind denn das für VMs? Wo liegen die?


    Hier erhalte ich Fehlermeldungen:

    Was hast du denn da angepingt?


    Ist ip_forwarding an?


    Diese anonymisierten XXX Schlangen sind die Hölle. Da schreib lieber a1 und a2, da erkennt man den Unterschied schneller. Wir wissen schon, wie lang so eine IPv6 Adresse ist.

  • Erst einmal herzlichen Dank für die ersten Rückmeldungen.

    In der Tat habe ich mich nicht ganz klar ausgedrückt bzw. Informationen nicht gegeben ...


    WAN: 2a03:4000::a1

    LAN: 2a03:4000::a2


    Also, die VM liegen hinter der OPNsense in einem Cloud vLAN.

    Aus diesem heraus sollen die VM über die OPNsense auf des Internet (sprich: Routing nach außen) zugreifen können.

    Angepingt habe ich die berühmt berüchtigten Google-Server:


    PING google.de(fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003)) 56 data bytes

    From a1 icmp_seq=1 Destination unreachable: Address unreachable

    From a1 icmp_seq=2 Destination unreachable: Address unreachable

    From a1 icmp_seq=3 Destination unreachable: Address unreachable

    From a1 icmp_seq=4 Destination unreachable: Address unreachable


    Hierzu noch den Hinweis:

    Wenn ich die betreffende VM mit Ihren "eigenen" (es geht hier auch um einen Root-Server) IP-Daten "ins Netz" lasse funktioniert alles prima.


    Die IPv6-Konfiguration habe ich laut Netcup-Wiki vorgenommen:


    Code
    net.ipv6.conf.default.accept_ra=0
    net.ipv6.conf.default.autoconf=0
    net.ipv6.conf.all.accept_ra=0
    net.ipv6.conf.all.autoconf=0
    net.ipv6.conf.eth0.accept_ra=0
    net.ipv6.conf.eth0.autoconf=0

    IP-Forwarding ist an:


    Code
    user@a1:~$ cat /proc/sys/net/ipv4/ip_forward
    1
  • Auf der OpenSense muss IP Forwarding für IPv6 via sysctl aktiv sein. Kann sein, dass OpenSense das automatisch macht, aber prüfe das noch mal.


    Und dann immer in kleinen Schritten arbeiten. Nachdem du das IP-Setup eingerichtet hast, fang auf einer VM an:

    - Ping auf die lokale Adresse (XXXX:XXXX:b:XXX::10)

    - Ping auf die Gateway-Adresse (XXXX:XXXX:b:XXX::1)

    - Ping auf die Gateway-Adresse der OpenSense (XXXX:XXXX:a:XXX:XXXX:XXXX:XXXX:XXXX)

    - Ping ins Internet.


    Dabei sowohl auf der VM als auch auf der OpenSense mittels tcpdump prüfen, welche Pakete wo ankommen. Das Problem bei Ping kann ja der Hinweg oder Rückweg sein, und letzterer wird gern mal vergessen.

  • OPNSense hat eine Firewall - ist der IPv6 Verkehr in der Forward Chain hier blockiert?

    Stimmt das Netzwerk Interface auf der VM - ist das Public Interface hier zusätzlich deaktiviert?


    Wie sind denn die groben Ausgaben von ip a auf der VM?


    b)

    iface ens4 inet6 static

    address XXXX:XXXX:b:XXX::10/64

    gateway fe80::1

    Das funktioniert nur, wenn du die Adresse fe80::1 dem LAN-Interface des OPNSense zuweist. Ansonsten musst du die volle Adresse nehmen.

  • Dankeschön :)


    - Ping auf lokale Adresse 2a03:4000::10 funktioniert

    - Ping auf Gateway-Adresse 2a03:4000::1 funktioniert schon nicht mehr


    Als Gateway habe ich in "/etc/network/interfaces" gerade 2a03:4000::1 hinterlegt.

  • -> Forward Chain blockiert keinen IPv6-Verkehr

    -> Interface auf der VM ist korrekt, das Public Interface ist komplett deaktivert.


    Was genau meinst du mit "allgemeine Ausgaben" von ip a?


    Ebenso: Was meinst du mit voller Adresse?

  • Ich muss gestehen, das ich mit tcpdump noch gar nicht gearbeitet habe.

    Eines aber scheint klar zu sein: tcpdump fängt von dem Interface ens4 keine IPv6-Pakete ab,

  • Du hast wirklich ein Talent, dich äußerst unklar und widersprüchlich auszudrücken.

    Eines aber scheint klar zu sein: tcpdump fängt von dem Interface ens4 keine IPv6-Pakete ab,

    Auf welchem Rechner? VM oder Opensense? Und was heißt "fängt keine IPv6 Pakete ab"? Werden keine angezeigt? Werden keine gecaptured? Wie sieht der Aufruf aus? Und was ist das Ergebnis, auch nach Beendigung von tcpdump (Statistik)?

  • Also:


    -> VM

    tcpdump -q icmp

    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

    listening on ens4, link-type EN10MB (Ethernet), snapshot length 262144 bytes

    => Ergebnis: keine Logs bei Ping auf Gateway-Adresse der OPNsense

    0 packets captured

    0 packets received by filter

    0 packets dropped by kernel



    -> OPNsense

    tcpdump -q icmp

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes

    18:24:18.624001 IP Host > gateway.netcup.net: ICMP echo request, id 20838, seq 6461, length 8

    18:24:18.624652 IP gateway.netcup.net > Host : ICMP echo reply, id 20838, seq 6461, length 8

    18:24:19.691744 IP HOST > gateway.netcup.net: ICMP echo request, id 20838, seq 6462, length 8

    18:24:19.693354 IP gateway.netcup.net > Host: ICMP echo reply, id 20838, seq 6462, length 8

    279 packets captured

    19216 packets received by filter

    0 packets dropped by kernel

  • mit tcpdump -i kannst du gezielt das Interface angeben, auf dem gelauscht werden soll. "-i any" lauscht auf allen Interfaces, das macht später auf der Opensense wahrscheinlich Sinn, da die Pakete auf dem Weg ins Internet durch mehrere Interfaces müssen.


    Wenn du als Filter "icmp" angibst, dann ist auch klar, warum du keine IPv6 Pakete siehst. Für ICMPv6 wäre das Filter "icmp6". Anstatt "-q" würde ich eher "-n" in Betracht ziehen, das macht in deinem Fall die Zuordnung wesentlich einfacher.

  • OK, hier nochmal von der VM (a1) auf OPNsense bzs. Gateway der OPNsense (a2):


    ping a2

    PING a2 (a2) 56 data bytes

    From a1 icmp_seq=1 Destination unreachable: Address unreachable

    From a1 icmp_seq=2 Destination unreachable: Address unreachable

    From a1 icmp_seq=3 Destination unreachable: Address unreachable

    From a1icmp_seq=4 Destination unreachable: Address unreachable

    From a1 icmp_seq=5 Destination unreachable: Address unreachable

    From a1 icmp_seq=6 Destination unreachable: Address unreachable

    /tt]

    -> tcpdump von a1

    [tt]

    tcpdump -i ens4 -q icmp6

    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

    listening on ens4, link-type EN10MB (Ethernet), snapshot length 262144 bytes

    18:58:18.028001 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:19.039924 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:20.063936 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:21.088117 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:22.111934 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:23.135910 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:24.160099 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:25.183936 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    18:58:26.207883 IP6 a1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has a2, length 32

    ^C

    9 packets captured

    9 packets received by filter

    0 packets dropped by kernel

  • Den interessanten Teil hast du weg gelassen: Was kommt von der neighbor solicitation bei der OpenSense an, und vor allem: Wie antwortet sie darauf? Ich könnte mir vorstellen, dass sie die Antwort auf dem falschen Interface raussendet.

  • Also nochmal:


    -> OPNsense

    -> VM ping OPNsense-Gateway



    -> VM tcpdump


  • Du lauscht auf der OpenSense auf dem falschen Interface.


    Und wenn du anfängst, Adressen zu anonymisieren, dann musst du es überall machen. Wie sollen wir denn sonst die Zuordnung zu deinen Adressen ableiten?


    Bei der Gelegenheit: Was passiert, wenn du auf der OpenSense ihre beiden lokalen IPv6 Adressen anpingst? Was passiert, wenn du von der OpenSense die VM IP anpingst? Wieder mit tcpdump auf allen beteiligten Geräten (auf den richtigen Interfaces).

  • Also nochmal, die Anonymisierung lasse ich jetzt weg ...


    VM -> OPNsense:

    a) tcpdump OPNsense

    tcpdump -i vtnet1 -n icmp6

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on vtnet1, link-type EN10MB (Ethernet), capture size 262144 bytes

    19:22:55.279305 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:56.285342 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:57.309299 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:58.333569 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:59.357336 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:00.381284 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:01.405423 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:02.429293 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:03.453318 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    ^C

    9 packets captured

    282 packets received by filter

    0 packets dropped by kernel


    b) tcpdump VM

    tcpdump -i ens4 -n icmp6

    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

    listening on ens4, link-type EN10MB (Ethernet), snapshot length 262144 bytes

    19:22:55.281995 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:56.287933 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:57.311928 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:58.336116 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:22:59.359932 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:00.383951 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:01.408070 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    19:23:02.431922 IP6 2a03:4000:20:275:185:243:10:229 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4000:20:275::1, length 32

    ^C

    8 packets captured

    8 packets received by filter

    0 packets dropped by kernel

  • Ja, das hab ich erwartet. Die neighbor solicitation kommt an, aber es gibt keine Antwort darauf. Entweder fühlt sich die OpenSense nicht angesprochen, oder sie schickt die Antwort an ein anderes Interface.


    Jetzt ist es Zeit, das IP-Setup der OpenSense zu analysieren, also:

    - wie sind die IP-Adressen verteilt auf die Interfaces?

    - Welche Routen mit welcher Metric sind eingerichtet?

    - Gibt es sowas wie Policy Based Routing?

    - Was passiert, wenn man auf der OpenSense Pings auf lokale oder entfernte Adressen absetzt?