- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux → Serveur VPN
- Assignée à Personne
- Système d'exploitation Freebox Server V6 (Révolution)
- Sévérité Basse
- Priorité Très Basse
- Basée sur la version 4.5.8
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par XNihili - 03/06/2022
Dernière modification par mmakassikis - 13/06/2022
FS#36703 - Accès partiel au LAN suite à une connexion sur le VPN de la Freebox.
J’ai configuré le serveur VPN de la Freebox.
Dans le réseau j’ai 2 serveurs :
- 192.168.0.99
- 192.168.0.101
Lorsque je suis dans le LAN, j’accède sans souci aux 2 serveurs (ping et ssh).
Lorsque je me connecte via le VPN (Wireguard et OpenVPN Routé), j’accède à 192.168.0.101 mais j’ai un timeout sur le 192.168.0.99.
A noter que si je me connecte sur le 192.168.0.101, je peux accéder à 192.16.0.99.
Toujours via le VPN, si je fait un traceroute vers 192.168.0.101, ça part sur la freebox avant d’arriver à 192.168.0.101. Quand je fais un traceroute vers 192.168.0.99, ça part sur la freebox avant de faire un timeout.
Enfin si j’utilise le VPN PPTP je n’ai aucun souci mais le traceroute a l’air de m’envoyer directement sur les serveurs sans passer par la Freebox.
Est-ce que ce problème vous dit quelque chose ? Comme je n’ai pas accès aux logs des serveurs VPN de la Freebox, je ne peux pas vérifier s’il y a un problème de routage.
13.06.2022 09:59
Raison de la fermeture : Résolu
Commentaires de fermeture :
problème sur la config des serveurs
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Le routage n’est pas différent selon le type de VPN.
Avez-vous la possibilité de faire une capture tcpdump/wireshark sur 192.168.0.99 ?
Est-ce que vous avez testé de pinger l’équipement connecté en VPN depuis 192.168.0.99/101 (l’IP est visible dans FreeboxOS) ?
Bonjour,
Merci pour ces pistes.
Effectivement le ping depuis 192.168.0.99 vers l’équipement en VPN (192.168.27.65) échoue alors que depuis 192.168.0.101 ça marche.
J’ai installé tcpdump sur 192.168.0.99 mais j’avoue ne pas trop bien connaitre l’outil.
J’ai essayé d’attraper le ping en échec avec : sudo tcpdump -i any -w log.pcap icmp
Mais ça me donne des appels vers des IP qui ne correspondent à rien.
J’ai peur que les containers dockers pourrissent le résultat.
1 0.000000 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
2 0.000028 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
3 0.000112 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
4 0.000119 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
5 0.000174 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
6 0.000180 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
7 3.071965 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
8 3.071987 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
9 3.072027 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
10 3.072031 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
11 3.072056 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
12 3.072059 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
13 3.359955 192.168.16.1 192.168.16.1 ICMP 132 Destination unreachable (Host unreachable)
14 3.359982 192.168.16.1 192.168.16.1 ICMP 132 Destination unreachable (Host unreachable)
15 3.360003 192.168.16.1 192.168.16.1 ICMP 132 Destination unreachable (Host unreachable)
16 6.143968 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
17 6.143993 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
18 6.144062 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
19 6.144069 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
20 6.144118 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
21 6.144125 192.168.0.99 172.25.0.3 ICMP 108 Destination unreachable (Host unreachable)
22 6.431973 192.168.16.1 192.168.16.1 ICMP 132 Destination unreachable (Host unreachable)
Sur 192.168.0.101 c’est propre :
1 0.000000 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=1/256, ttl=64 (reply in 2)
2 0.105951 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=1/256, ttl=63 (request in 1)
3 1.001197 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=2/512, ttl=64 (reply in 4)
4 1.088922 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=2/512, ttl=63 (request in 3)
5 2.002203 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=3/768, ttl=64 (reply in 6)
6 2.072204 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=3/768, ttl=63 (request in 5)
7 3.003463 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=4/1024, ttl=64 (reply in 8)
8 3.057050 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=4/1024, ttl=63 (request in 7)
9 4.005370 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=5/1280, ttl=64 (reply in 10)
10 4.038162 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=5/1280, ttl=63 (request in 9)
11 5.006085 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=6/1536, ttl=64 (reply in 12)
12 5.046164 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=6/1536, ttl=63 (request in 11)
13 6.007442 192.168.0.101 192.168.27.65 ICMP 98 Echo (ping) request id=0x000e, seq=7/1792, ttl=64 (reply in 14)
14 6.127495 192.168.27.65 192.168.0.101 ICMP 98 Echo (ping) reply id=0x000e, seq=7/1792, ttl=63 (request in 13)
Bon je pense que ce n’est pas un pb avec la freebox mais avec les interfaces de mon cluster kubernates. Merci pour l’aide, je ferme la demande
Le problème avec “-i any” est que finalement vous ne savez pas sur quelle interface arrivent les paquets …
Vous pouvez faire “-i eth0 icmp” et voir en live si les paquets arrivent à destination.
Sinon depuis 192.168.0.99, vous pouvez faire “ip route get 192.168.27.65” (remplacer l’ip par celle attribuée par le VPN): vous verez par quelle interface l’hôte pense pouvoir joindre le client connecté en VPN.