Dynamic DNS Client n'envoie pas l'adresse publique
-
Bonjour,
Je suis débutant sur Pfsense. Je voulais remplacer Un de mes IPCOP par pfsense, mais je butte sur un problème:
Mon réseau :En tete d'installation un modem/routeur
en sortie 1 du modem/routeur : un firewall SonicWall (Administration)
en sortie 2 du modem/routeur : l'Ipcop a remplacer (Pedagogie)Le Dynamic DNS Client n'envoie pas l'adresse publique du modem/routeur mais l'IP interne fournit par le DHCP du modem/routeur !
Sur Ipcop on coche "Devinez la véritable adresse public à laide d'un srveur exterieur" mais sur Pfsense ?Sur le forum on trouve "Two possibilities:
- let your modem do the DynDNS update itself (it knows the WAN IP)
- (if at all possible) switch your modem to bridge mode and have pfSense do the PPPoE. This way it knows the WAN IP and can update your DynDNS settings correctly."
Sur mon modem/routeur ST609 j'ai pas trouvé l'option Dynamic DNS Client.
et je ne peux mas passer mon modem/routeur en bridge.
Y a t-il un addon pour Pfsense? ou une astuce que je n'ai pas trouvée ?
-
le ST609 peux passer en bridge non ? Dans ce cas Pfsense s'occupe du PPP et connait donc l'adresse IP publique.
Autre solution, celle que j'ai adopté, passer le modem en half bridge (anciennement appelé DHCP spoofing).
Dans ce cas, le modem s'occupe du PPP, mais délivre une adresse IP publique en DHCP vers PFsense.
Avantage du full bridge : possibilité d'avoir de l'IPv6 en natif par Nérim en ADSL. (double session PPP, IPv4 + IPv6).
Inconvénient du full bridge : PPP semble poser de sérieux problèmes en multiwan, quelque soit le routeur Opensource. Seuls les routeurs commerciaux du type PePlink savent gérer ca correctement. Peut être Pfsense 2.0 d'ici un an ou deux lorsqu'il sera stable.
Inconvénient du Half bridge : IPv6 non supporté car les modems ne savent pas gérer IPv6 en interne (difficile à croire moins de deux ans avant le déployement global d'IPv6 en Europe !!)
Le ST609 est un ancêtre. Thomson ne semble plus fournir aucun support sur ces modems, si tant est qu'ils aient fourni ce qu'on peut appeler un support.
J'utilise des Linksys AM200, ils supportent tous les modes courants sans se prendre la tête avec la configuration ultra complexe des thomsons : full bridge, half bridge pppoe ou pppoa, mode routé en pppoe ou pppoa, et même le RFC1483 routé (IPoa) ou bridgé (MER).
La seule chose qu'on peut pas faire sur le linksys, c'est du multi VC, et la gestion QOS atm. Mais de toutes façons, aucun opérateur en France ne propose du multi VC. (trop compliqué pour eux et pas assez rentable, ils préfèrent louer des SDSL à 200-500 euros / mois).
Les fournisseurs d'accès français nous cassent les pieds avec le PPP en ADSL. C'est inutile pour l'utilisateur. La France est un des rares pays à s'entêter à faire du PPP sur ADSL, sauf chez Free, qui fait du RFC1483 routé (IpoA).
France Telecom est le principal responsable de l'omniprésence du PPP sur l'ADSL. A l'étranger, on fait des efforts pour évoluer. Au niveau hardware, Cisco supporte très bien les modes RFC1483 routés et bridgés.
Alors si le PPP vous casse les pieds, faites le savoir à votre FAI. Ca fera avancer un peu les choses. Le PPP était utile à l'époque des modems RTC et de la facturation horaire. En ADSL ou est l'intérêt d'un controle de la durée de session ?
Le RFC1483 routé (IPoA) choisi par Free est le plus optimisé en terme d'efficacité du lien, mais pose le problème de la configuration automatique de l'adresse IPv4 car aucun protocole n'est prévu délivrer une IP au niveau 3. Free utilise un protocole propriétaire pour délivrer l'adresse IP. Sinon, IP statique manuellement configurée obligatoire.
Le RFC1483 bridgé (MER ou EthoA) ajoute un peu d'entêtes (ethernet), mais permet de délivrer une IP en DHCP.