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

Ajout: j'ai trouvé ceci qui aurait pu être une piste  FS#15045  Mais non car tous mes devices sont bien dans "Machines sans contrôle parental" et le mode de filtrage par défaut est "Accès Internet autorisé"

J'ai l'impression que vous initiez une connexion HTTP sortante sur le port 40 000 mais le serveur envoie ses réponses sur un port inférieur à 49152... donc il envoie ses réponses à vos colocataires IP.

C'est l'explication immédiate que je vois. J'ignore si c'est normal ou pas, mais c'est l'explication qui me parait la plus logique.
Sur la 4G comme vous n'êtes pas en port partagé, le problème ne se pose pas.

Je ne sais pas au juste comment fonctionne le protocole HTTP, mais non le port de retour des données n'est pas forcément égal au port sortant, et c'est même rarement le cas en fait.
Sur les journaux de firewall on ne visionne pas forcement le flux retour car il est présumé autorisé automatiquement via le Stateful Packet Inspection.
Il faut des journaux plus fin qui loguent le trafic à un niveau "paquet"

Je comprends le souci de pénurie d'IPV4 mais ce truc de port partagé à mon avis ça doit foutre un sacré bordel... aujourd'hui plus ou moins masqué par le fait que désormais c'est l'IPv6 qui est natif chez Free. Les ordinateurs vont donc se connecter prioritairement en IPv6 et se délester en IPv4 si ça ne marche pas, et non l'inverse.

D'ailleurs à se demander si certains soucis mentionnés sur ce forum lié à des histoires d'agrégation ADSL/4G n'aurait pas un rapport avec ça....

Il y a une solution définitive :

PASSEZ VOS REQUETES EN IPV6, Free vous l'offre gratuitement en natif désormais
Comme actuellement il est impossible d'ouvrir un port en IPv6, il vous faudra d'abord désactiver le l'option pare-feu IPv6 au niveau de la Freebox de votre association.

Pas de panique, votre serveur doit avoir son propre firewall IPv4 / Ipv6, donc vous n'êtes pas les "fesses à l'air", sauf si vous avez désactivé ce pare feu bien entendu, auquel cas, ce n'est pas bien du tout. IPv6 signifie PAR-FEU OBLIGATOIRE. Il vous suffira d'ouvrir le port au niveau du pare feu serveur.

De toutes les façons, on y viendra tous car la la pénurie des adresses IPv4.... on y est ... du moins presque.

Perso quand j'ai migré en 10 GB, ils m'ont basculé en IPv4 partagée (j'étais en full stacks au départ car je n'étais pas en zone moyennement dense), mais le jour même j'ai immédiatement fait ma demande d'IPv4 full stacks, la demande a été traitée en ligne en... 20 minutes seulement.... changement d'IPv4, pas eu besoin d'attendre 1 semaine.

Je garde jalousement cet IPv4 comme un bien précieux... même si en fait pour monter mes serveurs je raisonne désormais IPv6 IPv6 et IPv6

Déjà l'IPv6 c'est plus pratique.... on assigne une adresse IP spéficique à chaque appareil
l'IPv6 c'est relou de prime abord, mais une fois que vous avez compris vous vous rendez compte que ça a plus de potentiel que l'IPv4

Après héberger un site Web sur une connexion Free.... OK si le site Web n'est pas un site en accès publique (par exemple Intranet).
Si c'est un site Web en accès publique.... vous allez vous retrouver un beau matin à l'assoc avec des connexion qui vont ramer car des petits rigolos vont décider de lancer des attaques DOS juste pour le fun.

Un hébergement et un nom de domaine.... c'est je crois 9 EUR par an chez OVH, donc franchement....

Bonjour Wozzeck,

Tout d'abord merci pour toutes ces informations.

J'imagine qu'au niveau du port client (sur la Freebox de mon domicile) le choix du port à l'initialisation de la connexion est toujours bon et permet de sortir, si non quelque soit le serveur appelé (même sur les ports standards 80, 443) le problème se produirait régulièrement.
Donc on va dire que le port client (Freebox domicile) est dans la plage 32768-49151

Réf: même si la règle voudrait que la plage de port client soit 49152-65535 mais j'imagine que la Freebox Server est adaptée aux IP partagées mises en place par Free
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Si je comprend bien la supposition:

• /1/ la requête part de mon domicile

— IP:port de destination : freebox.asso:40 000
— IP:port client: freebox.domicile:32768-49151
Rien n'empêche la requête de partir.
Donc elle devrait continuer son chemin jusqu'au serveur via Internet.

• /2/ la requête arrive sur le serveur

Je devrai être capable de la voir dans les journaux de logs, mais ce n'est pas le cas.
NB: j'ai positionné un nginx tout bête sur un port 40 xxx et je n'ai pas de logs quand j'appelle via freebox.domicile (j'ai les logs en 4G)

Et si ce n'était pas déjà bloqué jusque là:

• /3/ le retour de la requête part du serveur

Le serveur devrait envoyer sa réponse sur IP:port client mentionné en /1/
J'imagine en passant par le port 40 000.
Et si non alors Freebox de l'association doit choisir un port qui lui permet de sortir (comme quand elle affiche http://www.free.fr port 80, alors que 80 est hors de sa plage 49152-65535)
Donc ça devrait sortir

• /4/ le retour de la requête arrive à mon domicile

Comme IP:port de retour est la connexion client initiée par ma Freebox domicile, le retour est accepté et servi au device.
Ce qui est le cas lors de l'appel à n'importe quel site Web même sur les ports http (80) et https (443)

Réf: le port de retour doit bien être le 40 000
https://blogs.getcertifiedgetahead.com/controlling-protocols-ports-traffic/

Du coup au final je ne vois toujours pas ce qui peut bloquer et si c'est à la sortie de ma Freebox domicile ou à l'entrée de la Freebox de l'association.

Cordialement

PS:
Nous avons un site public chez un hébergeur. Mais pour le cas particulier mentionné c'est une autre solution, qui ne peut qu'être hébergée que par nous même (machine fournie et configurée par un prestataire).
Donc je ne sais pas trop ce qu'il y a dedans, alors IPv6 etc .... je n'ai pas trop envie de m'engager sur ce chemin. :-p
( et je ne fais qu'apporter un peu d'aide à l'association )
C'est comme cela depuis plusieurs années, mais c'est un autre débat :-p
Si je n'arrive pas à résoudre, nous devrons tenter de revenir en IP full stack ... sans garantie de résultat.

gestion de la box via l'application Freebox sur iOS (port 38 443)

Pour pouvoir accéder à la box depuis l'extérieur (et pas juste en local), le port choisi doit être dans la plage attribuée à la freebox.
Les ports 38 et 443 ne permettront donc pas un accès à la box depuis l'extérieur.

Si je comprends bien,
- tu as un site web sur quelque chose comme http://monsite.web:40000/ - depuis une freebox fibre en IP partagée (ports entrants 49152-65535) : tu n'as pas accès à ce site
- depuis une autre connexion Free, Orange, Bouygues, SFR et/ou mobile : tu as généralement accès à ce site, sur ce port
C'est bien ça ?

Pour pouvoir avoir des réponses plus détaillées à ton souci, pense à fournir :
- la MAC de server Freebox
- la MAC du server de l'association

Bonjour rr,

Oui c'est bien ça.
Tout m'indique que le site (port 40000) fonctionne correctement et pourtant il peut arriver, comme depuis mon domicile via ma Frebox, de ne pouvoir y avoir accès.
Je n'arrive pas à avoir de piste pour savoir où ça bloque (chez moi ou à l'association) et donc comment résoudre.

Voici les adresse MAC :

Freebox domicile: Fibre optique, IP partagée, plage de port 49152-65535, MAC 68:A3:78:75:23:14
Freebox association: ADSL, IP partagée, plage de ports 32768-49151, MAC 14:0C:76:72:15:A7

PS: J'ai bien choisi à chaque fois des ports compris dans la plage attribuée à la Freebox association (32768-49151)
L'accès pour l'application Freebox sur iOS est sur le port 38443 (j'avais noté "38 443" pour faciliter la lecture)
Le site de l'association sur 40000 (sur un PC) et un autre pour test sur le port 40314.

Bonjour Maxime,

En effet j'ai demandé une IP full stack puisque je n'avais aucune info me permettant de résoudre le problème (comme par exemple des logs de filtrage du NRA ou de la freebox, pour savoir jusqu'où cheminait l'appel).

Dès que l'IP full stack a été attribuée, je n'ai plus eu aucun problème pour accéder au site Web de l'association ou à la box via l'application Freebox sur iOS. Pareil pour les quelques adhérents qui étaient dans mon cas (pas forcément depuis des Freebox).

Il ne s'agit pas d'une correction dans un firmware, car l'affectation d'une IP full stack a résolu le problème sans aucun upgrade firmware.
Ce qui me semble le plus logique, c'est qu'avec une IP partagée certaines requêtes sont filtrées par erreur en fonction de quelque chose envoyé ar le client (même si le port appartient à la plage attribuée). Bien entendu, invérifiable.