Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour

Oui :

11:39:01 nba@lap-nba0:~/fbx-delta-api/api$ ip a show dev enp7s0
3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 24:5e:be:43:b3:73 brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.55/24 brd 10.0.20.255 scope global noprefixroute enp7s0
       valid_lft forever preferred_lft forever
    inet6 fd00:20::3f/128 scope global dynamic noprefixroute 
       valid_lft 529930sec preferred_lft 529930sec
    inet6 fe80::ba04:a374:492a:b7b2/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

idem sur une autre machine :

ip a show dev sfp-nba1
21: sfp-nba1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:fd:fe:1a:66:60 brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.25/24 brd 10.0.20.255 scope global noprefixroute sfp-nba1
       valid_lft forever preferred_lft forever
    inet6 fd00:20::14/128 scope global dynamic noprefixroute 
       valid_lft 595434sec preferred_lft 595434sec
    inet6 fe80::7977:e385:4eba:fba4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Les machines ont des IPv6 sur le vlan 20 dans la plage fd00:20::1 ←→ fd00:20::ffff

Sur le firewall j'ai un magic any/any en v4 + v6 (mis pour l'occasion):

config firewall policy
    edit 244
        set name "TEMP PASS ALL"
        set uuid fa7f38d8-a0e2-51ef-dcd2-c85d0bb32be8
        set srcintf "v20"
        set dstintf "v100"
        set action accept
        set srcaddr "all"
        set dstaddr "all"
        set srcaddr6 "all"
        set dstaddr6 "all"
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end

idem pour la table de routage v6 qui à pour next hop la freebox avec la static suivante :

 get router info6 routing-table static 
Routing table for VRF=0
S*      ::/0 [10/0] via fe80::3627:92ff:fe63:3990, v100, 07w1d01h, [1024/0]

Pour info la freebox est sur le vlan 100 (v100 = INTERCO-INTERNET) d'ou l'interface dans la règle 244 ci dessus et dans la table de routage.

Et ça ne fonctionne pas, depuis mon laptop qui à une pate sur le vlan 20 par exemple :

11:34:55 nba@lap-nba0:~/fbx-delta-api/api$ time curl -k https://[fd0f:ee:b0::1]/api_version ; echo
^C
real	0m12,957s
user	0m0,001s
sys	0m0,013s

11:35:17 nba@lap-nba0:~/fbx-delta-api/api$ time curl -k https://[fd0f:ee:b0::1]:20xx/api_version ; echo
^C
real	0m16,848s
user	0m0,010s
sys	0m0,018s

11:35:50 nba@lap-nba0:~/fbx-delta-api/api$ 

idem depuis tous les serveurs du LAN (quelque soit le vlan, les règles de routage et de firewalling sont OK)

Pourtant la même requête sur l'IPv6 publique de la box fonctionne :

11:34:49 nba@lap-nba0:~/fbx-delta-api/api$ time curl -k https://[2a01:e0a:xxxx:xxxx::1]:20xx/api_version ; echo
{"box_model_name":"Freebox v7 (r1)","api_base_url":"\/api\/","https_port":20xx,"device_name":"14RV-FBX","https_available":true,"box_model":"fbxgw7-r1\/full","api_domain":"fxxxxxx.fbxos.fr","uid":"537axxxxxxxxxxxxxxxxxxxxxxxxxx5","api_version":"12.0","device_type":"FreeboxServer7,1"}
real	0m0,276s
user	0m0,027s
sys	0m0,012s

PS : je constate également le souci sur une VM de la freebox qui elle à directement une IPv6 sur le vlan 100 (celui de la freebox)

En vous remerciant encore pour votre aide
Cordialement
nbanba

Bonjour

@mmakassikis merci encore pour votre réponse et pour votre aide.

J'ai poussé le debug et en effet, l'API écoute bien, mais je note un comportement surprenant (anormal ?):

17:07:15 nba@lap-nba0:~$ curl -k https://[fd0f:ee:b0::1]/api_version
{"box_model_name":"Freebox v7 (r1)","api_base_url":"\/api\/","https_port":20xx,"device_name":"14RV-FBX","https_available":true,"box_model":"fbxgw7-r1\/full","api_domain":"fxxxxxx.fbxos.fr","uid":"53xxxxxxxxxxxxxxxxxxxx5","api_version":"12.0","device_type":"FreeboxServer7,1"}

Le truc c'est que pour arriver à joindre cette IPv6 local, j'ai du ajouter sur la patte du firewall une IPv6 dans le même subnet et forcer le source nat au travers de cette IP (la dernière de la liste "config ip6-extra-addr" : "edit fd0f:ee:b0::2/64") !!

config system interface
    edit "v100"
        set vdom "root"
        set ip xxx.xxx.xxx.xxx 255.255.255.0
        set allowaccess ping
        set description "INTERNET + 5 IP WAN"
        set alias "INTERCO-INTERNET"
        set monitor-bandwidth enable
        set role wan
        set snmp-index 13
        set secondary-IP enable
        config ipv6
            set ip6-address fd00:100::f/64
            set ip6-allowaccess ping
            config ip6-extra-addr
                edit 2a01:e0x:xxxx:xxx0::f/64
                next
                ...
                edit fd0f:ee:b0::2/64
                next
            end
            set ip6-send-adv enable
            set ip6-manage-flag enable
            set ip6-other-flag enable
            config ip6-prefix-list
                edit 2a01:e0x:xxxx:xxx0::/64
                    set autonomous-flag disable
                next
                ...
                edit fd00:100::/64
                    set autonomous-flag disable
                next
            end
        end
        set interface "x1"
        set vlanid 100
        config secondaryip
            edit 1
                set ip 185.xxx.xxx.10 255.255.255.0
                set allowaccess ping
            next
            ...
            edit 5
                set ip 185.xxx.xxx.14 255.255.255.0
                set allowaccess ping
            next
        end
    next
end

Cela signifie donc que la FREEBOX n'apprend pas les RA du Firewall sur le segment L2 connectant la Freebox au firewall.
Ce comportement est surprenant pour les subnets locaux lorsque TOUS les subnets IPv6 de la box ont pour next-hop le firewall (en gros la Freebox ne gère plus l'IPv6) et que le firewall s'annonce correctement sur le subnet local présent sur le L2

Pour illustrer, voici ce que je capture dans une VM de la DELTA avec 'radvdump'.
On voit clairement que le subnet local du segment est bien annoncé, le firewall aussi pour le prefix fd00:100::/64 (=segment local IPv6 du vlan 100 faisant la jonction entre la Freebox et le firewall)

# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::209:fff:fe09:12
# received by interface enp0s3
#

interface enp0s3
{
	AdvSendAdvert on;
	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
	AdvManagedFlag on;
	AdvOtherConfigFlag on;
	AdvReachableTime 0;
	AdvRetransTimer 0;
	AdvCurHopLimit 0;
	AdvDefaultLifetime 1800;
	AdvHomeAgentFlag off;
	AdvDefaultPreference medium;
	AdvLinkMTU 1500;
	AdvSourceLLAddress on;

	prefix 2a01:e0x:xxxx:xxx0::/64
	{
		AdvValidLifetime 2592000;
		AdvPreferredLifetime 604800;
		AdvOnLink on;
		AdvAutonomous off;
		AdvRouterAddr off;
	}; # End of prefix definition
        ...
	prefix fd00:100::/64
	{
		AdvValidLifetime 2592000;
		AdvPreferredLifetime 604800;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
	}; # End of prefix definition

}; # End of interface definition

À défaut de monter une IPv6 sur le subnet fd00:100::/64, la Freebox devrait normalement ajouter une route pour ce subnet dans sa table de routage avec pour gateway le firewall, et donc je n'aurais pas du faire le bricolage consistant à ajouter l'IP fd0f:ee:b0::2 sur la pate du firewall et de source nat le trafic par cette IP lorsque la destination est fd0f:ee:b0::1

Pour tous ceux qui ont une infra 'standard' avec un firewall, il serait bien que quand la gestion globale de l'IPv6 est gérée par le firewall, la Freebox ait un comportement normal, à savoir apprendre la route du segment privé dans sa table de routage avec pour gateway le firewall pour ce subnet (ou se peer en BGP sur le link local et apprendre le subnet de cette manière).

En vous remerciant encore et d'avance
Cordialement
nbanba

PS:
la tâche avec son objet original peut être fermé. Il serait quand même bien que la Freebox ait un comportement standard au niveau des IPv6 local quand un autre routeur gère l'IPv6 sur le réseau (nécessite d'ouvrir une autre tâche ?)

Bonjour

Merci pour votre retour.
Oui aucune globale, que des ULA sur fc00/7 (plutôt sur fd00/8 d'ailleurs)
fd00:10:: L3 vlan 10
fd00:20:: L3 vlan 20
fd00:30:: L3 vlan 30
… fd00:100:: L3 vlan 100 (VLAN du segment L2 Freebox ⇔ Firewall)

Je suis également surpris d'avoir du faire tout ça …

Cordialement
nbanba

Bonsoir

Encore une fois, merci pour votre retour.

La box devrait en avoir connaissance car dans sa position de routeur n'aillant pas le contrôle de ces subnets locaux, elle devrait faire comme tous les routers ipv6 du marché , à savoir apprendre la route et la gateway (depuis les RA du router maître les controlant) pour chaque subnet de fd00/7 qu'elle ne gère pas afin de les ajouter à sa table de routage avec comme gateway le routeur/firewall maître sur le segment L2.

Pour répondre non aucune adresse GLA, à cause de la dualité publique/privée sur les segments L2 locaux présent derrière la freebox (problème de sécurité, les machines se retrouvent avec 1 ipv4 privée + 1 ipv6 publiques sur le même segment ethernet, de faite exposés à internet..!!)

Les machines portent des ULA
Les firewalls (qui font routers) sont exposés à internet et portent les GLA, puis filtrent le trafic pour passer d'internet aux réseaux rfc1918 (en v6) sur fc00/7, ce qui permet d'analyser le trafic au passage, tant au niveau logique que physique (impossible sur le même L2, donc impossible avec des GLA sur un segment L2 local)
Le tout histoire d'avoir un minimum de sécurité et de rupture de flux car la dualité ipv4 privée / ipv6 publiques sur le même segment L2 est en réalité une exposition directe à internet de toutes les machines qui historiquement étaient "cachées" par un router nat en ipv4 (du pain béni pour tous les kiddies du darknet qui jouent des exploits sans même savoir ce qu'ils font)

Le protocole Ethernet (OSI-L2) ne possède en lui même aucune sécurité et seul l'escalade des couches OSI permet d'ajouter des fonctionnalités de sécurité.

IPv6 à été conçu pour apporter à minima la même sécurité qu ipv4, ce qui n'est pas le cas quand on mélange ipv6 publiques et ipv4 privéees sur le même segment OSI-L2 (particulièrement lorsque ce segment est présent entre 2 routers et qu'en ipv4 le segment est privé alors qu'il est publique en ipv6).
À noter que la segmentation logique n'est réellement efficace que sur des segments physiques isolés/dédiés, et un simple tcpdump sur n'importe quel L2 permet de TOUT capturer, donc si sur un même L2 sont montés des subnets privés et publiques, une capture promiscuous casse instantanément la pseudo isolation L3 et permet de tout voir…
Dans le cas des Freebox cela peut être assez catastrophique car de l'IOT comme un frigo connectés présent sur le LAN ipv4 se retrouve dans cette configuration directement accessible en ipv6 sur le WAN … alors vous me direz à raison que sur un serveur on met un firewall local et on ressert les policies pour se protéger d'internet, mais aujourd'hui je ne sais pas installer nftables ou équivalent sur un asic de 10 millimètres cubes possédant une norme 802.qqch transformant n'importe quel objet du quotidien en un objet connecté ⇒ ces IOT ne doivent jamais et en aucun cas porter des GLA les rendant accessible sur internet, mais ils doivent porter des ULA et être physiquement inaccessible depuis internet (en v4 comme en v6)

Il faudrait que la Freebox apprenne depuis les RA les routes v6 annoncée sur le L2 local lorsque ce n'est pas la freebox qui est le routeur maître (ou qu'on puisse monter une session BGP entre la freebox et le(s) routeurs/firewalls pour populer la table de routage de la box avec la bonne gateway pour les subnets de fc00/7 qu'elle ne gère pas).

Merci encore

Bien cordialement
nbanba

Bonsoir

PS: d'où mon insistance il y a quelques années pour le développement de la tic box "Firewalls IPv6" lorsque avait été retiré de FreeboxOS la possibilité pour l'utilisateur de désactiver complètement l'IPv6

Cordialement
nbanba

Et désolé pour les 'GLA' au lieu de 'GUA' dans mon précédent message.
Je n'avais pas relu avant de poster et ça a été modifié par la correction automatique du téléphone ! Sorry !
Cordialement
nbanba