DISCLAIMER: je ne sais pas si je dois poster cette question ici ou sur FrNog, mais Sag me paraît plus approprié a priori.
Donc voilà :
Hello la foule,
Le serveur de mon bureau (FreeBSD 12.2 stable) possède deux cartes réseau, re0 et ale0. re0 ne sert qu’à connecter le serveur au routeur tête de pont fourni par mon FAI (Celeste). ale0 dessert le réseau local.
Il y a un NAT IPv4 entre ale0 et re0, réalisé par une ligne qui va bien dans /etc/pf.conf. Le serveur tourne (entre autres) un serveur DHCP/DHCP6 sur ale0.
En v4, tout fonctionne nickel, y compris l’accès au réseau des clients VPN (Strongswan).
Le souci, c’est l’IPv6.
Soit P mon préfixe (/64, évidemment).
Initialement, avec ipv6_gateway_enable = YES dans /etc/rc.conf, j’avais configuré re0 en P::ffff/64 (mon routeur tête de pont est en P::1), et ale0 en P::1:0/112 avec une config DHCP6 correspondante. Pour les clients VPN, j’avais P::2:0/112
Problème : rien ne passe de re0 vers ale0. Les pings des machines du réseau local (P::1:XXXX) atteignent leur cible, mais les réponses sont bloquées au niveau de la tête de pont, le gateway émettant des paquets multicast NS fff2::1:xxxx:xxxx auquel le serveur ne répond pas. J’ai essayé d’utiliser ndp(8) pour ‘proxifier’ certaines v6, mais queude. Le serveur reste complètement muet, et ne renvoie jamais de réponse aux sollicitations du gateway, donc les paquets réponse sont perdus. J’ai également tenté d’utiliser rtadvd pour avertir les équipements amont qu’ils communiquaient avec un routeur, mais là aussi, zéro effet.
Alors, vous me direz, le mieux est de créer un bridge entre re0 et ale0. OK, pas de souci : ifconfig bridge0 create addm re0 addm ale0. Fantastique, tout à coup les machines du réseau local peuvent causer IPv6 avec l’extérieur. Le souci, ce sont les clients VPN. Les tunnels fonctionnent en point à point avec le serveur, mais impossible de communiquer avec qui que ce soit d’autre, aussi bien sur ale0 que sur re0. Même souci : les paquets sortent correctement, mais le serveur ne répond pas aux NS par délégation des clients VPN, ni sur re0, ni sur ale0.
D’où ma question : y a-t-il une manip à faire pour forcer ce foutu serveur soit à forwarder les paquets NS vers leurs légitimes destinataires, soit à répondre en leur nom ?
Toute suggestion sera la bienvenue. Merci de votre temps !
Bon week-end !
Vincent
On 17 Jul 2021, at 15:14, Vincent Habchi vincent@geomag.fr wrote:
Blabla
OK. J’ai mis en place un NAT IPv6 (!) pour mes clients VPN. Ça fonctionne. Les paquets sortent avec l’IP du serveur, ça évite les soucis de routage mentionnés.
Désolé du bruit — même si je suis preneur d’une solution plus élégante.
Bonne soirée,
V.
Hello
Est-ce qu'en forward dans pf, tu avais accepté de forward les icmpv6-qui-vont-bien notamment NS ?
Cordialement,
On 17/07/2021 21:52, Vincent Habchi wrote:
On 17 Jul 2021, at 15:14, Vincent Habchi vincent@geomag.fr wrote:
Blabla
OK. J’ai mis en place un NAT IPv6 (!) pour mes clients VPN. Ça fonctionne. Les paquets sortent avec l’IP du serveur, ça évite les soucis de routage mentionnés.
Désolé du bruit — même si je suis preneur d’une solution plus élégante.
Bonne soirée,
V.
Liste de diffusion du FRsAG http://www.frsag.org/
Salut !
Est-ce qu'en forward dans pf, tu avais accepté de forward les icmpv6-qui-vont-bien notamment NS ?
J’avais une ligne ’pass proto icmp6’ quelque part dans mes règles, je l’ai mise à la fin. Si je supprime les lignes NAT, je reviens à l’état antérieur. Ça ne fonctionne pas.
Mon idée est que les paquets multicast ffff::1:… sont limités au brin physique sur lequel ils transitent. Ils ne peuvent pas (normalement) traverser les routeurs. C’est d’ailleurs ce qui me crispe avec la configuration Celeste : ils te livrent un config v6 qui ne fonctionne que sur un monobrin derrière le routeur tête de pont, et apparemment le dernier routeur fonctionne en mode -accept_rtadv puisque les RA que j’envoie sont ignorés (ce qui paraît logique pour un routeur ?).
If_bridge(4) permet de résoudre ce souci élégamment, mais ça n’explique pas pourquoi ndp(8) refuse systématiquement de répondre aux NS qui arrivent côté extérieur.
Merci de ta réponse, bon dimanche !
Vincent
On 18/07/2021 08:55, Vincent Habchi wrote:
Salut !
Est-ce qu'en forward dans pf, tu avais accepté de forward les icmpv6-qui-vont-bien notamment NS ?
J’avais une ligne ’pass proto icmp6’ quelque part dans mes règles, je l’ai mise à la fin. Si je supprime les lignes NAT, je reviens à l’état antérieur. Ça ne fonctionne pas.
Mon idée est que les paquets multicast ffff::1:… sont limités au brin physique sur lequel ils transitent. Ils ne peuvent pas (normalement) traverser les routeurs. C’est d’ailleurs ce qui me crispe avec la configuration Celeste : ils te livrent un config v6 qui ne fonctionne que sur un monobrin derrière le routeur tête de pont, et apparemment le dernier routeur fonctionne en mode -accept_rtadv puisque les RA que j’envoie sont ignorés (ce qui paraît logique pour un routeur ?).
J'ai souvenir que free à l'époque et orange annonce un /64 également. Il faut utiliser un proxy ndp sur la machine en coupure pour "router" les NS de chaque côté. Et j'utilisai (sous linux pour mon cas) radvd pour faire la conf stateless sur mon lan.
As-tu testé ndproxy au lieu de ndp ?
If_bridge(4) permet de résoudre ce souci élégamment, mais ça n’explique pas pourquoi ndp(8) refuse systématiquement de répondre aux NS qui arrivent côté extérieur.
Merci de ta réponse, bon dimanche !
Vincent
-
Vincent Habchi -
Yannick Martin