vpn et sfrbox hd probleme ? Le sujet est résolu

[Tachyon]

Bonsoir,

j’étais aujourd’hui sur une box sfr HD, je branche mon raspberry et je me sers de mon vpn comme d'habitude pour le travail sauf que là , rien , pas de sortie et pas d'entrée

je regarde les configs de la box , ipsec et pptp son bien cocher , pas de firewall en fonction ...

La box sfr bloquerais le vpn quelque part d'autre ?

[Grhim]

attention , je ne suis pas un pro du Vpn, mais se sont des configs différentes si tu utilise openvpn et si la box sfr fonctionne sous PPTP/Ipsec
essais la config PPTP par exemple

[Tachyon]

effectivement j'utilise Openvpn et d’après la notice que j'ai pu lire , la sfr box ne prend en compte que le pptp et ipsec , ce qui est très ennuyeux ...
OpenVpn est quand même le protocole le plus sécurisé, ça m'embête de devoir utiliser pptp ... et ipsec est lent !

existe-t-il un moyens de contourner le problème ?

ce qui est étrange c'est que sur mon android auquel celui-ci est connecter au wifi de la box Sfr, j'ai l'application de mon fournisseur Vpn et ça fonctionne...

[Grhim]

Openvpn est le plus configurable je te l'accorde mais je crois qu'il existe le proto sstp https://secuweb.fr/comparatif-protocoles-vpn/

existe-t-il un moyens de contourner le problème ?

acheter un routeur dd-wrt vpn support par exemple , mais il va falloir mettre la super box fibre en mode bridge, je ne sais pas si c'est intéressant si tu a d'autres appareils à connecter sur le mode routeur de la box...

ce qui est étrange c'est que sur mon android auquel celui-ci est connecter au wifi de la box Sfr, j'ai l'application de mon fournisseur Vpn et ça fonctionne...

dans ce cas il faudrait que tu test via un live Debian en usb , faire ta config via openvpn et voir si ça ne vient pas de ton raspberry

[PascalHambourg]

je me sers de mon vpn comme d'habitude pour le travail sauf que là , rien , pas de sortie et pas d'entrée

C'est-à-dire ?
Le tunnel est-il monté ?
Si oui, quels tests de connectivité as-tu faits ?
Les adresses et routes sont bien présentes ?
Pas de collision entre les plages d'adresses des réseaux local et distant ?
Si non, que disent les logs d'openvpn ?

la sfr box ne prend en compte que le pptp et ipsec

A cause de leurs particularités, les protocoles PPTP et IPSec peuvent nécessiter une prise en charge spécifique par les dispositifs de NAT tels que les box internet. Ce n'est pas le cas du protocole d'openvpn qui ne nécessite aucune prise en charge particulière., pas plus que DNS ou HTTP. C'est un simple flux UDP ou TCP.

[Tachyon]

Le tunnel est-il monté ?
Si oui, quels tests de connectivité as-tu faits ?
Les adresses et routes sont bien présentes ?
Pas de collision entre les plages d'adresses des réseaux local et distant ?

pas fait de tests de connectivité mis a part des ping qui ne me renvois rien

tout est nikel chrome juste que je n’atteint aucunes pages et dés que je l’arrête la page qui était en attente s'affiche ..

j'ai noté une chose c'est qu'il se connecte si je ne dis pas de bêtises sur 192.168.0.1 alors que je suis en 192.168.0.23 c'est peut etre la cause ?

les protocoles PPTP et IPSec peuvent nécessiter une prise en charge spécifique par les dispositifs de NAT tels que les box internet

je test demain puis ferais un retour

merci du coup de main

[PascalHambourg]

Si je comprends bien, le VPN monte ? Qu'y a-t-il à l'autre bout ?

j'ai noté une chose c'est qu'il se connecte si je ne dis pas de bêtises sur 192.168.0.1 alors que je suis en 192.168.0.23 c'est peut etre la cause ?

Qu'entends-tu exactement par "il se connecte sur 192.168.0.1" et "je suis en 192.168.0.23" ? Qui est "il", qui est "je" ?
Peux-tu montrer ce que tu vois ?

[Tachyon]

Peux-tu montrer ce que tu vois ?

avec plaisir , voici un ifconfig -a
img

iftop -i wlan0 :>

img

et openvpn :

img

[PascalHambourg]

Ce serait mieux de copier/coller le texte brut entre balises de code plutôt que des images d'écran.

192.168.0.23 est l'adresse IP attribuée à l'interface wifi.
192.168.0.1 est a priori l'adresse IP locale de la box internet.
Rien d'anormal ici, c'est du classique.

Peux-tu poster (en texte) la sortie des commandes suivantes ?

Code : Tout sélectionner

ip -4 addr
ip -4 route
cat /etc/resolv.conf

pas fait de tests de connectivité mis a part des ping qui ne me renvois rien

Peux-tu montrer les commandes et les sorties (en texte brut) ?

Je ne comprends pas ceci :

je me sers de mon vpn comme d'habitude pour le travail

Je pensais donc que ce VPN servait à te connecter à un réseau d'entreprise distant.

je n’atteint aucunes pages et dés que je l’arrête la page qui était en attente s'affiche

Si la page s'affiche hors VPN, c'est donc qu'elle n'est pas hébergée sur le réseau d'entreprise distant.
Peux-tu expliquer cette apparente contradiction ? A quoi te sert exactement ce VPN, à quoi est-il connecté ?

[Tachyon]

Peux-tu poster (en texte) la sortie des commandes suivantes ?

Code : Tout sélectionner

ip -4 addr
ip -4 route
cat /etc/resolv.conf

Code : Tout sélectionner

$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.0.23/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 46839sec preferred_lft 46839sec
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet 5.249.162.194/27 brd 5.249.162.223 scope global tun0
       valid_lft forever preferred_lft forever

Code : Tout sélectionner

$ ip -4 route
0.0.0.0/1 via x.xxx.xxx.xxx dev tun0 
default via 192.168.0.1 dev wlan0 proto dhcp metric 600 
unreachable 1.53.41.196 scope host 
5.249.162.192/27 dev tun0 proto kernel scope link src 5.249.162.194 
unreachable 23.239.1.78 scope host 
unreachable 37.79.37.22 scope host 
unreachable 37.220.180.39 scope host 
unreachable 51.38.12.12 scope host 
80.67.8.196 via 192.168.0.1 dev wlan0 
unreachable 86.108.4.157 scope host 
unreachable 111.35.43.122 scope host 
unreachable 115.238.245.8 scope host 
unreachable 117.248.32.127 scope host 
unreachable 124.150.89.39 scope host 
128.0.0.0/1 via 5.xxx.162.xxx dev tun0 
unreachable 128.14.255.162 scope host 
unreachable 157.0.130.206 scope host 
unreachable 167.99.156.12 scope host 
unreachable 171.38.148.129 scope host 
unreachable 178.46.13.33 scope host 
unreachable 181.29.205.137 scope host 
unreachable 184.105.139.79 scope host 
unreachable 185.254.122.201 scope host 
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.23 metric 600 
unreachable 195.231.5.79 scope host 
unreachable 197.43.198.60 scope host 
unreachable 202.8.222.119 scope host 

Code : Tout sélectionner

~$ cat /etc/resolv.conf
# Generated by NetworkManager
search numericable.fr
nameserver 89.2.0.1
nameserver 89.2.0.2

pour le ping google.fr , je le fais sous connexion Openvpn , une fois aue j'ai appuyer sur la touche enter rien ne s'affiche

Code : Tout sélectionner

~$ !!
sudo ping google.fr
puis quelques minute apres : ping: google.fr: Temporary failure in name resolution

Je pensais donc que ce VPN servait à te connecter à un réseau d'entreprise distant.

j'ai besoin d'un vpn pour le travail et en général aussi (préférence personnel)

Je vais tester en passant par PPTP juste pour voir si la connexion se fait , cela voudrais dire que la boxsfr fait des sienne !?

[PascalHambourg]

Comment se fait-il que l'adresse IP de l'interface tun soit complètement différente de sur tes captures d'écran ? C'était une adresse privée en 10.*, maintenant c'est une adresse publique en 5.*.

.

sudo ping google.fr puis quelques minute apres : ping: google.fr: Temporary failure in name resolution

1) Pas besoin de sudo pour faire un ping.
2) Ça, ce n'est pas un ping : c'est une résolution de nom suivie, si et seulement si elle réussit, d'un ping. Or on peut voir que la résolution de nom échoue, donc pas de ping envoyé. Un ping, ça se fait avec une adresse IP comme cible (connue pour répondre au ping) afin de s'affranchir d'un éventuel problème de résolution de noms. Par exemple le bien connu 8.8.8.8.

On peut voir dans resolv.conf que ce sont des DNS de Numericable qui sont utilisés. Pourquoi pas avec une box SFR, depuis la fusion entre Numericable et SFR (ou le rachat de l'un par l'autre, je ne sais plus). Par contre il est probable que ces DNS ne répondent qu'aux requêtes provenant d'adresses IP appartenant au réseau de Numericable ou SFR, ce qui n'est pas le cas de l'adresse IP du VPN. Le problème pourrait venir de là. Tu as peut-être eu de la chance sur les autres réseaux locaux où c'est la box qui était utilisée comme DNS. Dans ce cas il te faudra configurer ton openvpn pour utiliser un DNS joignable depuis le VPN.

[Tachyon]

Je suis bien connecter sur la box en pptp,

En effet la Box sfrHD n'utilise que pptp/Ipsec.....

pour utiliser Openvpn il faut mettre la box sur bridge et connecter un routeur par dessus , merci sfr....

Code : Tout sélectionner

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet 10.20.40.2  netmask 255.255.255.255  destination 10.20.40.1
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 11  bytes 469 (469.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 281 (281.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Comment se fait-il que l'adresse IP de l'interface tun soit complètement différente de sur tes captures d'écran ? C'était une adresse privée en 10.*, maintenant c'est une adresse publique en 5.*.

J'imagine qu'a chaques tentatives de connection il attribu l'un ou l'autre ?

pour revenir sur le ping 8.8.8.8 , c'est tout bete, mais une fois fait chmod u+s `which ping` , c'est mieux :

Code : Tout sélectionner

~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=53.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=55.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=48.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=50.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 48.401/51.830/55.378/2.636 ms

[PascalHambourg]

En effet la Box sfrHD n'utilise que pptp/Ipsec.....
pour utiliser Openvpn il faut mettre la box sur bridge et connecter un routeur par dessus

Je reste persuadé que la box n'a rien à voir et c'est juste un problème de configuration DNS sur ta machine, car le tunnel montait bien.
Tu as vraiment testé openvpn avec la box en mode bridge et un routeur ?

Comment se fait-il que l'adresse IP de l'interface tun soit complètement différente de sur tes captures d'écran ? C'était une adresse privée en 10.*, maintenant c'est une adresse publique en 5.*.

J'imagine qu'a chaques tentatives de connection il attribu l'un ou l'autre ?

Ce n'est pas normal. Les deux types d'adresse n'ont pas le même usage. Trouverais-tu normal que la box t'attribue tantôt une adresse publique et tantôt une adresse privée ?

pour revenir sur le ping 8.8.8.8 , c'est tout bete, mais une fois fait chmod u+s `which ping` , c'est mieux

Mieux que quoi ? Ce n'est certainement pas cela qui a corrigé l'erreur "Temporary failure in name resolution" que tu rencontrais. L'absence du bit "s" (SUID) peut être normale : si le système de fichiers supporte les attributs étendus, la commande utilise la "capacité" cap_net_raw et n'a pas besoin du SUID.

[Tachyon]

Ce n'est pas normal. Les deux types d'adresse n'ont pas le même usage. Trouverais-tu normal que la box t'attribue tantôt une adresse publique et tantôt une adresse privée ?

effectivement, excuse-moi, j'ai regardé mes manipulations faites la dernière fois, et j'avais essayé plusieurs configurations avec le fichier ovpn dont un en essayant avec ce même fichier pour le protocole Pptp, ça a foutu un peu le boxon, je crois que ça viens de là.

Je reste persuadé que la box n'a rien à voir et c'est juste un problème de configuration DNS sur ta machine,

Tu as encore une fois raison Pascal, j'ai testé avec le DNS de cloudflare (1.1.1.1) dans /etc/resolv conf et je me connecte sans problème via Openvpn

Ce sont les dns de numericable/sfr qui bloque Openvpn

[PascalHambourg]

et j'avais essayé plusieurs configurations avec le fichier ovpn dont un en essayant avec ce même fichier pour le protocole Pptp,

Je ne suis pas sûr de comprendre ce que tu veux dire. A ma connaissance, openvpn n'utilise que son propre protocole, il ne peut pas utiliser le protocole PPTP. Pour utiliser le protocole PPTP il faut un client comme pptp-linux, soit directement avec pppd soit via un greffon de gestionnaire de réseau comme network-manager-openvpn.

Ce sont les dns de numericable/sfr qui bloque Openvpn

Pas du tout. Les DNS de Numericable/SFR, comme les DNS de tous les autres FAI, refusent de répondre aux adresses IP n'appartenant pas à ce FAI. Quand tes communications passent par un VPN, tu n'es plus identifié comme client du FAI d'origine mais comme client du fournisseur du VPN. Tu dois donc soit utiliser les DNS fournis par le VPN (je suppose que c'est le cas avec la configuration PPTP), soit utiliser des DNS publics qui répondent à tout le monde (Google, OpenDNS, CloudFlare...), soit utiliser le DNS de la box (je suppose que c'était le cas quand tu étais connecté à d'autres box), les requêtes se faisant sur le réseau local sans passer par le VPN.

Mais attention : quand tu utilises le DNS de la box, tes requêtes DNS transitent en clair jusqu'aux DNS du FAI, donc même sans voir le trafic chiffré qui transite par le VPN, on (et notamment le FAI) peut savoir à quels sites tu te connectes. Et si un site reçoit une connexion depuis l'adresse du VPN juste après que le serveur DNS de son domaine a reçu une requête depuis l'adresse de la box, alors il peut faire le lien entre les deux adresses. Bonjour la confidentialité.

[Tachyon]

Mais attention : quand tu utilises le DNS de la box, tes requêtes DNS transitent en clair jusqu'aux DNS du FAI, donc même sans voir le trafic chiffré qui transite par le VPN, on (et notamment le FAI) peut savoir à quels sites tu te connectes. Et si un site reçoit une connexion depuis l'adresse du VPN juste après que le serveur DNS de son domaine a reçu une requête depuis l'adresse de la box, alors il peut faire le lien entre les deux adresses. Bonjour la confidentialité.

Comment? je ne savais pas , mais comment être vraiment safe si le fai comprend le vpn ? elle est où ma confidentialité?

[PascalHambourg]

Le FAI ne comprend pas le VPN, il voit le trafic DNS et autre qui passe en clair hors du VPN.

Le VPN ne transporte que les communications directes avec des machines situées au delà du réseau local. Quand tu utilises le DNS de la box qui se trouve dans le réseau local, tu lui envoies les requêtes DNS en clair, en dehors du VPN, et la box les relaie vers les DNS du FAI, toujours en clair..

J'ai déjà expliqué ce qu'il faut faire pour éviter cela : lorsque le VPN est monté, il faut utiliser directement des DNS situés au delà du réseau local afin que les requêtes transitent par le VPN. Mais cela ne peut pas être les DNS du FAI car ils ne reconnaîtront pas l'adresse de sortie du VPN comme appartenant au FAI.

[Tachyon]

J'ai déjà expliqué ce qu'il faut faire pour éviter cela : lorsque le VPN est monté, il faut utiliser directement des DNS situés au delà du réseau local afin que les requêtes transitent pas le VPN. Mais cela ne peut pas être les DNS du FAI car ils ne reconnaîtront pas l'adresse de sortie du VPN comme appartenant au FAI.

donc en prenant les dns de cloudflare ou autre, c'est ok ? ou faut-il un fichiers de configuration propre à Openvpn ?

[PascalHambourg]

Je ne connais pas les DNS de Cloudflare mais tu peux utiliser n'importe quels serveurs DNS récursifs publics ou ceux fournis par le fournisseur du VPN le cas échéant lorsque le VPN est monté.

OpenVPN peut configurer des DNS lorsque le tunnel monte grâce à des options dhcp-option DNS [adresse] si le paquet resolvconf est installé. Cette option peut être définie localement dans la configuration du client ou poussée par le serveur avec une option push et prise en compte par le client avec l'option pull, éventuellement autorisée par une option pull-filter accept "dhcp-option DNS".

[piratebab]

Pascal,

J'ai déjà expliqué ce qu'il faut faire pour éviter cela : lorsque le VPN est monté, il faut utiliser directement des DNS situés au delà du réseau local afin que les requêtes transitent pas le VPN

Si j'ai bien compris, coté client, tu fais en sorte qu'il contacte directement le DNS.
Comme ca, impossible de faire le lien entre la requête DNS (qui vient du PC client), et la connexion au serveur de contenu qui passe par le LAN, et donc sort du LAN via la box.
C'est bien ça ?