La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Bbox par un routeur => Discussion démarrée par: thomas_zech@thomaszech.fr le 27 mai 2020 à 13:46:35
-
Bonjour,
j'ai deux fortigate un 30 E et un 60 D
je voudrais savoir comment configrer l'accès internet sans sa bbox de boygues
j'ai dja mit sur l'interface vlan du fortigate l'adresse mac de la bbox ainsi que le vlan 100 , mais je n'ai rien qui arrive pas d'adresse ip et pas de connexion à internet possible.
Aurriez vous une idée car je ne sais plus quoi faire pour ce que celà fonctionne.
J'ai pus le faire avec un sophos utm SG115 donc je suis sur qu'il est possible de le faire avec un fortigate / fortinet
Merci pour votre retour. Thomas
-
Bonjour,
VLAN 100 et DHCP, pas besoin de quoi que ce soit d'autre.
Par contre il faut attendre un peu que le bail DHCP expire, car il doit être lié à la MAC du Sophos peut-être.
-
Oui, pendant 1h au maximum, si le bail n'est pas libéré correctement, seule la même adresse MAC peut s'authentifier.
-
tu peux m'en dire plus car j'ai mit sur l’interface du fortigate 60 D Wan2 après création d'une interface virtuelle avec le vlan 100 et l'adresse mac de la bbox mais celà tourne dans le vide sans trouver une ip bouygues
Merci Thomas
-
Bonjour, après plusieurs essai avec mon fortigate 30E, en passant par l'ONT, hier j'ai réussi à avoir internet en mettant direct en IP fixe du FAI.
de même en mettant la passerelle bouygues également en static route
Le souci c'est que au matin, plus internet, donc je vois pas ce qui ne fonctionne pas, réellement.
Sur mon Sophos celà avait parfaitement fonctionné très facilement.
Si une personne peut m’éclairer ? Merci encore
-
En effet la connexion WAN est stable pendant 30 minutes et apres le WAN se deconnecte.
Config en place : VLAN 100 + Spoofed mac address.
Est-ce que Bouygues envoi des requetes regulierement ?
Toute aide ou indice sera apprecie :)
-
Je crois qu'il faut forcément mettre en DHCP, si il n'y a pas de requêtes reçues en face il est probable que ça coupe.
En tout cas, c'est comme ça chez SFR.
-
+1 pour le client DHCP.
L’authentification est faite très souvent par l'@Mac lors de la demande DHCP et attribution IP.
Pas de demande DHCP : couic!
-
Merci beaucoup pour vos réponses.
Aux dernières nouvelles quel est le vendor-class-identifier à utiliser s'il vous plait ? BYGTELIAD ? byteliad_data?
-
Aucun.
-
Etrange car j'ai essaye plusieurs fois le mode DHCP sur interface WAN avec VLAN 100 avec mac spoof mais toujours sans succes...
-
Arrête de spoof la MAC, juste branche, attend au moins 1h que le bail se libère et ça devrait fonctionner.
-
Meme en attendant 1h et sans spoof la mac pas de reponse DHCP venant de Bouygues....
-
Possible d'avoir le résultat d'un config sys int / show ?
-
Bonjour,
Meme souci ici, sur un Forti 30 E, j'ai essayée en spoofant la mac et sans et en patientant 1h à chaque essai... j'ai aussi essayée sur le valn200
Voici ma conf (je n'ai mis que la partie WAN)
end
edit "wan"
set vdom "root"
set mode dhcp
set type physical
set role wan
set snmp-index 1
next
edit "VLAN100"
set vdom "root"
set mode dhcp
set role wan
set snmp-index 8
set interface "wan"
set vlanid 100
next
-
La conf est bonne, quelle est la version de l'OS ? Je suis sur la 6.4.0 mais ça fonctionnait aussi avec la branche 6.2.X ainsi que la 6.0.4 à l'époque.
-
Merci pour ta réponse.
Le 30E n'est pas encore compatible 6.4.0 je suis en 6.2.4. (en tout cas lorsque je regarde sur forticloud l'upgrade path la maj la plus haute qu'il me propose est la 6.2.4 a moins qu'ily ait un autre moyen...)
Edit: j'ai regardé en allant cherché la 6.4 je ne trouve pas le 30E dans la liste...
J'ai cru comprendre en lisant d'autres post que certains utilisateurs étaient encore sur le VLAN200, je ne me souvient plus trop quand j'ai souscrit chez Bouygues mais c’était avant Juillet 2018, est ce que cela se pourrait que je sois encore sur l'infra en 200 ? a priori si j'ai bien suivi en 6.2.4 ont ne peut pas encore changer la vendor class id (dispo qu'à partir de la 6.4) penses tu que cela puisse venir de ca ?
Y'a t 'il un moyen de savoir qu'elle est le bon VLAN à utiliser ?
Edit 2: bon je suis en train de refaire le test, je n'avais peut etre pas laissé assez longtemps l'ONT branché... une petite question au passage car tu m'as l'air bien caler, concernant la static route, il faut renvoyer vers l'interface VLAN ou l'interface WAN (j'ai mis la VLAN mais je suis pas bien certaine...)
Edit 3: Bon j'ai laissé l'ONT branché sur le forti plus de 2h... rien :(
-
Exactement le meme probleme....
-
La 6.4 ne sortira probablement pas pour le 30E. Ce produit est déjà déprécié et remplacé par le 40F. Pas assez de RAM à priori. En tout cas j'ai un 60E en 6.2.3 pour lequel ça fonctionne sans problème.
Normalement le VLAN200 est totalement fini, sur ce forum en tout cas je n'ai vu personne chez qui c'était encore actif.
Vu que c'est du DHCP, la route s'ajoutera automatiquement, pas besoin de la spécifier à l'avance.
Tu as essayé de redémarrer l'ONT alors qu'il est connecté au forti ?
Un test simple permettrait de confirmer ou infirmer un problème au niveau du FGT : Connecter un PC avec le VLAN 100 taggé sur la carte réseau et voir si il récupère l'IP publique.
-
Encore une fois merci pour ton suivi et retour.
Ok je prends bonne note pour la 6.4 et la route.
Oui j'ai essayé de redémarrer FORTi et ONT au bout d'une heure et demi... mais rien...
Je vais essayer de me monter un petit linux dans le weekend pour tester ca
Je vous tiens au courant.
Bonne soirée
Edit: bon en fait j'ai réussi à le faire depuis mon mac, j'ai récupéré l'IP publique au bout de 2 minutes... donc souci sur le FGT... :(
J'ai peut être loupé un truc à force de le bidouiller je vais le reset...
Edit 2: Factory reset de mon forti et downgrade en 6.2.3, je configure mes interfaces : WAN en DHCP + création de l'interface virtuelle (VLAN 100 + role wan + lié à l'interface WAN) >>>> rien :( j'ai meme essayé de changer la vitesse de l'interface wan en 1000full...
bref là je sèche...
-
C'est trop bizarre. Ça vient forcément du FGT, mais c'est tellement simple qu'on ne peut pas se tromper. Essaie avec un autre port que le WAN pour voir ?
-
Pas Con, je vais test ca.
Edit: pas mieu en utilisant une interface LAN...
Effectivement quand je test depuis ma becane c'est tout con...
rappel de ma conf au cas ou ... :
edit "wan"
set vdom "root"
set mode dhcp
set allowaccess ping
set type physical
set role wan
set snmp-index 1
next
edit "VLAN100"
set vdom "root"
set mode dhcp
set allowaccess ping
set role wan
set snmp-index 5
set interface "wan"
set vlanid 100
next
end
j'essaie de faire du debug mais la ca commence vraiment à piquer... :
Quand j'essaie de sniffer sur le VLAN voila ce que je récolte (bon la je comprends pas grand chose , je comprends pas trop ce que viens faire le port UDP 548 ici...)
diagnose sniffer packet VLAN100
interfaces=[VLAN100]
filters=[none]
pcap_lookupnet: VLAN100: no IPv4 address assigned
29.886542 0.0.0.0.68 -> 255.255.255.255.67: udp 548
35.945866 0.0.0.0.68 -> 255.255.255.255.67: udp 548
46.045882 0.0.0.0.68 -> 255.255.255.255.67: udp 548
57.155856 0.0.0.0.68 -> 255.255.255.255.67: udp 548
63.801621 0.0.0.0 -> 224.0.0.1: ip-proto-2 8
96.555864 0.0.0.0.68 -> 255.255.255.255.67: udp 548
136.955861 0.0.0.0.68 -> 255.255.255.255.67: udp 548
178.365861 0.0.0.0.68 -> 255.255.255.255.67: udp 548
188.804840 0.0.0.0 -> 224.0.0.1: ip-proto-2 8
214.725869 0.0.0.0.68 -> 255.255.255.255.67: udp 548
^C
10 packets received by filter
0 packets dropped by kernel
Quand je debug DHCP: (je vais essayer de me pencher la dessus pour comprendre...)
Sending discover!
Send a packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: LA MAC DE MON INTERFACE
add ip udp header
dhcpcd_send_packet,268:result:590, ifinde:16
unregister timer:0x433de08
register timer func=0x1fb129 arg=0x433d7c8 name=send_discover -> send_discover
Allocate a new timer
Registered timer 0x433c0c8 will expiry in 43 secs
timer 0x432c328 expired, take action
Sending discover!
Send a packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: LA MAC DE MON INTERFACE
add ip udp header
dhcpcd_send_packet,268:result:590, ifinde:8
unregister timer:0x432c328
register timer func=0x1fb129 arg=0x433d188 name=send_discover -> send_discover
Allocate a new timer
clairement il se passe rien coté DHCP, normalement il devrait y avoir des DHCPDISCOVER > DHCPOFFER > DHCPREQUEST et DHCPACK ...
-
J'ai pas du tout la même chose :
Unregistered timer func=0x77afa0 arg=0x1423f050 name=bind_lease -> state_renewing
register timer func=0x77afa0 arg=0x1423f050 name=intfs_changed -> state_renewing
Allocate a new timer
Registered timer 0x1420e700 will expiry in 0 secs
timer 0x1420e700 expired, take action
T1 has expired, state renewing.
make request
make dhcp message, code=3
Insert option(255), len(0)
Insert option(53), len(1)
Insert max message len (1458)
Insert option(57), len(2)
Insert requested options
Insert option(55), len(11)
Insert customer options
Insert class ID option
Insert option(60), len(13)
Insert client ID
Insert option(61), len(7)
Insert hostname
Insert option(12), len(10)
get_dhcp_msg_len, 293
too small, extend to 548
Sending request!
Send a packet out.
add hw header
dst hw addr: 00:D0:F6:EC:BD:54
src hw addr: 04:D5:90:CA:43:E4
add ip udp header
dhcpcd_send_packet,268:result:590, ifinde:23
unregister timer:0x1420e700
register timer func=0x77b210 arg=0x1423f050 name=send_request -> send_request
Allocate a new timer
Registered timer 0x14250790 will expiry in 6 secs
timer 0x14250790(send_request -> send_request) will expire in 6 secs
fd 16 can be read now
###############3Receive packet:
len=368
del hw header
ether_type:0800
hw addr from: 00:D0:F6:EC:BD:54
del ip udp header
final dhcp message len:326
DHCP Message received.
parse dhcp options
parse dhcp option buffer (86 bytes)
option[53], len:1
option[54], len:4
option[51], len:4
option[1], len:4
option[3], len:4
option[6], len:8
option[28], len:4
option[61], len:7
option[12], len:10
option[15], len:7
option[42], len:4
option[72], len:4
DHCPACK received
handle received dhcp options!
lease ip:587E8xxx
lease time: 3600, renew: 0, rebind: 0
Ack: expiry 3600 secs renew: 1800 secs rebind: 2700 secs
binding lease
make arp check
Broadcasting ARPOP_REQUEST for 176.139.X.X
Sending arpcheck!
Send an arp packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: 04:D5:90:CA:43:E4
result:60
unregister timer:0x14250790
Unregistered timer func=0x77b210 arg=0x1423f050 name=send_request -> send_request
register timer func=0x77b500 arg=0x1423f050 name=send_arp_check -> send_arp_check
Allocate a new timer
Registered timer 0x14250790 will expiry in 1 secs
timer 0x14250790(send_arp_check -> send_arp_check) will expire in 1 secs
timer 0x14250790 expired, take action
Sending arpcheck!
Send an arp packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: 04:D5:90:CA:43:E4
result:60
unregister timer:0x14250790
register timer func=0x77b500 arg=0x1423f050 name=send_arp_check -> send_arp_check
Allocate a new timer
Registered timer 0x1420e700 will expiry in 1 secs
timer 0x1420e700(send_arp_check -> send_arp_check) will expire in 1 secs
timer 0x1420e700 expired, take action
Sending arpcheck!
Send an arp packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: 04:D5:90:CA:43:E4
result:60
unregister timer:0x1420e700
register timer func=0x77b500 arg=0x1423f050 name=send_arp_check -> send_arp_check
Allocate a new timer
Registered timer 0x14250790 will expiry in 1 secs
timer 0x14250790(send_arp_check -> send_arp_check) will expire in 1 secs
timer 0x14250790 expired, take action
Sending arpcheck!
bind lease
unregister timer:0x14250790
register timer func=0x77afa0 arg=0x1423f050 name=bind_lease -> state_renewing
Allocate a new timer
Registered timer 0x1420e700 will expiry in 1796 secs
config interface:wan1.100
config interface ip:587E8xxx
Config interface netmask: 00F8FFFF
Config interface broadcast: FF7F8BB0
config interface default gateway:01788BB0
config interface dns1:0A7A9EC2
config interface dns2:0F7A9EC2
make arp inform
Broadcasting ARPOP_REPLY for 176.139.X.X to make it valid
Send an arp packet out.
add hw header
set dst hw addr as: FF:FF:FF:FF:FF:FF
src hw addr: 04:D5:90:CA:43:E4
result:60
-
Alors je viens de remarquer que lorsque la tentative de requete DHCP se termine sur mon interface et m'affiche une erreur j'ai un bouton retry qui apparait et quand je le lance j'ai ca qui ce passe coté log
state reboot.
state init.
make discover
make dhcp message, code=1
Insert option(255), len(0)
Insert option(53), len(1)
Insert max message len (1458)
Insert option(57), len(2)
Insert client ID
Insert option(61), len(7)
Insert requested options
Insert option(55), len(11)
Insert hostname
Insert option(12), len(9)
Insert class ID option
Insert option(60), len(13)
get_dhcp_msg_len, 292
too small, extend to 548
Sending discover!
et aprés ca reboucle sur le message que j'avais sur le post plus haut , si je compare avec ce que tu as, au lieu d'envoyer
sending request
ce bfbfejfzubvzub de FORTI envoi un sending discover et apres c'est la loop de l'infini
-
Le DHCP Bouygues n'aimerait pas la plage d'adresses MAC du FGT ?
Si on met l'adresse MAC du Mac sur le FGT ?
Si on met l'adresse MAC du FGT sur le Mac ?
Après sinon c'est un bug sur les 30E je pense. J'en ai en prod en DHCP côté WAN mais pas avec Bouygues.
-
Je vais essayer mais je penche plus pour un bug sur le 30E, car j'avais deja essayé de spoof la mac en mettant celle de la box, mais allez soyons fou je ne suis plus à ca pres...
SI ca marche pas je pense que je vais abandonner, de toute facon je devais me former sur les Mikrotik, ce sera l'occasion
Edit: Bon ba c'est ce que je pensai, @mac du FORTI sur le MAC > aucun souci / @mac du MAC sur le FORTI > KO
sachant que je ne suis pas la seule à avoir un 30E qui se comporte de la meme manière, ca ressemble bien à un souci sur ce modèle...
Je vais me faire une raison...
En tout cas merci pour l'aide ;)
-
Si il est sous contrat, toujours possible d'ouvrir un ticket. Sinon... Espérer à chaque changelog.
-
il est encore sous contrat jusqu'à septembre mais bon... si je trouve la motiv pendant les vacances j'essaierai d'ouvrir un case
-
Bonne année à tous !!!
Je tombe sur le même soucis - et j'ai les mêmes symptômes.
Avez-vous réussi à passer votre Fortigate sur le DHCP ?
Pour info, ma conf
FGT60F-6.4.4-FW-build1803-201209
edit "wan2"
set vdom "root"
set type physical
set role wan
set macaddr 90:4d:4a:xx:xx:xx (Ma BBox MAC)
next
edit "INTERNET"
set vdom "root"
set mode dhcp
config client-options
edit 1
set code 61
set value "01904d4axxxxxx"
next
edit 2
set code 60
set type string
set value "BYGTELIAD"
next
end
set role wan
set interface "wan2"
set vlanid 100
next
end
Rien d'autre - pas de firewall policy...
:35 make discover
:35 make dhcp message, code=1
:35 Insert option(255), len(0)
:35 Insert option(53), len(1)
:35 Insert max message len (1458)
:35 Insert option(57), len(2)
:35 Insert requested options
:35 Insert option(55), len(11)
:35 Insert customer options
:35 Insert option(60), len(9)
:35 Insert option(61), len(7)
:35 get_dhcp_msg_len, 289
:35 too small, extend to 548
:35 Sending discover!
:35 Send a packet out.
:35 add hw header
:35 set dst hw addr as: FF:FF:FF:FF:FF:FF
:35 src hw addr: 90:4D:4A:xx:xx:xx
:35 add ip udp header
:35 dhcpcd_send_packet,268:result:590, ifinde:21
:35 unregister timer:0x144d9f10
:35 register timer func=0x7a6700 arg=0x145107a0 name=send_discover -> send_discover
:35 Allocate a new timer
:35 Registered timer 0x144d9700 will expiry in 6 secs
:35 timer 0x144d9700(send_discover -> send_discover) will expire in 6 secs
:36 timer 0x144d9700(send_discover -> send_discover) will expire in 5 secs
:37 timer 0x144d9700(send_discover -> send_discover) will expire in 4 secs
Et jamais de DHCP Request...
Et je confirme bien qu'en plaçant un linux à la place, avec la même MAC, sur le même vLan 100, avec les mêmes options 60 et 61, j'obtiens bien une réponse DHCP.
J'ai un ticket chez Fortinet en cours - mais ils bloquent aussi.
Comment avez-vous fait de votre coté ?
-
J'ai un 60F en 6.4.4, je n'ai pas eu besoin d'options :
config system interface
edit "wan1.100"
set vdom "root"
set mode dhcp
set allowaccess ping https
set alias "FTTH Bouygues 1 Gb/s"
set device-identification enable
set estimated-upstream-bandwidth 500000
set estimated-downstream-bandwidth 950000
set monitor-bandwidth enable
set role wan
set snmp-index 29
config ipv6
set ip6-mode dhcp
set ip6-allowaccess ping https
set dhcp6-prefix-delegation enable
end
set dns-server-override disable
set interface "wan1"
set vlanid 100
next
end
Il faut essayer de redémarrer l'ONT une fois connecté au FGT, des fois ça aide.
-
Aucune option ?
Sais-tu me dire si on est sur le même DHCP server ? Peux-tu me passer l'info en MP ?
Tu ne spoof même pas la MAC de ta box ?
-
Non, pas besoin de spoof la mac, il faut juste laisser le bail expirer (1h chez moi) si la box (ou autre équipement) était connectée avant.
Le serveur DHCP qui me répond est 212.194.36.5
Je vais t'envoyer en MP la capture du paquet request et ack pour que tu puisses comparer.
-
Bonjour a tous
Je suis bloqué et arrivé au bout des investigations - voila mes conclusions, validées par le support Fortinet.
FortiOS n’est pas compatible avec les DHCP Relay de Bouygues Fibre, suivant les zones. Certains des DHCP relay pouvant effectivement fonctionner parfois.
Voici plus précisément le symptôme.
FortiOS envoie sa requête DHCP Discover (la première demande) avec le Bootp Flag à 1 (Broadcast).
Or le DHCP relay n’y répond pas.
Si vous prenez un Linux, un BSD, un Windows, un OpenWRT, un checkpoint, un Cisco, et j’en passe, ils envoient leur requête avec le Bootp flag à 0 (Unicast).
J’ai testé sur le même lien avec d’autres systèmes et effectivement l’IP est obtenue immédiatement (pas besoin d’attendre 1h), et toutes les manipulations DHCP sont efficace (release, renew). Mais elles sont en unicast (sur ff:ff:ff:ff:ff:ff:ff:ff ou 255.255.255.255 bien sûr, mais avec ce bit de « bootp flag » à zéro.
Donc effectivement, pas besoin de spoof MAC, pas besoin d’ID client et autre. Juste le VLAN.100 et un Bootp flag à 0
Quelques détails ici https://superuser.com/questions/472594/dhcp-broadcast-flag
Je partage volontiers plus de détails en MP si vous le voulez. C’est de la discussion autours des RFC DHCP...
Le fin mot de l’histoire est que Fortinet ne corrigera pas sauf à obtenir une NFR (New Feature Request), auprès de leur R&D. Autant dire que cela n’arrivera pas.
Et Bouygues ne bougera pas d’une oreille même si leur DHCP relay ne sont pas conformes aux RFC, puisqu’ils disent que le problème vient du routeur et qu’avec une Bbox, ça marche...
Bref - je vais regarder sérieusement pFsense ou openwrt... dommage.
-
Est-ce qu'il est possible de faire une sorte de MITM pour modifier à la volée ce flag DHCP ?
-
Merci pour cette investigation, ça explique pourquoi chez certaines personnes ça fonctionne et d'autres non.
Oui chez Forti il faut passer par son revendeur autorisé pour faire une feature request il me semble, c'est casse bonbon.
Tout espoir n'est pas perdu, ça faisait des années que j'espérais voir les options pour le client DHCP arriver, elles sont bien arrivés un jour ;D
-
Est-ce qu'il est possible de faire une sorte de MITM pour modifier à la volée ce flag DHCP ?
C’est une bonne idée. J’ai essayé, mais je n’ai pas trouvé comment.
Le client dhcp est le fortigate, son interface wan... il n’y a pas moyen de faire du mitm avant la sortie du paquet.
Il y aurait une possibilité en ajoutant un dhcp relay entre l’ONT et le Forti, mais cela perd de l’intérêt - autant passer sur pFsense.
Quelqu’un saurait comment faire ce type de mitm ?
-
https://community.fortinet.com/t5/Support-Forum/DHCP-Failure-due-to-BOOTP-Broadcast/m-p/227256/highlight/true#M201513
Pas le seul à avoir le soucis - C'est lié à Fortigate / Fortinet.
A suivre s'ils corrigent dans le futur.
-
Salut,
S'il y en a encore qui cherchent, je viens de récupérer une ipv4 publique directement sur un vlan du port wan2 de mon fwf-80f.
Il m'a suffit de désactiver le dhcp broadcast flag.
conf sys interface
edit bouygues
set dhcp-broadcast-flag disable
end
Je suis en version 7.4
-
Salut ouaibix
Excellent ! C'est effectivement ce qui manquait aux versions antérieures à 7.4.0.
Avec juste le VLAN100, l'ID DHCP client, et ce fichu DHCP-Broadcast-flag désactivé, tout roule !
Merci d'avoir relancé ce topic. :-*
J'avais un peu laissé tomber, désespéré, mais le support Fortinet aurait tout de même un peu écouté :)
Et heureusement que tu as été plus persévérant que moi. Merci. Merci. Merci.
-
Salut ouaibix
Excellent ! C'est effectivement ce qui manquait aux versions antérieures à 7.4.0.
Avec juste le VLAN100, l'ID DHCP client, et ce fichu DHCP-Broadcast-flag désactivé, tout roule !
Merci d'avoir relancé ce topic. :-*
J'avais un peu laissé tomber, désespéré, mais le support Fortinet aurait tout de même un peu écouté :)
Et heureusement que tu as été plus persévérant que moi. Merci. Merci. Merci.
Salut!
Avec plaisir cybergull :)
Allez comme j'ai un peu galéré sur l'ip v6 alors j'en profite pour compléter ma réponse avec ma conf wan2 (wan1 = Free, config ici: https://lafibre.info/remplacer-freebox/remplacer-freebox-revolution-par-un-fortigate/msg1038468/#msg1038468 (https://lafibre.info/remplacer-freebox/remplacer-freebox-revolution-par-un-fortigate/msg1038468/#msg1038468)).
Bouygues utilise dhcpv6 pour déléguer un préfixe /60 mais ne donne aucune adresse IP/128 à allouer à son interface wan.
Pour l'instant le seul moyen que j'ai trouvé a été de déléguer un /64 à la même interface.
Config des interfaces
fwf01 # conf sys interface
fwf01 (interface) # edit wan2
fwf01 (wan2) # show
config system interface
edit "wan2"
set vdom "root"
set vlanforward enable
set type physical
set role wan
set snmp-index 2
set macaddr 30:93:xx:xx:xx:xx
next
end
Conf interface vlan
fwf01 # conf sys interface
fwf01 (interface) # edit bouygues
fwf01 (bouygues) # show
config system interface
edit "bouygues"
set vdom "root"
set mode dhcp
set distance 15
set dhcp-broadcast-flag disable
set allowaccess ping
set device-identification enable
set role wan
set snmp-index 33
config ipv6
set ip6-mode delegated
set ip6-allowaccess ping
set dhcp6-prefix-delegation enable
set ip6-delegated-prefix-iaid 1
set ip6-upstream-interface "bouygues"
set ip6-subnet ::f:0:0:0:1/64
config dhcp6-iapd-list
edit 1
set prefix-hint ::/64
next
end
end
set dhcp-client-identifier "BYGTELIAD"
set dns-server-override disable
set interface "wan2"
set vlanid 100
next
end
Résultat:
fwf01 (bouygues) # get
name : bouygues
vdom : root
vrf : 0
cli-conn-status : 2
mode : dhcp
client-options:
distance : 15
priority : 1
dhcp-relay-interface-select-method: auto
dhcp-broadcast-flag : disable
dhcp-relay-service : disable
dhcp-classless-route-addition: disable
ip : 176.XXX.XXX.1 255.255.224.0
allowaccess : ping
fail-detect : disable
arpforward : enable
broadcast-forward : disable
bfd : global
l2forward : disable
icmp-send-redirect : enable
icmp-accept-redirect: enable
reachable-time : 30000
vlanforward : disable
stpforward : disable
ips-sniffer-mode : disable
ident-accept : disable
ipmac : disable
subst : disable
substitute-dst-mac : 00:00:00:00:00:00
status : up
netbios-forward : disable
wins-ip : 0.0.0.0
type : vlan
netflow-sampler : disable
sflow-sampler : disable
src-check : enable
sample-rate : 2000
polling-interval : 20
sample-direction : both
explicit-web-proxy : disable
explicit-ftp-proxy : disable
proxy-captive-portal: disable
tcp-mss : 0
inbandwidth : 0
outbandwidth : 0
egress-shaping-profile:
ingress-shaping-profile:
weight : 0
external : disable
vlan-protocol : 8021q
trunk : disable
devindex : 44
description :
alias :
l2tp-client : disable
security-mode : none
ike-saml-server :
device-identification: enable
device-user-identification: enable
estimated-upstream-bandwidth: 0
estimated-downstream-bandwidth: 0
measured-upstream-bandwidth: 0
measured-downstream-bandwidth: 0
bandwidth-measure-time:
monitor-bandwidth : disable
vrrp-virtual-mac : disable
vrrp:
role : wan
snmp-index : 33
preserve-session-route: disable
auto-auth-extension-device: disable
ap-discover : enable
managed-subnetwork-size: 256
switch-controller-igmp-snooping-proxy: disable
switch-controller-igmp-snooping-fast-leave: disable
switch-controller-feature: none
swc-vlan : 0
color : 0
tagging:
eap-supplicant : disable
ipv6:
ip6-mode : delegated
nd-mode : basic
ip6-address : 2001:861:x:xxxf::1/64
ip6-allowaccess : ping
icmp6-send-redirect : enable
ra-send-mtu : enable
ip6-reachable-time : 0
ip6-retrans-time : 0
ip6-hop-limit : 0
ip6-prefix-mode : dhcp6
dhcp6-prefix-delegation: enable
delegated-prefix iaid 1 : 2001:861:x:xxx0::/60
preferred-life-time : 5400
valid-life-time : 7200
delegated-DNS1 : 2001:860:b0ff:1::1
delegated-DNS2 : 2001:860:b0ff:1::2
delegated-domain :
cli-conn6-status : 1
vrrp-virtual-mac6 : disable
vrip6_link_local : ::
ip6-dns-server-override: enable
Acquired DNS1 : ::
Acquired DNS2 : ::
ip6-send-adv : disable
ip6-delegated-prefix-iaid: 1
ip6-upstream-interface: bouygues
ip6-subnet : ::f:0:0:0:1/64
dhcp6-iapd-list:
== [ 1 ]
iaid: 1 prefix-hint: ::/64 prefix-hint-plt: 604800 prefix-hint-vlt: 2592000
dhcp-relay-request-all-server: disable
dhcp-smart-relay : disable
dhcp-client-identifier: BYGTELIAD
dhcp-renew-time : 0
idle-timeout : 0
detected-peer-mtu : 0
disc-retry-timeout : 1
padt-retry-timeout : 1
defaultgw : enable
DHCP Gateway : 176.XXX.XXX.1
Lease Expires : Fri Oct 6 11:08:09 2023
dns-server-override : disable
Acquired DNS1 : 194.158.122.10
Acquired DNS2 : 194.158.122.15
dns-server-protocol : cleartext
pptp-client : disable
mtu-override : disable
wccp : disable
drop-overlapped-fragment: disable
drop-fragment : disable
interface : wan2
vlanid : 100
-
Bonjour à tous,
De mon côté avec un FG60F en version 7.4.1 tous marche nickel à l’exception de la ligne fix qui est indispensable pour moi. J'ai ce problème depuis Janvier 2023, à l'époque J'avais un router UDM de chez Ubiquiti et je retrouve du coup le même soucis avec mon FG60F aujourd'hui, le voyant de la ligne fix reste rouge sur la bbox et impossible de passer/recevoir un coup fils.
Est-ce que quelqu'un à eu le même soucis et comment faire pour le résoudre ?
-
Bonjour à tous,
Merci pour le partage! Cela m'a permis d'enfin avoir une IPv6 chez Bouygues.
Avez vous des difficultés pour avoir la TV ? De mon coté, tout fonctionnait le jours de mon déménagement et dans mon nouveau logement je n'ai que TF1...
Avez vous la possibilité de partager vos configs ?
De mon coté, j'avais seulement cette règle multicast:
config firewall multicast-policy
edit 1
set logtraffic enable
set srcintf "dmz"
set dstintf "BG_Public"
set srcaddr "all"
set dstaddr "all"
next
edit 2
set logtraffic enable
set srcintf "BG_Public"
set dstintf "dmz"
set srcaddr "all"
set dstaddr "all"
next
ainsi que cette policy:
edit 5
set name "TV_BOUYGUES"
set uuid 76987086-fe60-51e9-249d-09e49964acc0
set srcintf "BG_Public"
set dstintf "dmz"
set srcaddr "Source_TV_BG" "Source_TV_BG2" "Source_TV_BG3" "Source_tv_BG4"
set dstaddr "TV_INPUT" "Tv_INPUT2" "TV_INPUT1234"
set action accept
set schedule "always"
set service "TV" "TV_Bis" "TV_1234"
set fsso disable
set comments "Clone of Flux_TV"
set nat enable
next
Merci pour votre aide ( et j'espère aussi pouvoir vous aider :))