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

après connexion via openvpn en mode bridgé, accès impossible au reseau privé pour atteindre le disque dur externe

Bonjour,

Lors de la modification du Freebox serveur du mode routeur vers le monde bridge, il y a différentes informations sur les conséquences de cette modification.

Cependant il n’y aucune mention sur le fait que les applications Freebox connect et Freebox files ne seront plus utilisables.

Pourriez vous svp ajouter ces infos pour que tout le monde soient prévenu ?

Merci

Bonjour,

Je viens d’installer un système mesh tp-link deco BE85 derrière ma Freebox Ultra que j’ai passé en mode bridge.

Problème (à définir si côté routeur tp-link ou freebox) : parfois, quand je redémarre le tp-link, l’uplink (en SFP+) reste au rouge (rien concernant la connexion de l’uplink dans ses logs). Un simple reboot de la freebox le fait passer au vert sans même redémarrer ce dernier.
Routeur tp-link uplink param pour récup l’IP pub en DHCP (je viens de la fixer pour voir si c’est pareil)

Possible de regarder les logs de ma Freebox vers 6h45 ce jour pour voir si vous voyez un truc s’il vous plaît ? S’ils ne sont pas effacés après un reboot…

MAC : 38:07:16:CC:69:CF

Concernant, l’IPv6, je l’ai désactivé pour le moment côté tp-link. Dans les choix j’ai IP dynamique, PPPoE, Tunnel 6to4, Pont. Je suppose que je dois choisir Pont et ne rien toucher dans les param IPv6 de la Freebox à part juste bien activer le firewall ? Rien dans Delegation de préfixe à mettre vu que je ne peux pas conf l’IPv6 en fixe sur le tp-link ?

Merci, bonne journée.

Bonjour,

J’ai passé ma Freebox POP v8 (4.9.4) en mode bridge depuis 1 mois. Je dispose d’une adresse IPv4 full-stack depuis longtemps.

Cependant je rencontre maintenant des pertes de connexion vers Internet tous les 3-4 jours approximativement.
Derrière la Freebox (sur le port 2.5g) j’ai branché un firewall Sophos.

Lorsque la perte de connexion intervient, le Sophos ne parvient plus à accéder à la Gateway en .254 de la Freebox. Le lien physique est bien actif.
L’adresse IP publique est toujours accessible depuis l’extérieur mais cela s’arrête à la Freebox. Je n’ai pas accès aux services interne.

Par contre j’ai toujours accès à la Freebox à travers les applications Freebox et Freebox Connect ce qui me permet de redémarrer la Freebox et de résoudre le problème mais cela se reproduit tous les 3 -4 jours

En mode routeur, aucun soucis mais j’ai vu quelques problèmes similaires sans résolution pour le moment.

C’est difficilement utilisable dans ce mode Bridge.
Merci d’avance et bonne journée.

Bonjour,

Depuis que j’ai configuré ma Freebox POP S en mode bridge, avec un routeur OpenWRT derrière, nos smartphones ne parviennent plus à utiliser le service VoWiFi à domicile. Cela pose un réel problème, car la couverture mobile est très faible chez nous, et nous dépendons fortement du VoWiFi pour passer des appels.
Mon routeur OpenWRT est configuré correctement, avec le support complet d’IPv4 et d’IPv6, et les deux protocoles fonctionnent sans problème depuis nos téléphones.

À ce stade, je me pose les questions suivantes :

- S’agit-il d’un bug ou d’une limitation du côté de Free ?
- Y a-t-il une configuration spécifique à appliquer de mon côté pour rétablir le service ?

Merci d’avance pour votre aide.

Je trouve plusieurs tickets concernant l’activation du LACP, et je trouve la réponse “ça ne servirait à rien vous ne saturerez jamais le lien router⇔freebox un peu obsolète dans la mesure où le débit fibre est maintenant supérieur à 2.5Gbps avec la Pop.
On commence à trouver aujourd’hui pas mal de routeurs capables de supporter du LACP sur un port WAN 2.5GB + Ethernet 1GB, et il serait plutôt sympa d’avoir la possibilité d’en bénéficier avec la Freebox POP, en mode bridge uniquement par exemple, pour pouvoir encaisser des pics de trafic.
Je suis très satisfait de ma connexion fibre et des performances générales de la POP (que j’utilise en bridge avec un routeur wifi 6 Orbi, très bon combo), le support du LACP serait la cerise sur la gâteau fort appréciée.

Merci de prendre cela en considération!

Bonjour,
Je ne comprends pas pourquoi lorsque nous sommes en mode bridge, l’adresse fd0f:ee:b0::1 n’est pas accessible par le réseau local.
Mon routeur interne récupère est paramétré en SLAAC sur le port de la freebox bridge pour la partie WAN et en SLAAC sur la partie LAN également.
Pourquoi il n’est pas possible d’acceder à cette adresse multicast fd0f:ee:b0::1 ? Sans elle pas de flux RASH.
Alors qu’il n’y a pas de souci avec l’adresse multicast 212.27.38.253 en ipv4.
Pour info j’ai ouvert l’icmpv6 (pour accès MLD) entierement sur mon reseau pour faire le test mais cela ne passe pas.
Merci de votre retour,

Afin de résoudre certains problèmes d’adressage/routage etc. (IPv4/IPv6), de bridge et bien plus, je redemande la mise à jour de iproute2, actuellement, dans Freebox OS 4.9.1 : 6.6.0 (2023-11-04).

- https://wiki.linuxfoundation.org/networking/iproute2
- https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2/
- https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
- https://github.com/iproute2/iproute2
- https://github.com/iproute2/iproute2/tags

Note importante : bridge-utils a été intégré dans iproute2.

Les Freebox ont seulement la 1.5 de 2011 mais il existe une version 1.7.1 (2021-03-22) :
→ https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/

Je pense qu’il est temps de supprimer bridge-utils 1.5 (pas à jour) des Freebox Server.

Les fonctions ont été intégrées dans iproute2.

Merci d’avance.

Bonjour,

J’ai repéré un comportement très étrange sur le bridge réalisé par Freebox entre un client wifi et une cible filaire.
(donc sur un traffic uniquement à l’intérieur du LAN de la Freebox)

Voici la situation simple pour reproduire:
1) Un client qqconque en wifi connecté sur la Freebox Pop (F-GW08D)
2) Une machine “serveur” qqconque branchée en ethernet (directement sur la freebox)

Il suffit de ping le “serveur” depuis le client wifi.
Alors, les requêtes ARP arrivent bien sur le serveur, mais avec une longueur anormalement grande, cf:

clientwifi$ ping 192.168.8.14
PING 192.168.8.14 (192.168.8.14): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
Request timeout for icmp_seq 0

serveur# tcpdump -i igb0 -nn -vvve arp
21:01:59.377399 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 50

⇒ 64 bytes ici (vs 60 bytes normalement)

Une analyse avec wireshark (toujours du coté du serveur) montre un FCS ou un padding (suivant l’heuristique d’analyse choisi) anormal de 4 bytes: 0×00000000 qui semble ajouté sur la couche ethernet de toutes les requêtes ARP qui sont passés par la Freebox en wifi.

Ma conclusion:
⇒ le bridge de la freebox “modifie” (+4 bytes) les trames ARP lorsqu’elles transitent depuis le coté wifi vers les ports ethernet, ce qui les rends non standard
⇒ bug de la freebox ?

Important: le mot “bridge” que j’utilise ici n’a rien à voir avec le fameux “mode bridge”, car je parle du “switch” (layer 2) fait par la freebox entre les différentes partie du LAN (wifi & ports ether).
NB: ma Freebox est en mode “routeur” comme par défaut, et il n’y aucun routeur ou autre équipement “avancé” supplémentaire.

Merci d’avance

Bonjour,

Freebox Delta en mode bridge avec connexion locale sur le port SFP+.

J’ai reçu mon backup Freebox 4G, ayant ma fibre inutilisable, mais il n’est malheureusement peu utilisable en l’état:

Apres la premiere connexion, la Freebox Delta l’a bien reconnu, l’affichage dit bien “Backup Internet: Actif”. Du coté de mon routeur, meme en faisant un DHCP renew, aucun changement, il garde l’IP de la connexion fibre et aucun paquet ne passe.

Reboot de la Freebox, après son démarrage, j’obtiens bien une IP différente et j’ai une connexion internet fonctionnelle par la 4G.

Malheureusement, cela ne dure que ~ 10 minutes - 1h avant de se couper, plus aucun paquets.
Pas de message sur l’affichage de la Freebox, toujours “Backup Internet: Actif”. La LED du backup Freebox reste blanc constant.

Redémarrage du backup Freebox: ne fait rien, la Freebox refait bien la procedure de connexion et affiche a la fin “Backup Internet: Actif” mais toujours aucun paquets
DHCP renew sur mon routeur: ne fait rien
Redémarrage de la Freebox Delta: connexion internet par la 4G remarche.

Est ce que je suis passé a coté de quelque chose ou cela est-il un bug?

Cordialement,

Passage d'une revolution+boitier Pon en mode bridge avec un firewall Sophos SG qui fait le routage/vpn a une ultra. En mode routeur+ DMZ la ultra fonctionne mais bloque certains ports ou trafic vers le routeur. En mode bridge, le lien est UP mais en erreur et pas d'internet. Le routeur n'arrive pas a pinger la gateway free alors que la meme config avec une revolution + transceiver Pon ca marche et le routeur peut pinger la passerelle. merci de vos eclaircissements

Bonjour,

Ancien utilisateur de la fibre orange et adepte aux nouvelles technologies, j'ai une maison bien connectée. La box orange, incapable de gérer plus de 20 connexions simultanées était insuffisante pour mon usage. Or, je decide de passer chez free notamment pour pouvoir bénéficier de l'option bridge afin de m'en servir de mon propre routeur plus performant.

La Freebox pop se connect bien au réseau fibre, l'heure s'affiche. Je vais sur l'interface de réglages pour changer de mode routeur vers mode bridge. En mode routeur tout fonctionne, le routeur Netgear que je veux utiliser est connecte par ethernet et tant que la Freebox reste en mode routeur mon Netgear a access internet. C'est lors du passage en mode bridge qu'il n'y a plus d'internet. Le routeur ne détecte aucune connexion malgre être toujours connecte via ethernet. Je teste en branchant le meme cable ethernet connecté sur le Netgear sur mon ordinateur, pareil, pas de connexion internet.

Comment résoudre ce problème?

Bonjour,

J’utilise une Mini 4K sur fibre FTTH et IP V4 fullstack ou est raccordé au LAN de la Mini 4k un routeur ASUS RT-AC88U (firmware ASUS Merlin à jour) qui supporte mon réseau domestique.

Micrologiciel 4.3.2 Freebox Server mini (R2)

* En mode routeur Free, pas de soucis hormis les limitations de l’usage de mon Asus, DDNS ASUS par exemple mais très stable.

* En mode pont (Bridge), c’est inutilisable, grosse pertes de paquets et freeze… reboot multiples et/ou reset usine de la freebox server ne change rien à l’histoire, le retour au mode routeur Free fait disparaître toute instabilité : Aller retour entre les 2 modes routeur/bridge Free effectués multe fois avec le même constat :(

De plus, j’utilise sur mon routeur ASUS mode “DUAL WAN fail over”, en clair j’utilise Free OU un autre fournisseur internet haut débit derrière le routeur ASUS de façon automatisée.

Cet autre fournisseur configuré en mode bridge haut débit fonctionne sans aucun soucis, ça ne fait que confirmer que c’est bien le mode bridge de la Mini 4K qui est en cause !

Je sais qu’il y a d’autres post sur l’implémentation du mode bridge dans les Freebox et des demande de mise à jour notamment de iproute2 et de suppression de codes obsolètes, je ne peux que m’y associer, ensuite est-ce le seul soucis et mon problème fait-il partie de ce sujet ?

Quoiqu’il en soit le mode bridge mini 4k est totalement inutilisable chez moi et ça sent vraiment le bug.

Est-ce un soucis connu et pouvez-vous s’il vous plaît vous pencher sur cette anomalie ? je suis bien sur disponible pour tout test ou fourniture d’autres éléments afin d’investiguer.

Merci par avance.

PYJ

Je viens de perdre deux heures pour comprendre que sur la Ultra le mode Bridge ne fonctionne que sur le port SFP+ !

Ca sent le bugg et ça voudrait dire que le port SFP+ est géré à part.

Hélas le câble SFP+ que j’avais entre la Delta et mon UDM Pro ne fonctionne plus. Merci de ne pas fournir le câble idoine et de ne pas pouvoir réutiliser l’ancien.

J’ai fini par retrouver un très court câble SFP+ de chez Ubiquiti et et la tout est reconnu et fonctionnel mais avec de mauvais débits en UP.

J’ai commandé ce câble https://amzn.to/3TgSuRS qui semble OK d’après les forums.

Ce problème reste à expliquer

Bonjour,

J’aurais voulu savoir s’il était possible d’installer homebridge en VM sur la Freebox ultra, j’ai réussi à installer home assistant mais trop gourmand je l’ai donc désinstallé.

Merci beaucoup

Bonjour,
En utilisant le serveur OpenVPN bridgé, même si on assigne une adresse IP locale fixe au client celle-ci est sous un autre sous-réseau.
Le client n’est pas visible sur le même sous-réseau et son adresse IP locale est affichée 0.0.0.0.
Un freenaute a trouvé la solution avec une longue commande mais ce serait bien si ça pouvait marcher “out of the (free)box”.
https://https://forum.ubuntu-fr.org/viewtopic.php?id=2052651 Merci

Bonjour,

Impossible d’utiliser la Freebox Delta en mode Bridge. Cela rend le réseau complètement inutilisable avec des déconnexions constantes et erreurs DNS.
Obligé de se mettre en mode routeur ce que je ne souhaite pas.

Je résume mes mésaventures avec la Freebox Delta :
- Wifi mesh avec une très mauvaise stabilité et portée (remplacé par un routeur wifi TPlink c’est le jour et la nuit)
- Agrégation 4G qui n’a jamais apporté aucun débit notable, même pendant une période d’un mois où mon débit global était <1Mo à cause d’un mauvais câble (réglé depuis, sachant que 2 freehelpers n’ont absolument rien trouvé d’autre à dire que “tout va bien de notre côté”, heureusement que j’ai trouvé la source du problème tout seul)
- Bugs innombrables sur le player Dévialet, entre les artefacts d’image, le replay qui plante, le airdrop qui ne fonctionne pas, la lecture en dlna capricieuse...
Ca fait cher le player/enceinte sur laquelle on ne peut même pas brancher de casque audio (super pour les malentendants comme moi).

Le mode bridge qui ne fonctionne pas c’est un peu la goutte d’eau qui fait déborder le vase...
Merci 1000 fois à qui aura une solution ou au développeur qui réparerait ça pour la prochaine mise à jour !

Bonjour,

Tentant de placer un UDM PRO SE derrière ma Freebox Server et ayant configuré un VLAN 100 sur cet UDM comme sur ce schéma, je me rend compte que l'UDM PRO "perd Internet", comme si cela posait un soucis au "switch" de la Freebox que d'avoir 2 connexions. Un problème sur la Freebox quand elle est en mode bridge ?

//img.community.ui.com/26e57516-7b0c-403f-91e6-b18ecc4938f3/answers/f9df1eac-6ed8-4135-9c6d-aa9b17f7ee22/e9e2faa9-f94f-44e4-afc4-6bf5750ef541

Merci pour votre retour,

Bonjour,

Je tente de raccorder deux freebox server (une Révolution et un Mini, j’utiliserai ces noms pour distinguer le server et le client OpenVPN) dans l’optique de fusionner les deux LAN sur le même subnet (192.168.0.*) en utilisant OpenVPN en mode Bridge.

Je configure donc le Mini en tant que server, créé un utilisateur spécifique pour cette connexion et charge le fichier de configuration généré par le Mini dans le client VPN de la Révolution. Première erreur : il faut commenter la ligne dev-type tap qui empêche au client de la Révolution de charger le fichier le configuration (et aussi tls-remote qui n’est plus nécessaire et génère un warning dans les logs).

Une fois le fichier de configuration corrigé et chargé, toute tentative de connection retourne une erreur Bad local IP dont ne je n’ai pu trouver aucune référence sur le net (autre qu’une erreur de pppd). Le log indique aussi que le client tente la requête avec dev-type tun (puisque je l’ai commenté dans le fichier de config).

Log complet :

2015-08-13 14:26:18 l2 state change ‘l2_down’ ⇒ ‘l2_down’
2015-08-13 14:26:18 l3 state change ‘l3_down’ ⇒ ‘l3_down’
2015-08-13 14:26:18 state change ‘down’ ⇒ ‘down’
2015-08-13 14:26:18 enabling connection
2015-08-13 14:26:18 state change ‘down’ ⇒ ‘wait_l2_up’
2015-08-13 14:26:18 l2 state change ‘l2_down’ ⇒ ‘l2_up’
2015-08-13 14:26:18 state change ‘wait_l2_up’ ⇒ ‘l2_up’
2015-08-13 14:26:18 state change ‘l2_up’ ⇒ ‘wait_l3_up’
2015-08-13 14:26:18 l3 state change ‘l3_down’ ⇒ ‘l3_start’
2015-08-13 14:26:18 starting
2015-08-13 14:26:18 calling helper script at ‘/etc/fbxconnman/conn.pre-up’
2015-08-13 14:26:18 l3 state change ‘l3_start’ ⇒ ‘l3_wait_preup_helper’
2015-08-13 14:26:18 l3 state change ‘l3_wait_preup_helper’ ⇒ ‘l3_wait_stable’
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 OpenVPN 2.3.2 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 24 2015
2015-08-13 14:26:18 openvpn: connected to management interface
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: Connected to management server at unix_mgt.sock
2015-08-13 14:26:18 openvpn: rx: >INFO:OpenVPN Management Interface Version 1 – type ‘help’ for more info
2015-08-13 14:26:18 openvpn: rx: >HOLD:Waiting for hold release
2015-08-13 14:26:18 openvpn: tx: hold release
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘hold release’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: hold release succeeded
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘state on’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: real-time state notification set to ON
2015-08-13 14:26:18 openvpn: rx: >PASSWORD:Need ‘Auth’ username/password
2015-08-13 14:26:18 openvpn: tx: username “Auth” “[user]”
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘username “Auth” “[user]”’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: ‘Auth’ username entered, but not yet verified
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘password [...]’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: ‘Auth’ password entered, but not yet verified
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,WILL_CONNECT,[IP],,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Socket Buffers: R=[172032→131072] S=[172032→131072]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 UDPv4 link local: [undef]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 UDPv4 link remote: [AF_INET][IP]:[PORT]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,WAIT,,,,,,0
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,WILL_CONNECT,[IP],,,,,0
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,WAIT,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,AUTH,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 TLS: Initial packet from [AF_INET][IP]:[PORT], sid=7f32f5b5 869df738
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,AUTH,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY OK: depth=1, C=FR, O=Freebox SA, CN=Freebox OpenVPN server CA for […]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Validating certificate key usage
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 ++ Certificate has key usage 00a0, expects 00a0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY KU OK
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Validating certificate extended key usage
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY EKU OK
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY OK: depth=0, C=FR, O=Freebox SA, CN=Freebox OpenVPN server […]
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘dev-type’ is used inconsistently, local=’dev-type tun’, remote=’dev-type tap’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1557’, remote=’link-mtu 1589’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1500’, remote=’tun-mtu 1532’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Encrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Decrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 [Freebox OpenVPN server […]] Peer Connection Initiated with [AF_INET][IP]:[PORT]
2015-08-13 14:26:20 openvpn: rx: >STATE:1439468780,GET_CONFIG,,,,,,0
2015-08-13 14:26:20 openvpn: output: Thu Aug 13 14:26:20 2015 MANAGEMENT: >STATE:1439468780,GET_CONFIG,,,,,,0
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 SENT CONTROL [Freebox OpenVPN server […]]: ‘PUSH_REQUEST’ (status=1)
2015-08-13 14:26:21 openvpn: rx: >STATE:1439468781,CONNECTED,SUCCESS,,[IP],,,1500
2015-08-13 14:26:21 openvpn: bad local ip
2015-08-13 14:26:21 l3 is now stable
2015-08-13 14:26:21 l3 does not fulfil config requirement
2015-08-13 14:26:21 l3 state change ‘l3_wait_stable’ ⇒ ‘l3_bring_down’
2015-08-13 14:26:21 waiting for l3 providers to go down
2015-08-13 14:26:21 l3 state change ‘l3_bring_down’ ⇒ ‘l3_wait_down’
2015-08-13 14:26:21 l3 state change ‘l3_wait_down’ ⇒ ‘l3_cleanup_start’
2015-08-13 14:26:21 calling helper script at ‘/etc/fbxconnman/conn.post-down’
2015-08-13 14:26:21 l3 state change ‘l3_cleanup_start’ ⇒ ‘l3_wait_postdown_helper’
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 PUSH: Received control message: ‘PUSH_REPLY,ping 30,ping-restart 120’
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 OPTIONS IMPORT: timers and/or timeouts modified
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 Initialization Sequence Completed
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 MANAGEMENT: >STATE:1439468781,CONNECTED,SUCCESS,,[IP],,,1500
2015-08-13 14:26:21 l3 state change ‘l3_wait_postdown_helper’ ⇒ ‘l3_cleanup_finish’
2015-08-13 14:26:21 l3 state change ‘l3_cleanup_finish’ ⇒ ‘l3_finished’
2015-08-13 14:26:21 state change ‘wait_l3_up’ ⇒ ‘wait_l3_down’
2015-08-13 14:26:21 l3 state change ‘l3_finished’ ⇒ ‘l3_down’
2015-08-13 14:26:21 state is now DOWN
2015-08-13 14:26:21 state change ‘wait_l3_down’ ⇒ ‘l3_finished’
2015-08-13 14:26:21 state change ‘l3_finished’ ⇒ ‘wait_l2_down’
2015-08-13 14:26:21 l2 state change ‘l2_up’ ⇒ ‘l2_cleanup’
2015-08-13 14:26:21 l2 state change ‘l2_cleanup’ ⇒ ‘l2_down’
2015-08-13 14:26:21 state change ‘wait_l2_down’ ⇒ ‘down’

Lorsque le Serveur est en mode bridge, le mDNS émis par le Player pollue les log des routeurs/firewall placés en aval du Serveur ce qui génère de fausses alertes d’usurpation d’IP.
Un simple switch pour activer/désactiver le mDNS du player serait la bienvenue.

D’avance merci !

Après avoir téléchargé la configuration OpenVPN bridgé depuis la freebox, puis l’avoir importé dans un client OpenVPN sous Windows 10, le réseau local de la freebox est bien visible mais par défaut le trafic Internet ne passe pas par le VPN. Les 2 lignes suivantes doivent être ajoutées manuellement dans la configuration générée par la freebox pour que ce soit le cas :

route-gateway 192.168.0.254
redirect-gateway def1

Il serait intéressant que la freebox génère ces lignes directement ou alors qu’une option soit proposée dans la configuration VPN pour les ajouter ou non

Bonjour,

J’essai de faire un lien OpenVPN Bridgé entre deux Freebox (Mini 4K en ADSL et One en FTTH AMI Orange).
Serveur créé sur la One, client sur la mini 4K.

Déja j’ai du effacer la ligne dev-type tap du fichier sinon impossible de l’importer sur Freebox OS.

Ensuite j’ai une erreur interne, avec bad local ip, comme si le client n’arrive pas à obtenir une adresse IP.

Merci pour votre aide, ci joint le log

//d.pr/i/3g5Ukf

2019-05-02 14:14:42 starting
2019-05-02 14:14:42 calling helper script at '/etc/fbxconnman/conn.pre-up'
2019-05-02 14:14:42 l3 state change 'l3_start' => 'l3_wait_preup_helper'
2019-05-02 14:14:42 l3 state change 'l3_wait_preup_helper' => 'l3_wait_stable'
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 OpenVPN 2.3.17 arm-unknown-linux-muslgnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Apr 26 2019
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.09
2019-05-02 14:14:42 openvpn: connected to management interface
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: Connected to management server at unix_mgt.sock
2019-05-02 14:14:42 openvpn: rx: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2019-05-02 14:14:42 openvpn: rx: >HOLD:Waiting for hold release
2019-05-02 14:14:42 openvpn: tx: hold release
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'hold release'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: hold release succeeded
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'state on'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: real-time state notification set to ON
2019-05-02 14:14:42 openvpn: rx: >PASSWORD:Need 'Auth' username/password
2019-05-02 14:14:42 openvpn: tx: username "Auth" "FBX78340"
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'username "Auth" "FBX78340"'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: 'Auth' username entered, but not yet verified
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'password [...]'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: 'Auth' password entered, but not yet verified
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,WILL_CONNECT,91.166.145.220,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Socket Buffers: R=[163840->163840] S=[163840->163840]
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 UDPv4 link local: [undef]
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 UDPv4 link remote: [AF_INET]91.166.145.220:40992
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,WAIT,,,,,,0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,WILL_CONNECT,91.166.145.220,,,,,0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,WAIT,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,AUTH,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 TLS: Initial packet from [AF_INET]91.166.145.220:40992, sid=38ca0eec 073b41c0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,AUTH,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY OK: depth=1, C=FR, O=Freebox SA, CN=Freebox OpenVPN server CA for 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Validating certificate key usage
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 ++ Certificate has key usage  00a0, expects 00a0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY KU OK
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Validating certificate extended key usage
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY EKU OK
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY X509NAME OK: C=FR, O=Freebox SA, CN=Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY OK: depth=0, C=FR, O=Freebox SA, CN=Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1561', remote='link-mtu 1593'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 [Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180] Peer Connection Initiated with [AF_INET]91.166.145.220:40992
2019-05-02 14:14:44 openvpn: rx: >STATE:1556799284,GET_CONFIG,,,,,,0
2019-05-02 14:14:44 openvpn: output: Thu May  2 14:14:44 2019 MANAGEMENT: >STATE:1556799284,GET_CONFIG,,,,,,0
2019-05-02 14:14:45 openvpn: output: Thu May  2 14:14:45 2019 SENT CONTROL [Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180]: 'PUSH_REQUEST' (status=1)
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 PUSH: Received control message: 'PUSH_REPLY,ping 30,ping-restart 120'
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 OPTIONS IMPORT: timers and/or timeouts modified
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 Initialization Sequence Completed
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 MANAGEMENT: >STATE:1556799286,CONNECTED,SUCCESS,,91.166.145.220,,,1500
2019-05-02 14:14:46 openvpn: rx: >STATE:1556799286,CONNECTED,SUCCESS,,91.166.145.220,,,1500
2019-05-02 14:14:46 openvpn: bad local ip
2019-05-02 14:14:46 l3 is now stable
2019-05-02 14:14:46 l3 does not fulfil config requirement
2019-05-02 14:14:46 l3 state change 'l3_wait_stable' => 'l3_bring_down'
2019-05-02 14:14:46 waiting for l3 providers to go down
2019-05-02 14:14:46 l3 state change 'l3_bring_down' => 'l3_wait_down'
2019-05-02 14:14:46 l3 state change 'l3_wait_down' => 'l3_cleanup_start'
2019-05-02 14:14:46 calling helper script at '/etc/fbxconnman/conn.post-down'
2019-05-02 14:14:46 l3 state change 'l3_cleanup_start' => 'l3_wait_postdown_helper'
2019-05-02 14:14:46 l3 state change 'l3_wait_postdown_helper' => 'l3_cleanup_finish'
2019-05-02 14:14:46 l3 state change 'l3_cleanup_finish' => 'l3_finished'
2019-05-02 14:14:46 state change 'wait_l3_up' => 'wait_l3_down'
2019-05-02 14:14:46 l3 state change 'l3_finished' => 'l3_down'
2019-05-02 14:14:46 state is now DOWN
2019-05-02 14:14:46 state change 'wait_l3_down' => 'l3_finished'
2019-05-02 14:14:46 state change 'l3_finished' => 'wait_l2_down'
2019-05-02 14:14:46 l2 state change 'l2_up' => 'l2_cleanup'
2019-05-02 14:14:46 l2 state change 'l2_cleanup' => 'l2_down'
2019-05-02 14:14:46 state change 'wait_l2_down' => 'down'

Bonjour,

Suite à l’utilisation du serveur OpenVPN en mode bridgé sur ma freebox V6 (le poste distant utilisant le client OpenVPN Windows), j’ai un débit descendant (du PC distant vers ma freebox) très bon (environ 10Mo/s), alors qu’en montant ce débit est très faible (environ 70ko/s).

J’ai tenté de changer de port, forcé en UDP, changé de mode de chiffrement, sans aucun succès.

J’ai constaté ce problème depuis 2 freebox différentes (donc sur 2 lignes différentes), dans les mêmes proportions.

Après une recherche sur Internet, j’ai trouvé cette explication : http://winaero.com/blog/speed-up-openvpn-and-get-faster-speed-over-its-channel/

Malheureusement pour corriger ce problème il faut modifier le fichier “server.conf” du serveur OpenVPN, chose que nous n’avons pas moyen de faire (et cela me parait normal).

Je voulais donc savoir dans quelles mesures ce fichier pouvait être modifié.

Je vous remercie,
Cordialement,
BENUR

Il semble que l’adresse fd0f:ee:b0::1 n’est pas up en mode bridge, ce qui ne permet pas d’acceder à la freebox tant qu’il n’y a pas de synchro.

Je peux utiliser l’adresse link local mais ca pose des problèmes pour la router

BTW quel est le MTU pour cette addresse 1500 ou 1480 ?

ip addr
...
31: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default qlen 1000

  link/ether 14:cc:20:0c:78:5e brd ff:ff:ff:ff:ff:ff
  inet6 fd0f:ee:b0::2/64 scope global 
     valid_lft forever preferred_lft forever
  inet6 fe80::16cc:20ff:fe0c:785e/64 scope link 
     valid_lft forever preferred_lft forever

...

ip route get fd0f:ee:b0::1
fd0f:ee:b0::1 from :: dev eth0 proto kernel src fd0f:ee:b0::2 metric 256 pref medium

ping6 fd0f:ee:b0::1
PING fd0f:ee:b0::1 (fd0f:ee:b0::1): 56 data bytes

— fd0f:ee:b0::1 ping statistics — 3 packets transmitted, 0 packets received, 100% packet loss

socat - tcp6-connect:[fd0f:ee:b0::1]:80
GET /
2017/01/07 16:21:46 socat[18667] E connect(5, AF=10 [fd0f:00ee:00b0:0000:0000:0000:0000:0001]:80, 28): Host is unreachable

ping6 fe80::XXX:78ff:fe1c:2b77%eth0
PING fe80::XXX:78ff:fe1c:2b77%eth0 (fe80::6aa3:78ff:fe1c:2b77%eth0): 56 data bytes
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=0 ttl=64 time=0.494 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=1 ttl=64 time=0.465 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=2 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=3 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=4 ttl=64 time=0.417 ms

socat - tcp6-connect[fe80::XXX:78ff:fe1c:2b77%eth0]:80
2017/01/07 16:24:42 socat[18794] E unknown device/address “tcp6-connect[fe80::XXXX:78ff:fe1c:2b77%eth0]”

root@OpenWrt:~# socat - tcp6-connect:[fe80::XXXX:78ff:fe1c:2b77%eth0]:80
GET /
<!DOCTYPE HTML>

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="user-scalable=no,width=640" />
    <title>Freebox OS</title>
    <link rel="stylesheet" href="resources/css/ext-theme-classic.css?v=6fc705ae37cb6900959981efd00a2c07d28b9c34">
    <link rel="stylesheet" href="resources/css/btn.css?v=f69a1aa3c216108c791625a61937dc3c640a4cdf">
    <link rel="stylesheet" href="resources/css/fbx.css?v=f06254ed6d39675d818e6f4cab9d30a675bc2d61">
    <script type="text/javascript">//<![CDATA[
        FbxConf = {};
        FbxConf.apiBaseUrl = '/api/v3/';
        FbxConf.uploadBaseUrl = '/api/v3/upload/';
        FbxConf.csrfToken = '';
        FbxConf.firmwareVersionMajor = '3';
        FbxConf.firmwareVersionMinor = '3';

        var _paq = _paq || [];
        _paq.push(["trackPageView"]);
        _paq.push(['setCustomVariable', 1, 'FromExt', '0', 'page']);

        FbxFilenames = {
          "expressInstall": "expressInstall.swf?v=1c12004633e89d6de3bbe4a190093a537bdecebe",
          "hlsplayer": "hlsplayer.swf?v=95b2f91b30e78015a68202ac95f65a9be7d0acc9",
        };

    //]]></script>
    <script src="resources/js/freeboxos.min.js?v=21599b783dddcd2de0e32449ea236c1b13e2394e"></script>
    <script src="resources/js/jquery.min.js?v=bfa700339185fcaa1b8388a62eb3285461f7dcb9"></script>
    <script src="resources/js/swfobject.min.js?v=760434d819abc468eb420ccd7df39198cbf6a638"></script>
</head>
<body>
</body>

Bonjour,

Actuellement en train de configurer mon réseau interne avec un routeur/firewall, je souhaitais utiliser la freebox en mode Bridge mais je me heurte à 2 problèmes.

Tout d’abord, un fois le mode Bridge activé, je n’accède plus par FTP au disque du Freebox Server depuis l’extérieur.
Aussi, mon réseau local, certes sur un autre réseau, n’accède plus au NAS du Freebox Server.

Si je repasse la Freebox en mode Routeur + DMZ vers mon routeur personnel, tout refonctionne.

Est-ce une anomalie récente ?

Car j’ai pu trouver différents sujet sur le net dont un article du site de l’assistance Free dans lequel le mode Bridge est censé permettre l’accès au NAS via \\mafreebox.freebox.fr mais il n’en est rien.
De même, le FTP n’est pas censé être inaccessible et pourtant, j’attéri directement sur mon routeur qui pour le moment ne dispose pas de FTP sur son réseau.

Même chose pour l’accès à l’interface FreeboxOS qui est renvoyée vers le routeur depuis le Web, heureusement l’application fonctionne :)

Merci pour vos réponses.

Cdt,