La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Hakujou le 23 avril 2017 à 17:34:28
-
Bonjour à tous,
Suite à ma question posée ici : https://lafibre.info/1gb-free/debit-divise-par-deux-en-mode-bridge/, j'ai d'autres questions :)
J'ai décidé de garder ma Freebox Mini 4K en mode routeur étant donné la différence de débit (DL : 650Mbps en routeur contre 300 en bridge...). J'ai derrière cette Freebox un seul routeur PfSense, sur qui tout est connecté (AP Wifi, machines, serveurs...).
Certaines personnes de mon domicile (moi inclus) jouant en ligne, il serait en revanche sympathique de bénéficier d'un NAT non strict. Le NAT Loopback serait également pratique pour accéder aux serveurs (sans avoir à les entrer dans le DNS).
En toute logique, j'ai défini le routeur PfSense en DMZ sur la Freebox, et me suis (naïvement) dit que ça suffirait. Sauf que... non.
Les enregistrements UPnP-IGD apparaissent bien dans PfSense, mais le jeu et les consoles se plaignent toujours du NAT, qui est déclaré strict. Le NAT Loopback ne fonctionne pas du tout non plus...
Comment faire pour rétablir ces deux fonctions ?
Merci à vous !
EDIT : Il est en revanche intéressant de noter que je peux accéder à mes services de l'extérieur, donc le DMZ fonctionne, et encore plus étrange : Si je teste les ports des enregistrements UPnP-IGD sur http://www.yougetsignal.com/tools/open-ports/, ils sont bien marqués ouverts... Partant de là, j'ai du mal à comprendre comment et pourquoi les consoles et jeux se plaignent du NAT ?!
EDIT 2 : J'ai fait quelques tests avec MiniUPNP sur Windows, j'arrive bien à ouvrir des ports (je les vois sur le routeur), et j'y accède bien depuis l'extérieur. J'ai donc plus l'impression que le message sur mon jeu relève du faux-positif, j'espère que ça ne gènera pas. Par contre pas de trace d'une ouverture de port UPnP sur les consoles (360 et PS4), et elles se plaignent bien d'un NAT strict. Je sais pas si c'est moi qui manque quelque chose dans la config.
Egalement, j'ai "override" la WAN IP Address sur la config UPnP de PfSense pour indiquer mon IP publique. Je ne sais pas si je suis censé faire comme ça et/ou si ça change quelque chose...
-
"NAT strict" est une terminologie qui ne veut rien dire. C'est propre aux consoles.
Si t'en a 2 il se peut qu'elles "luttent" pour ouvrir les memes ports ?
si upnp fonctionne ce qui a l'air d'être le cas il n'y a pas grand chose d'autre à faire.
Apres faudrait savoir ce que teste vraiment les consoles (c'est l'OS des consoles ou les jeux eux-memes?) . une capture au niveau du pfsense pourrait donner des infos.
t'es en ZMD? full-stack ou un 1/4 d'IP ?
-
Effectivement, mais je connais pas de terminologie "officielle". Elles n'arrivent pas à ouvrir un port vers elle même (c'est aussi appelé NAT Type 1/2/3 sur certains jeux/consoles).
J'ai essayé avec les consoles séparèment ou des jeux sans conflits : même résultat. Parmi les consoles, au moins une aurait réussi à s'approprier les ports : ici, rien sur l'UPnP-IGD sur le routeur (ce qui est définitivement étrange, par contre).
Sur les consoles, les tests s'effectuent bien sur les consoles. La PS4 crache un "Type NAT : Strict" dans ses paramètres réseau, la 360 signale un problème avec le réseau pouvant impacter les communications et le matchmaking (et parle de NAT quand l'aide s'affiche). Je peux montrer une capture du PfSense, mais pas sûr que ça apporte grand chose.
On voit bien que Rainbow Six Siege, par ex, a bien réussi à ouvrir un port sur l'UPnP-IGD, pourtant, il continue de crier au NAT strict...
Sinon, une idée sur comment faire fonctionner le NAT loopback ?
Je suis en ZMD, et j'ai bien une IP full stack (sans quoi le bridge ne fonctionnait pas, d'ailleurs :o).
-
Le NAT lookback s'appele 'nat reflection' sur Pfsense il semble. dans System > Advanced, Firewall/NAT
voir https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks
c'est fort probable que ce soit le souci: le jeu ne manipule qu'une seule adresse IP pour le serveur de jeu local, la public. et pour se connecter au serveur localement il doit pouvoir utiliser cette public donc faire du loopback (ca serait mon interprétation de leur définition de strict: qui ne permet pas le loopback).
apres si ca ne marche toujours pas , t'as peut-etre aussi un reglage du firewalling qui bloque le loopback ?
-
Le NAT loopback fonctionnait très bien quand j'avais le PfSense en seul routeur. Je pense que le souci vient du fait qu'il ne connaît pas son IP WAN (la "vraie", celle sur la Freebox), mais je ne vois pas comment régler le souci.
Pour le jeu, je ne sais pas, j'ai bien mis l'IP publique Free en override sur l'UPnP-IGD...
Le firewall ne bloque pas du tout le loopback, ça fonctionnait avant.
-
https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks
The more elegant solution to this problem involves using Split DNS. Basically this means that internal and external clients resolve hostnames differently.
Vous aussi, vous appelez ça une approche élégante?
-
C'est la solution la plus courante, fréquemment rencontrée en entreprises, pour que les noms soient résolus en interne.
Cela dit je préférerais du NAT Loopback, pas franchement envie de re-rentrer tous les serveurs dans le DNS local...
-
Le NAT loopback fonctionnait très bien quand j'avais le PfSense en seul routeur. Je pense que le souci vient du fait qu'il ne connaît pas son IP WAN (la "vraie", celle sur la Freebox), mais je ne vois pas comment régler le souci.
Pour le jeu, je ne sais pas, j'ai bien mis l'IP publique Free en override sur l'UPnP-IGD...
Le firewall ne bloque pas du tout le loopback, ça fonctionnait avant.
il faudrait savoir comment le jeu ou la console obtient son IP public. Usuellement ca doit se faire en interrogeant un service sur le PSN ou XBox live peux-etre? Apres il se peut aussi que le double NAT soit détecté ou gène a un moment (je ne vois pas pourquoi a priori).
Mais avant faut bien tester que le loopback fonctionne correctement , depuis un PC par exemple.
-
Aucune idée. Cela dit toutes les consoles et jeux testés sont unanimes, alors que je n'ai jamais eu de souci avant la mise en place du double NAT...
Pour ce qui est du NAT loopback, c'est un souci "différent" des consoles/jeux (je ne pense pas qu'ils en aient besoin ?). Il ne fonctionne effectivement pas, l'IP est bien résolue sur l'IP WAN mais rien ne répond lorsque je ping ou que j'essaie d'y accéder à mes serveurs via un de mes noms de domaine... (je précise que ça fonctionnait très bien avant le double NAT).
-
effectivement le loopback doit merdé car y'a double NAT :
ip lan interne --> PF --> ip lan intermédiaire --> FBX --> ip wan
le loopback dans le PF fait son job mais pas le loopback dans la FBX (je ne sais même pas si la FBX sait faire du loopback d'ailleurs meme sur la DMZ ?)
tu peux deja tester si le loopback dans le PF fonctionne en utilisant l'IP wan du PF.
pour le NAT strict, peux-etre en faisant du NAT 1-1 dans le PF plutot que du NAT N-1 ? (on ne peut toujours pas faire de route statique dans la FBX: https://dev.freebox.fr/bugs/task/12869 ?) mais j'en doute.
-
C'est possible, mais ça me paraît bizarre. A ma connaissance, seule la Livebox était incapable de faire du NAT Loopback.
Par contre la Freebox ne résout pas les IP derrière le PfSense (logique, faut de route). Une chance que ça vienne de là ?
Si je fais du NAT 1:1, ça implique que j'aie autant d'IP côté LAN Freebox que celui LAN PfSense, si je ne dis pas de bêtises ?
C'est possible, mais potentiellement compliqué, côté PfSense j'ai un bridge de trois réseaux avec pour IP Gateway 10.11.1.1/11, un réseau 10.40.1.1/16, un 10.50.1.1/16 et un 10.60.1.1/16...
-
Par contre la Freebox ne résout pas les IP derrière le PfSense (logique, faut de route). Une chance que ça vienne de là ?
Tu peux m'expliquer ce qu'est "résoudre une IP"?
-
Pardon, mauvais terme. Elle ne route pas vers le PfSense, faute de route, elle ignore que les les réseaux derrière le PfSense existent (et doit probablement router vers WAN à la place).
-
mouais c'est mal barré je pense. le NAT 1-1 va être compliqué car il faudra propager l'upnp a la FBX , pas sur que PfSense sache faire cela.
t'es bon pour rester comme ca ou mettre la FBX en mode bridge quitte a perdre un peu de débit max (débit IPv4 il me semble, en IPv6 ca va bien non?)
-
Pardon, mauvais terme. Elle ne route pas vers le PfSense, faute de route, elle ignore que les les réseaux derrière le PfSense existent (et doit probablement router vers WAN à la place).
D'accord, elle n'a pas de route vers ce sous-réseau.
Tu peux me montrer un exemple de double NAT où l'existence d'une telle route a un effet?
-
Ce que je ne comprends pas, c'est le besoin de propager l'UPnP jusqu'à la FBX, en fait. Vu que le PfSense est en DMZ, tout devrait passer vers lui de toute façon, non ?
Le problème c'est qu'en mode bridge, je perds quand même plus de 50% du débit, on passe de 600-650Mbps à 250-300... (Pas testé le débit IPv6, le PfSense choppe une IPv6 sur WAN mais je n'ai pas été plus loin parce que je n'ai AUCUNE idée de comment ça fonctionne derrière... Cela dit l'intérêt doit rester limité vu le peu de serveurs qui fonctionnent en IPv6, idem pour les torrents).
EDIT :
D'accord, elle n'a pas de route vers ce sous-réseau.
Tu peux me montrer un exemple de double NAT où l'existence d'une telle route a un effet?
Ah aucune idée, c'était juste une piste comme ça.
-
Ce que je ne comprends pas, c'est le besoin de propager l'UPnP jusqu'à la FBX, en fait. Vu que le PfSense est en DMZ, tout devrait passer vers lui de toute façon, non ?
c'est uniquement en NAT 1-1 ca:
exemple:
pc1(10.40.1.2) ---(10.40.1.1)-pfsense NAT1:1-(10.140.1.1)--(10.140.1.254)fbx(NAT N:1)-IP PUB
pc2(10.40.1.3) --|
j'ai 2 pc ou autres derriere le pfsense sur le réseau 10.40.1.0/24
le réseau entre le pfsense et la fbx est 10.140.1.0/24
le NAT 1:1 consiste a mapper 10.40.1.x sur 10.140.1.x (on change que l'IP par les ports)
La freebox verra autant d'ip sur son LAN que de machines sur 10.40.1.x, elle verra donc 10.140.1.1 (pfsense), 10.140.1.2 (pc1) et 10.140.1.3 (pc2) (avec la meme adresse MAC car c'est le pfsense qui porte ces 3 IP).
si tu veut ouvrir un port pour pc1 en upnp, il faut dire a la freebox de renvoyer ce port sur 10.140.1.2 et pas sur la dmz 10.140.1.1 donc faut bien propager un upnp (modifié par le NAT 1:1 qui plus est):
pc1 envoie un upnp a pfsense: "rediriger le port tcp 80 sur 10.40.1.2". Pfsense doit propager ce message a la freebox mais en changeant: "rediriger le port tcp 80 sur 10.140.1.2".
mais bon on se complique pour rien car je ne pense pas que le NAT 1-1 solutionnera ton souci de 'nat strict'. Apres tu peux toujours essaye pour le fun. Tu peux NAT 1:1 tout un subnet (/24 par exemple) vers un autre subnet de meme taille ou juste une IP vers une IP par exemple (une IP étant un subnet /32).cf: http://blog.stefcho.eu/1-1-nat-in-pfsense-and-dd-wrt/ par exemple
-
Effectivement, je ne pense pas que le NAT 1:1 solutionne le NAT strict ou le NAT loopback.
Mais du coup, retour à la case départ : aucune idée de pourquoi ni l'un ni l'autre ne fonctionnent, et comment y remédier.
EDIT : L'UPnP fonctionne, donc la seule raison que je peux voir c'est qu'ils ne détectent pas la bonne IP de connexion (par exemple, celle du WAN côté PfSense, donc LAN FBX) et que ça échoue pour cette raison. Parce qu'étant donné que les ports sont bien ouverts sur demande UPnP et qu'ils fonctionnent quand je fais un port check depuis l'extérieur, je ne vois que ça...
-
deja faut tester en mettant une console directement derriere la fbx déja pour voir si c'est elle le coupable ou le double NAT.
-
Après un enième redémarrage de la Livebox, vérification des baux DHCP et du DMZ, pour une raison que je n'explique pas, le NAT est repassé en ouvert. Mes clients torrent, jeux, et consoles sont tous contents !
Par contre, toujours pas de NAT Loopback. Quand je suis connecté directement sur la Freebox, ça ne fonctionne pas mieux, donc je pense qu'elle ne le gère pas. Un moyen de "shunter" ça au niveau du PfSense ?
-
Par contre, toujours pas de NAT Loopback. Quand je suis connecté directement sur la Freebox, ça ne fonctionne pas mieux, donc je pense qu'elle ne le gère pas. Un moyen de "shunter" ça au niveau du PfSense ?
tu veux du loopback dynamique (aka compatible upnp) ou statique (ouverture d'un port a la main vers toujours la même ip interne) ?
pour du dynamique je ne vois pas (sinon dns menteur).
pour du statique, on doit pouvoir faire ca avec du destination NAT:
pc1(10.40.1.2) ---(10.40.1.1)-pfsense-(10.140.1.1)--(10.140.1.254)-fbx-IPPUB
pc2(10.40.1.3) --|
pc2 est serveur web port 80 par exemple et 10.140.1.1:80 va donc sur 10.40.1.3:80 (configuration ouverture port dans le pfsense).
IPPUB allant toujours sur 10.140.1.1 (DMZ) on a bien pc2 accessible depuis l’extérieur sur le port 80 d'IPPUB.
si pc1 veut accéder a IPPUB:80 sa demande va atteindre la fbx et la ca merdouille car elle ne loopback pas pour renvoyer sur pc2.
il faut donc que pfsense intercepte les demandes pc1 vers IPPUB:80 de facon particuliere.
avec du NAT destination (ou du NAT sur le 'in' de l'interface lan), on peut translater le trafic a destination de IPPUB:80 vers autre chose, par exemple directement PC2:80 ou 10.140.1.1:80.
edit: a la réflexion, peut être qu'on peut même généraliser et translater tout IPPUB vers 10.140.1.1 ce qui ferait le job même en dynamique?
-
Si on translatait tout IPPUB vers 192.168.1.2 (IP WAN de mon PfSense, côté LAN FBX), et que ça routait tout effectivement, ça résoudrait le problème. La question est : comment faire pour transformer le IPPUB en 192.168.1.2 ? Ajout d'une entrée NAT statique ? J'imagine que ça se passe sur la page dont j'ai fourni la capture, mais je ne sais pas comment la configurer...
-
hum a priori ce n'est pas possible avec pfsense je ne vois pas d'option pour faire du 'destination NAT'. A priori on ne peut modifier que l'adresse source.
-
Je joins une capture de l'interface de création de règle, au cas où...
Sinon, un autre moyen d'arriver à ce résultat ?
-
Je joins une capture de l'interface de création de règle, au cas où...
Sinon, un autre moyen d'arriver à ce résultat ?
difficilement. peut-etre avec des regles pf faites a la main mais ca va etre coton de cohabiter avec l'interface de pfsense.
Tu veux du lookback statique ou dynamique déjà? si c'est que statique autant partir sur une solution sans loopback avec du dns par exemple.
y'a 2 difficultés ici:
(A) translater ou router les paquets dont "dest=IPPUB" de facon a ce qu'ils ne quittent pas le pfsense pour aller sur la fbx.
(B) gérer le loopback pour ces paquets (ie les renvoyer sur le lan avec dest qui correspond a la machine qui gere le port)
B ce fait via le NAT loopback (reflection en jargon pfsense).
en general dans un routeur/firewall les routages/transformations (NAT) s'effectue en entrée ou sortie des interfaces.
ici vu qu'on veut A+B et vu que B marche en sortie de l'interface WAN, pour réaliser A il va falloir impérativement agir en entrée de l'interface LAN.
il faut donc une regle de redirection qui change la destination des paquets entrants dans le pfsense. C'est une simple regle de "destination NAT 1:1" : si destination = IPPUB alors destination = 192.168.1.2.
une regle pf du style:
rdr on LAN inet proto any from any to IPPUB -> 192.168.1.2
mais y'a des restrictions il me semble quand on met une IP locale en destination.
-
Le dynamique serait idéal, mais je pourrais m'en passer si nécessaire, le statique étant plus important.
Je pensais que c'était l'idée originale. Pour moi l'idée était de transformer les paquets à destination de "IPPUB" en "192.168.1.2" en sortie des LAN, vu que le NAT Reflection est actif sur PfSense (et fonctionnel quand il est en seul routeur), il devrait rerouter les paquets sans souci.
Par contre je n'ai aucune idée de comment translater les paquets "IPPUB" en "192.168.1.2". J'ai essayé deux-trois trucs sur l'interface NAT 1:1, sans succès.
-
comme déjà indiqué, on ne peut pas avec l'interface web, elle ne fait que du 'source' NAT (modification de l'adresse source). Ce qu'on veut c'est modifier l'adresse de destination.
-
Il faut ajouter une règle iptables à la main donc ?
Une idée d'à quoi elle ressemblerait ?
EDIT : Apparemment, PfSense (en tous cas, les versions modernes) n'utilise pas iptables. Il va falloir que je regarde comment je peux faire...
-
pfsense c'est sur Freebsd et pas Linux, y'a donc pas iptables. L’équivalent c'est 'pf' d'ou pfsense tire son nom d'ailleurs mais pfsense utilise une version spéciale de pf. J'ai indiqué la règle dans mon précédent post mais je n'ai pas de garantie sur son fonctionnement.
-
Effectivement, je m'en suis rendu compte juste après.
J'ai essayé un "echo 'rdr on bridge0 inet proto any from any to ippub -> 192.168.1.2' | pfctl -f -" en SSH, ça n'a pas fonctionné :
stdin:1: syntax error
pfctl: Syntax error in config file: pf rules not loaded
-
faut lire la doc , la je n'en sais pas plus pour la version freebsd/pfsense de pf. je suis plus souvent sur OpenBSD ce n'est pas la meme.
apres comme indiqué, la moindre modif dans l'interface web de pfsense va surement reset les modifs faites a la main dans la config de freebsd. voir: https://doc.pfsense.org/index.php/How_can_I_edit_the_PF_ruleset
-
Je reviens vers vous parce que j'ai une enième question (toujours pas réussi à faire ce malheureux NAT source, je me débrouille comme je peux en attendant avec du split DNS, qui fonctionne assez mal).
Au niveau de l'IPv6, comment puis-je faire pour que mes PC aient l'IPv6 ? J'ai suivi cette doc : http://vm.damota.net/2015/08/activer-ipv6-avec-pfsense-et-freebox-revolution-en-mode-bridge/ mais ça ne semble pas fonctionner (j'avais lu quelque part que c'était la même config que la freebox soit en bridge ou en router niveau IPv6, mais peut-être est-ce faux ?).
Le ping IPv6 depuis le PfSense fonctionne bien, mais rien sur les PC derrière. Le test me donne un joli 0/10 : http://test-ipv6.com/
-
oui c'est pareil. il faut choisir un prefix (le 2eme par exemple) et le gerer coté LAN du PfSense et bien mettre l'ip-link local du pfsense comme next-hop dans la freebox.
internet -- freebox -- 1er prefix/64 -- PfSense -- 2eme prefix/64
y'a pas forcement besoin de configurer une IPv6 public (du 1er prefix/64) sur le wan du pfsense, la link-local suffit.
coté lan du pfsense il faut activer SLAAC sur le 2eme prefix/64 et optionnellement un DHCPv6 stateless .
-
Je ne peux pas activer de DHCPv6 Stateless si l'interface LAN est en SLAAC...
(J'ai édité comme tu as dit, en supprimant l'IPv6 du WAN, en mettant le LAN en SLAAC, et même après un refresh d'IP sur un des postes, rien, toujours 0/10 au test. D'ailleurs dans l'affichage des interfaces PfSense, toute référence IPv6 disparaît sur le bridge LAN, y compris le link local)
-
Peut-etre me suis-je mal exprimé: 'lan en slaac' = le pfsense doit faire 'serveur' slaac (c'est a lui d'annoncer le prefix et la gateway par RA).
Le pfsense n'est donc pas en autoconf slaac, ce sont les PC du lan qui le sont.
conf coté lan du pfsense:
- son interface lan doit être en "IPv6 statique", (mettre une IP du "2eme prefix", par exemple "2eme prefix::1/64" )
- annonce le préfixe et la gateway et éventuellement les DNS via RDDNS : menu Services/DHCPv6 Server & RA/onglet router advertisements: choisir Unmanaged ou Stateless DHCP. Si "Stateless DHCP" configurer l'onglet "DHCPv6 server" sinon ne pas y toucher. remplir la conf DNS en bas en mettant l'IPv6 du pfsense ou des serveurs DNS externes)
- optionnellement un stateless DHCPv6 aussi : nb->je ne sais si PfSense peut faire cela. C'est surtout utile pour les PC Windows si y'a pas de conf DNS en IPv4.
Si la conf LAN est ok, les PC doivent recevoir une IPv6 sur "2eme prefix" indépendamment du fait que le coté WAN du PfSense soit configuré ou pas. il doivent recevoir l'IPv6 du pfsense comme route par défaut IPv6.
internet -- freebox (link-local freebox)----(link-local wan) PfSense (2eme prefix::1/64) -- LAN
dans la conf de la freebox indiqué que "2eme prefix" a pour next-hop la "link-local wan"
conf coté wan du pfsense:
- mettre SLAAC ca sera plus simple (le port WAN obtiendra une IPv6 dans "1er prefix::/64" mais aussi une link-local. c'est cette derniere qui nous interesse et qu'il faut mettre dans la freebox).
ps: pour voir l'ip link-local il faut aller dans http://ip-du-pfsense/status_interfaces.php (menu Status puis Interfaces). Le dashboard (page d'acceuil de pfsense) n'affichant pas les link-local.
-
C'était sans doute de ma faute, étant très néophyte en IPv6 je commence à lire et apprendre sur son fonctionnement qui diffère tout de même pas mal de l'IPv4. En effet, ça parait logique de ne pas mettre SLAAC côté LAN, j'aurais dû réaliser.
Par contre c'est à peu près la config que j'avais tirée de la documentation, sans succès. Je n'ai pas l'impression que les PC côté LAN tirent une IPv6, en réalité. J'en ai une "link local", mais c'est tout, qui n'a rien à voir avec le préfixe de la Freebox. J'ai essayé de désactiver l'IPv4 de la carte : plus de connexion (ce qui paraît logique).
Je n'ai pas encore de DNS compatible IPv6 (il faudra que je refasse la config des serveurs pour qu'ils prennent une IPv6 aussi, mais ils sont sur un réseau différent), donc j'ai essayé en laissant vide, ou en spécifiant celui de PfSense, sans succès (mais je n'ai pas l'impression que ça vienne de là).
J'ai aussi défini la priorité RA à High, au cas où => aucun changement...
Une idée ?
Merci pour ta précieuse aide, en tous cas !
-
Ce sont des PC sous quel OS ?
Le coté LAN du pfsense est bien configuré niveau IPv6 ? qu'affiche le status ?
-
Windows 10 (la Creators Update).
Le statut est up, j'ai bien l'IPv6 définie manuellement qui s'affiche sous l'IPv4 sur le panel PfSense.
-
dans ce cas si "RA" est bien a 'unmanaged' dans la conf de pfsense alors le PC windows doit recevoir une IPv6.
-
Et pourtant, non, je n'ai que "adresse IPv6 de liaison locale". Pareil sur mon téléphone (Android 7.1, qui fonctionne très bien en IPv6, normalement).
Si je fais un "ipconfig /all", j'ai tout de même des champs "IAID DHCPv6" et "DUID du client DHCPv6" mais pas d'autre IP, et la gateway est toujours définie en IPv4...
-
c'est que le pfsense n'envoi pas de RA. il faut bien verif sa conf.
-
J'ai trouvé le souci. Il ne fallait pas mettre l'IPv6 statique sur le bridge, mais directement sur l'interface. Mon PC a maintenant bien une IPv6.
Par contre j'ai une autre question, du coup : quelle IP dois-je assigner aux autres interfaces ? Je continue avec mon préfixe puis ::2, ::3 et ainsi de suite ?
Merci pour ton aide !
EDIT : Comme prévu, je peux pas, il y a un overlap. J'ai cru comprendre que réduire le /64 à plus petit n'était pas très standard... Je peux toujours prendre le préfixe suivant sur la FBX, mais ça ne me semble pas idéal comme manière de procéder, surtout qu'il n'y a que sept préfixes utilisables (vu qu'apparemment il ne faut pas utiliser le premier), ce qui correspond à mon nombre de réseaux mais qui semble "moyen" comme idée...
-
c'est un /64 par segment LAN donc il faut utiliser les autres prefix fournit par Free (et mettre next-hop a la meme valeur pour tous).^
il n'est pas recommandé ni souhaitable de couper un /64 en plusieurs morceaux (plein de systèmes fonctionneront mal).
Free ne fournit que 8 /64 (un /61 donc). Le 1er prefix est utilisable aussi il me semble mais pas avec pfsense (en l'état du moins).
Orange fournit un /56 soit 256 /64.
après 7 sous-réseaux distincts c'est déjà un peu extrême pour un particulier :)
-
Je vais faire comme ça, alors.
Je viens de passer d'Orange à Free (pour des raisons de débits/prix surtout), je vais éviter de faire le retour pour l'instant :).
C'est clairement extrême, mais j'ai pas mal de serveurs (un fameux homelab) donc pas mal de réseaux distincts pour les tests, la sécurité, etc.
EDIT: Une dernière question : j'ai vu le broadcast par IPv6 passait par des IP spéciales. Malgré tout, étant donné que les IPv6 sont directement sur les interfaces et non sur le bridge, les interfaces membres du bridge ne recevront pas les broadcasts des autres interfaces membres, si ?
Le comportement est très étrange... chaque membre du bridge reçoit une IPv6 de chaque interface membre... Quelque chose à faire pour empêcher ça ?
-
Une dernière question : j'ai vu le broadcast par IPv6
Y a pas de broadcast en IPv6, seulement du multicast.
-
Effectivement, il me reste encore pas mal à lire sur l'IPv6, visiblement...
Mais du coup, je ne sais toujours pas comment faire pour que les membres du bridge prennent uniquement une IP sur leur interface... Peut-être une règle de pare-feu à ajouter pour ne pas laisser passer la conf IPv6 entre les membres du bridge ?
-
Free ne fournit que 8 /64 (un /61 donc).
Il me semble que c'est en fait un /60 en ZMD mais je ne suis pas sûr que l'interface de la box permette de les utiliser.
-
Elle ne le permet effectivement pas, je n'ai que les 8 champs (correspondants au /61) pour mettre un "next hop". Dommage qu'il n'y ait pas de délégation de préfixe.
-
Ben, c'est de la délégation de préfixe là :D
-
Du préfixe /60 entier, je voulais dire :)
-
Je vois pas trop l'utilité, un /61 c'est déjà sympa :)
-
Disons que, quitte à allouer un /60 entier, autant laisser l'utilisateur s'en servir... Je suis arrivé au bout de mon /61, vu qu'on ne peut pas les assigner sur les bridges, par exemple.
-
Sur les bridges ? c'est à dire ?
-
Si je mets une IPv6 directement sur le bridge de mon pfSense plutôt que ses interfaces membres, rien ne fonctionne (pas d'IPv6 sur les PC connectés aux interfaces membres du bridge). Seul problème maintenant : tous les membres du bridges (4 interfaces dessus) ont 4 IPv6 différentes... J'essaie de faire en sorte que chaque PC connecté à une interface ait une IPv6 uniquement sur le préfixe de son interface, sans succès pour le moment...
-
Si je mets une IPv6 directement sur le bridge de mon pfSense plutôt que ses interfaces membres, rien ne fonctionne (pas d'IPv6 sur les PC connectés aux interfaces membres du bridge). Seul problème maintenant : tous les membres du bridges (4 interfaces dessus) ont 4 IPv6 différentes... J'essaie de faire en sorte que chaque PC connecté à une interface ait une IPv6 uniquement sur le préfixe de son interface, sans succès pour le moment...
https://redmine.pfsense.org/issues/4218 (notamment la #4)
en gros: un bridge a pas de link-local ce qui empêche radvd de fonctionner et d'annoncer le prefix aux interfaces du bridge.
il y a une manip pour activer AUTO_LINKLOCAL sur le bridge ce qui lui genere une link-local et permet a radvd de fonctionner.
sinon tu peux aussi ajouter une link-local manuellement au bridge (peut-etre pas avec l'interface toutefois).
A noter que ce bug est ouvert depuis plus de 2 ans... de meme chez OPNsense: https://github.com/opnsense/core/issues/926 mais correction prévue pour le 27 juillet ...
-
Hello je déterre ce sujet a propos du loopback et double nat.
J'ai trouvé la solution avec pfsense. il suffit dans ce cas de créer une ip virtuel avec l'ip public sur l'interface wan. de cette façon on recréer un loopback manuel sur l'ip public. du coup on peut à partir de la créer des ports forward sur l'ip public qui seront rediriger sur l'ip interne. ça marche bien.
-
Salut,
Est-ce que tu peux développer comment tu mets en œuvre cette solution stp ?
J'ai un problème avec un système d'alarme DeltaDore que je suspecte de vouloir utiliser l'UPnP-IGD et NAT Loopback.
Merci par avance.