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

UseDNS était commenté, je l'ai mis à NO et relancé le service mais pas de changement. Dans les logs rien d'anormal côté clés entre autres mais j'ai ceci quand je suis hors VPN :

- En SSH, ça finit par se connecter une fois sur 10 mais j'ai ces lignes dans les logs :
"Connection closed by ::1 port xxxxx [preauth]" puis "Accepted password for User from XX.XX.XX.XX port YYYYY ssh2 quand la connexion est OK

- En SFTP via FileZilla, la connexion ne passe pas du tout : même lignes (mais le délai time-out doit être plus court)

Avec VPN monté ça fonctionne de suite. De même sans VPN, avec une SIM d'un autre opérateur, ça fonctionne de suite.

Ce n'est donc pas ma configuration :

https://www.universfreebox.com/article/584404/2-bugs-genants-ont-ete-reperes-suite-a-la-derniere-mise-a-jour-freebox

En fait ça doit dater à peu près des débuts de la 4.9. Mais j'avais un plus gros problème avec cette mise à jour, j'ai passé un mois à faire des tests avec l'assistance et même changé de Freebox. L'assistance a même mis en doute mon installation électrique, finalement le problème a été corrigé avec la 4.9.2 (problèmes de Kernel Panic).

La configuration de mes serveurs n'ayant pas changé depuis plus d'un an, je doute que ça vienne d'un paramètre sur ceux-ci. Je vais éviter cette fois les tests à n'en plus finir, à la limite je peux connecter l'un de mes serveurs sur la box d'un autre opérateur pour confirmer que ça fonctionne ailleurs, mais il faudra patienter au moins 3 semaines.

Précision : l'accès fonctionne sans VPN, depuis un partage Free Mobile, avec l'adresse IP mais pas avec le nom de domaine.

Par contre depuis une SIM SFR, la connexion fonctionne via l'adresse IP ET le nom de domaine

Bonjour

Ayant pas mal travaillé sur SSH ces derniers temps, je vais essayer de vous faire une réponse moins bidon que l'article non fondé d'universfreebox

Déjà sur les SIM des autres opérateurs, forcez l'APN en IPv6 et désactivez celui en IPv4 et je suis certain que vous aurez les même soucis que depuis les SIM Free Mobile qui je crois push les 2 APN v4 v6 avec probablement une precedence pour v6

Idem sur les VPN, montez un VPN ipv6 only et vous devriez avoir les même soucis.

—-
Je suppose que vous êtes sous Linux.

Solution 1 - dirty
Sur le client, éditez le fichier /etc/gai.conf et modifiez la précédence IPv4 / IPv6

sudo vi /etc/gai.conf

décommentez la ligne:

precedence ::ffff:0:0/96  100

Si le client est un windows, je pense qu'on doit pouvoir faire pareil avec netsh (après je ne connais pas windows, donc je suppose)
qqch comme:

Trouvez la valeur associée à `::/0`

netsh interface ipv6 show prefixpolicies

Et mettez une valeur plus grande à '::ffff:0:0/96', ici j'ai mis 10 (le dernier terme)

netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 60 10
netsh interface ipv6 reset

Solution 2 - prefered
Assignez une des très nombreuses IPv6 publique disponible sur la connexion à la machine cible (la machine qui à un NAT du port 22 en IPv4) en mode ipv6 fixe, sans utiliser SLAAC mais plutôt qqch comme

ip -6 add add 2a01:e0xx:xxxx:xx0::xxxx:xxxx/64  dev <interface>

Pour l'exemple dans mon lab j'ai une machine qui s'appelle: deb13-lab-10c
J'ai mis comme adresse: 2a01:e0x:xxxx:xxx5:0:deb1:31ab:10c ce qui donne:

ip -6 add add 2a01:e0x:xxxx:xxx5:0:deb1:31ab:10c/64  dev enp12s1f15

Puis renseignez vos DNS comme suit:

$TTL 180
zone domain.tld

machine.domain.tld.    $TTL    IN    A       ip-public-freebox
machine.domain.tld.    $TTL    IN    AAAA    ipv6-public-du-server-ssh-derriere-le-nat-ipv4

Avec la machine de mon lab, ça donne:

$TTL 180
zone my-public-domain.net
deb13-lab-10c.my-public-domain.net.    $TTL    IN    A       82.6x.xxx.xx8
deb13-lab-10c.my-public-domain.net.    $TTL    IN    AAAA    2a01:e0x:xxxx:xxx5:0:deb1:31ab:10c

Vous ne devriez plus avoir de problèmes.

Dans le cas ou vous auriez toujours des soucis, il faudrait:

1) faire un tcpdump en ipv4 + en ipv6 sur le client et sur le serveur:

tcpdump -nnei <interface> -vvvtttXXX 'host <ip_client> and host <ip_server>' -w client.pcap
# et
tcpdump -nnei <interface> -vvvtttXXX 'host <ip_client> and host <ip_server>' -w server.pcap

2) Puis ouvrir le pcap avec `tshark -Vr client.pcap` ou `tshark -Vr server.pcap` pour analyse.

3) En parallèle, je vous recommande de build une version DEBUG de SSH:

git clone https://github.com/openssh/openssh-portable.git
mv openssh-portable openssh-portable-debug
cd openssh-portable-debug
./configure CFLAGS="-g -O0 \
-DDEBUG \
-DDEBUG_CHANNEL_POLL \
-DDEBUG_CONSTRAINTS \
-DDEBUG_KEX \
-DDEBUG_KEX_COOKIE \
-DDEBUG_KEXDH \
-DDEBUG_KEXECDH \
-DDEBUG_KRL \
-DDEBUG_PK \
-DDEBUG_SK \
-DDEBUG_SNPRINTF \
-DDEBUG_SSH_KEYSIGN"
make

4) puis utiliser la version de debug avec une commande du type:

/usr/src/build/openssh-portable-debug/ssh -vvvF none user@server.domain.tld

5) Vous pouvez aussi reproduire sur le server ssh:
Après avoir build une version debug de SSH sur le server également, vous pouvez lancer une nouvelle instance de sshd en mode debug sur un autre port (222 pour l'exemple)

sudo /usr/src/build/openssh-portable-debug/sshd -dddDe -f none -h /etc/ssh/ssh_host_ed25519_key -p222

Puis vous rajouter un DNAT en IPv4 pour joindre le serveur sur le port 222 depuis l'ipv4 publique de la Freebox.

Ensuite il faut reproduire le souci, récupérer les traces (très verbeuses) côté client + server et les 4 captures tcpdump (server + client en v4 + en v6) et analyser tout ça pour voir ou ça coince.

6) Me contacter si besoin pour analyse

7) Nota Bene:
j'ai pas mal travaillé sur SSH et ce que je peux vous dire c'est que le debug de SSH est très compliqué sans décrypter car dans le handshake SSH permettant d'établir le flux après msg_code 21 (NEWKEYS) à la 3è frame envoyée par le server et à la 4è frame ssh envoyée par le client, tout est crypté donc impossible de debug sans décrypter en live

voici un handshake SSH typique sur la dernière version d'OpenSSH disponible sur github (kex: mlkem768x25519-sha256, cipher: chacha20-poly1305):

frame 1 client:  Protocol (SSH-2.0-OpenSSH_10.0)
frame 1 server:  Protocol (SSH-2.0-OpenSSH_10.0 nba-debug)
frame 2 client:  msg_code 20 Key Exchange Init
frame 2 server:  msg_code 20 Key Exchange Init
frame 3 client:  msg_code 30 Client: PQ/T Hybrid Key Exchane Init
frame 3 server:  msg_code 31 Server: PQ/T Hybrid Key Exchange Reply, msg_code 21 New Keys, msg_code 7 Extension Information **Encrypted packet**
frame 4 client:  msg_code 21 New Keys, msg_code 7 Extension Information **Encrypted packet**
frame 4 server:  msg_code 5  Service Request **Encrypted packet**
frame 5 client:  msg_code 6  Service Accept **Encrypted packet**
...
frame 10 client  msg_code 98  Channel Request **Encrypted packet**
frame 10 server  msg_code 99  Channel Success **Encrypted packet**
...

Et c'est seulement à partir de ce "Channel Success" qu'une session 'exec' ou 'shell' peut s'établir (lire que la connexion est utilisable)

Aussi vous noterez que j'ai énuméré les msg_code par coeur après la frame 'msg_code 21' (server frame 3 / client frame 4), car partout ou vous voyez Encrypted packet, eh bien c'est crypté donc impossible d'avoir la fin du handshake sans décrypter la frame au préalable, puis les clés changent périodiquement à chaque REKEY donc il faut calculer de nouveau le shared_secret, dériver les iv + clés symétriques, etc… pour pouvoir continuer de décrypter.

Si besoin d'aller plus loin dans le debug contactez moi et je vous dirais comment et ou patcher le code source d'OpenSSH pour décrypter le flux en live (sans proxy ou hack du type man-in-the-middle) afin de pouvoir debug

Cordialement
nbanba

J'ai fait plus l'inverse : j'ai désactivé l'IPv6 de l'APN Free Mobile puisque je n'utilise que de l'IPv4. C'était désactivé sur la box et les serveurs mais pas côté Smartphones pour le partage de connexion.

Bonjour

IPV6 étant :
- l'avenir
- inévitable à terme

Je vous invite à utiliser la "solution 2" de mon précédent message plutôt que de vous enfermé dans un workarround périmé et non viable à terme.

PS: c'est facile ! surtout que vous avez l'air de connaître Linux…

Cordialement
nbanba

Bonjour

Question :
Comment faites vous pour désactiver l'ipv6 sur la freebox ?

Cela semble techniquement impossible, l'ipv4 étant transporté par des trames ipv6, le réseau Free étant en ipv6 natif.

Cordialement
nbanba