Buongiorno a tutti,

Chiedo cortesemente il vostro aiuto in quanto sto sbattendo la testa con questo problema da diversi giorni: sto cercando di fare funzionare IPv6 correttamente sul mio UDM Pro. La buona notizia è che, in sintesi, funziona, in quanto tutti i dispositivi connessi al router ottengono efficacemente un IPv6, ed è tutto ok da test-ipv6.com

L'unico dispositivo a non ottenere un IPv6 è l'UDM. Il motivo per cui mi serve un IPv6 sull'UDM è che mi occorre per far funzionare il VPN WireGuard, il cui server è hostato sull'UDM.

Questa è la mia configurazione WAN:

Questa è la mia configurazione LAN:

E come potete vedere, ottengo un IPv4 ma non un IPv6 sull'UDM:

Ho provato svariate configurazioni WAN ad IP statico, ma non funzionano, qualsiasi cosa io provi interrompe l'operatività di IPv6 sui client.

Sono Pianeta Fibra (Aruba) su rete Fibercop.

Ringrazio anticipatamente chiunque mi dia una mano.

    Ma l'IP che hai oscurato nel secondo screenshot, quello che termina con ::1/64, non è, di fatto, l'IP del gateway?

    Hai provato ad utilizzarlo dall'esterno per raggiungere l'UDM?

    Ciao Matt, grazie per la risposta.

    Si, è l'IP del gateway ma pare avere valenza esclusivamente locale. È raggiungibile in LAN e posso pingarlo dagli altri dispositivi della rete, ma non dall'esterno.

    Se faccio

    curl -6 ifconfig.co/ip

    Mi da

    curl: (28) Failed to connect to ifconfig.co port 80: Connection timed out

    Mentre su tutti gli altri dispositivi della rete il comando restituisce subito l'IPv6 pubblico e raggiungibile dall'esterno

    Gli IPv6 globali sono globali, indipendentemente dall'interfaccia alla quale sono assegnati... È più probabile che sia il firewall che stia bloccando le connessioni dall'esterno...
    Hai controllato le regole?

      mickey Ho provato svariate configurazioni WAN ad IP statico, ma non funzionano, qualsiasi cosa io provi interrompe l'operatività di IPv6 sui client.

      Il tuo router manda i pacchetti V6 della LAN attraverso il V6 LL nella P2P tra te e il BNG di Aruba.

      Ma nella LAN i dispositivi usano sempre un indirizzo ULA per mandare tutto al gateway locale?

      Matwolf

      Non è detto. Se tutte le P2P sono fatte con indirizzi ULA e non UGA non ha davvero un IPv6 routable sulla DM.

      Non è la prima volta che si vedono strane scelte da parte di Ubiquiti su V6 visto che sembrano essere molto V4 centrici.

      Su un router normale alla peggio ci faceva una dummy interface con un UGA a scelta tanto tutto il prefisso /56 è routed. Qui bho.

      Matwolf È più probabile che sia il firewall che stia bloccando le connessioni dall'esterno...
      Hai controllato le regole?

      C'è da controllare questo, sempre se il firewall lo consenta.

      @Lorenzo1635 @Matwolf

      Anzitutto grazie per le risposte.

      Dunque, ho provato una serie di regole firewall. Dopo un po' ho visto che questa specifica regola:

      Mi permette di pingare dall'esterno (per comodità utilizzo questo strumento
      l'indirizzo del gateway che vedo nella sezione LAN.

      Tuttavia, non mi permette di fare altro. Wireguard non funziona.

      In merito a ULA/GUA... riesco tranquillamente a raggiungere il mio RaspberryPi tramite IPv6 dall'esterno, su di esso gira un web service che funziona tranquillamente, pertanto ai dispositivi viene senza dubbio assegnato un GUA, tuttavia se poi il Raspi (o altri dispositivi) utilizzino ULA per comunicare con l'UDM, non saprei... potreste consigliarmi che analisi effettuare per capirlo?

        mickey Mi permette di pingare dall'esterno (per comodità utilizzo questo strumento
        l'indirizzo del gateway che vedo nella sezione LAN.

        Quindi è routed correttamente.

        mickey Wireguard non funziona.

        Sei sicuro che sia in ascolto su tutte le interfacce?
        Se sei riuscito a far passare ICMP non vedo perché non dovresti riuscirci con TCP/UDP

        14 giorni dopo

        Sono un fesso, testavo il VPN con rete di un MVNO basato su TIM che non supporta IPv6 (CoopVoce).

        Rimane il fatto che per qualche ragione non viene mostrato l'IPv6 nel riepilogo della sezione WAN (accanto all'IPv4), tuttavia l'IPv6 del gateway è effettivamente quello visibile nella sezione LAN, come diceva @Matwolf .

        Per completezza, questa è l'unica regola firewall necessaria a far funzionare correttamente il VPN WireGuard con IPv6:

        Grazie a tutti per le vostre risposte ed il vostro tempo e buone feste!

          mickey per qualche ragione

          Perché il gateway non ha un IPv6 routable sulla WAN, è corretto. Usa un LL.

          • mickey ha risposto a questo messaggio

            Lorenzo1635 Però mi domando: se fosse esclusivamente link local non sarebbe accessibile dall'esterno, no? Il fatto che io riesca ad utilizzare l'UDM come server WireGuard tramite <base-prefix>::1 vuol dire che é per forza WAN routed, o mi sfugge qualcosa?

              mickey

              Che non è un IP della interfaccia WAN, è un IP dell'interfaccia LAN: tutti i tuoi IPv6 sono routable ma il firewall -ovviamente - non lascia accedere a tutti i tuoi dispositivi dall'esterno.

              Diventa forse più chiaro in uno scenario in cui hai due o più LAN distinte (magari tramite VLAN):

              In questo caso la UDM ha 2 IPv6 ""WAN"" (abusando di questo termine).

              Comunque vabbè è solo nomenclatura alla fine di come chiami le interfacce.

              Ti ringrazio molto per l'immagine, ha aiutato, anche se ho dovuto sbatterci la testa, ma alla fine credo di aver capito... Ero troppo legato al concetto di NAT, o meglio, ad ignorare il salto che il NAT fa fare tra interfaccia WAN e LAN quando mi connetto ad un IPv4:porta.

              In IPv6, a differenza dell'IPv4, non c'è NAT, quindi:

              • L'interfaccia WAN usa solo un indirizzo link-local per comunicare con il BNG perché non ha necessità di essere esposta
              • Gli indirizzi pubblici (routable) sono assegnati direttamente alle interfacce LAN ed ai dispositivi che ne fanno parte
              • Il prefisso (es. 2001:db8:4efc:3db7::/64) è assegnato dall'ISP a me
              • L'ISP inoltra tutto il traffico per quel prefisso al mio router via link-local
              • Il router poi smista internamente in base al suffisso (::1, ::35, :34dc:54df:3d23:0001, ecc.)
              • L'istanza del server WireGuard è in ascolto sulla LAN, non sulla WAN. IPv4:porta vuol dire che il NAT reindirizza il traffico dall'interfaccia WAN alla LAN corrispondente, ma in IPv6 posso connettermi direttamente all'interfaccia LAN in questione.

              Il possibile routing di una richiesta a 2001:db8:4efc:3db7::1 quindi è:

              1. Il router di provenienza lo manda al mio ISP
              2. L mio ISP riceve il pacchetto, riconosce il mio prefisso, lo rimuove e lo manda al mio router via link-local
              3. Il mio router riceve dal BNG solo ::1 e lo indirizza al dispositivo corrispondente, in questio caso all'interfaccia LAN1

              Riassumendo, volevo necessariamente vedere un IPv6 dell'interfaccia WAN per un lascito di IPv4, ma fintantoché posso arrivare direttamente all'interfaccia LAN dove è in ascolto WireGuard, non ne ho bisogno!

                mickey Il router di provenienza lo manda al mio ISP
                L mio ISP riceve il pacchetto, riconosce il mio prefisso, lo rimuove e lo manda al mio router via link-local
                Il mio router riceve dal BGM solo ::1 e lo indirizza al dispositivo corrispondente, in questio caso all'interfaccia LAN1

                Tutto giusto quanto hai detto sopra l'unica cosa:
                a. Il tuo router fà una richiesta DHCPv6-PD al BNG.
                b. Il BNG ti dà un intero prefisso /56. Cosa ci fai non sono problemi suoi.

                1. Da qualche parte lato ISP c'è una route del tipo:
                  TUO_PREFISSO/56 via IP_LL_UDM/64

                c. Tu prendi quel prefisso /56 e ci fai una subnet /64 da usare come LAN. /64 perchè altrimenti romperesti SLAAC ma avresti potuto fare quello che più ti aggradava.

                Non devono toccare i tuoi pacchetti in nessun modo: arriva un pacchetto per te ai loro edge, ci fanno tutto il route nella loro rete, il BNG lo spara a te. Non c'è alterazione.

                Ora ho il dubbio che il P2P tra te il tuo router non sia una /64 e che non sia proprio fatta così la entry della route (perchè potrebbe essere come diretta) ma per capirci va bene così al netto dei dettagli implementativi.

                Tutto chiaro, avevo immaginato vi fosse una sorta di stripping della destinazione, invece sorgente e destinazione rimangono intatte e cambiano solo le header di livello inferiore, ovvero i MAC address di destinazione, durante i vari "salti". In questo senso il pacchetto viene modificato quando viene passato di "mano in mano", ma ovviamente non viene mutata la payload.

                Cercando di comprendere la tua ultima affermazione, desumo tu ti stia riferendo alla connessione che avviene in link local tra il BNG ed il router... Sono curioso di sapere da dove nasca il dubbio, poiché tutte le altre volte che abbiamo menzionato /64, non ci riferivamo alla P2P, dunque perché la P2P dovrebbe essere /64 ? C'è qualcosa di specifico che hai notato in merito alla mia situazione con Aruba, oppure è un ragionamento che stavi facendo così, a freddo, riguardo tutte le implementazioni link-local (ovvero che potrebbero essere dirette per evitare di assegnare due indirizzi da un gigantesco plethora da IP? Che poi non ci interessa comunque perché sono tutti fe80: e rimangono tra il gateway ed il BNG, no?)

                  mickey

                  Nono, tranquillo la tua configurazione è OK 😅. Nulla da eccepire in quello che hai fatto.

                  Solitamente anche le P2P sono delle /64 (Anche se potrebbe sembrare uno spreco di spazio solitamente non si fanno subnet più piccole di /64 indipendentemente dallo scopo. Gli IPv6 sono tantiiii) tuttavia il mio dubbio ricadeva su come viene fatto il provisioning dell' interfaccia vista la presenza della PPPoE che potrebbe cambiare la situazione. Ammetto la mia ignoranza, dovrei andare a vedere la RFC.

                  EDIT: Sul mio router è una /64 anche la P2P verso il BNG Aruba. Fun fact: sul mio Fritz dalla /56 la CPE si è tirata fuori - oltre che le /64 per LAN e GUEST - una /64 il cui primo address è posto sulla WAN interface, inoltre gli IP lato router sulle due subnet utenti sono bloccati dal firewall dall'esterno. Questo setup è più vicino a quello che ti saresti aspettato tu probabilmente. Comunque cambia poco alla fine.

                  @Lorenzo1635 Very fun fact: ti scrivo lontano da casa, da rete Dimensione (che usa prefisso /48) dove ho anche io un Fritz. Ebbene, vedo esattamente quello che dici tu, un'IP sull'interfaccia WAN!


                  I prefissi qua sopra non sono veri, ovviamente, li ho modificati...

                  Secondo AVM:

                  The WAN prefix and WAN interface ID combine to make up the IPv6 address for the WAN interface of the FRITZ!Box. This globally unique IPv6 address is needed by the FRITZ!Box for Internet communication. The WAN prefix is the part of the IPv6 address that designates the network.
                  Use first /64 prefix from the LAN prefix
                  Determines the first network from the LAN prefix with a prefix 64 bits long.

                  Dunque in questo caso il Fritz, a differenza dell'UDM, negozia un IPv6 non link-local con il BNG? Fosse così immagino che vada virtualmente a discapito del numero di IP assegnabili in LAN!

                  Poi per quello che dicevamo prima, penso di aver capito adesso: ovvero che normalmente si usa la subnet /64 per convenzione anche dove non serve, solo che le PPPoE utilizzano maschere diverse, tipo /32, anche in IPv4, ed essendoci la matematica certezza che gli host sull'interfaccia PPPoE siano solo due, allora non sarebbe stato implausibile pensare che la P2P BNG-router fosse una subnet di dimensioni non convenzionali. Solo che nel caso dell'UDM non avrebbe alcuna rilevanza siccome la P2P è LL, mentre presupponendo che sia vero che con il Fritz l'IP WAN non sia LL e sia pure in /64 vuole dire che mi toglie un'intera subnet di indirizzi assegnabili... (poi comunque ce ne frega poco perché come dicevi tu gli IPv6 sono tantissimi).

                    mickey il Fritz, a differenza dell'UDM, negozia un IPv6 non link-local con il BNG?

                    No, ha sia un link local per parlare con il BNG sia un IP GUA. Nella rete /64 WAN GUA c'è solo il Fritz quindi è praticamente alla stregua di una dummy interface. Volevano avere un IP6 sulla WAN che fosse indipendente da quelli in LAN/GUEST (e varie altre subnet). Non dovrebbe essere strettamente necessario (anche perché dubito che il BNG poi si prenda un IP in quella subnet: a che pro? In che modo? Sarebbe davvero molto complesso) a differenza di quello che dice il manuale.

                    Puoi avere conferma di ciò scaricando i dati di telemetria e guardando la routing table e stato interfacce.

                    Ma anche tu sulle interfacce vedi un indirizzo LAN al di fuori del prefisso assegnato con DHCPv6PD?

                    Perché io ho il prefisso xxxx:yyyy:2d55::/48 ed i device hanno tutti IP basati su questo prefisso, che persiste ai riavvii, mentre l'IP dell'interfaccia LAN (presumo sia la LAN perché WireGuard è in ascolto su una porta presso questo IP) è xxxx:yyyy:1000:ea44:aaaa:bbbb:cccc:dddd... e ad ogni riconnessione cambia quel terzo e/o gruppo.

                    Mentre a questo punto non sono esattamente sicuro come identificare l'IPv6 che il Fritz abbia assegnato esclusivamente all'interfaccia WAN

                      mickey

                      Oddio, no, sul mio Fritz in rete Aruba non vedo nulla di simile. Posso chiederti uno screenshot con il contesto in cui tu possa aver visto ciò? Perchè non credo di aver capito la domanda, perdonami.

                      Certamente, scusami se mi sono spiegato male.

                      Ecco qui:

                      Questo è uno screenshot di Internet -> Online monitor. Quello segnato come IPv6 address è quello che mi da come endpoint per WireGuard, nonché per accedere alla WebUI, quindi debbo supporre sia quello della LAN... Tuttavia, è fuori dall'IPv6 prefix!

                        Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                        P.I. IT16712091004 - info@fibraclick.it

                        ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile