# Réseau local VPN non pingable Mac



## FruitSellers (23 Octobre 2015)

Bonjour,

Je m'arrache les cheveux depuis plusieurs semaine sur la constitution de mon VPN.

Je m'explique, j'ai chez moi un serveur OpenVPN qui tourne sous Débian, j'ai aussi un serveur Windows Home Server dans ce même réseau.

L'idée c'est que je puisse me connecter au VPN pour accéder au donnée du serveur Windows, tout est bien configuré puisque j'accède bien au serveur Windows de mon réseau local depuis l'extérieur (192.168.1.17) lorsque j'utilise un pc Windows (Seven).

Par contre depuis mon Mac, absolument impossible, je suis bien connecté au VPN puisque mon IP publique est celle du réseau distant, mais impossible d'avoir accès au réseau local, comme si les routes était mauvaise, pourtant elles sont bonnes puisque j'y accède depuis un poste sous Windows, j'ai plus l'impression qu'un protocole pose problème.


Si vous avez la moindre idée je suis preneur parce que la je ne trouve plus..


----------



## Polo35230 (23 Octobre 2015)

Je ne sais pas si j'ai bien compris…
Client VPN Seven—internet—Box—Serveur OpenVPN—Serveur windows (192.168.1.17)     Le ping 192.168.1.17 est bon
Client VPN Mac   —internet—Box—Serveur OpenVPN—Serveur windows (192.168.1.17)     Le ping 192.168.1.17 ne marche pas
C'est ça?
Es-tu sûr que l'adresse IP privée du client VPN Mac n'est pas aussi utilisée sur ton Lan?
C'est le serveur VPN qui  attribue des adresses privées sur une plage différente (mais dans le même plan IP) de celles utilisées sur ton Lan?
Si ce n'est pas le serveur qui attribue les adresses, es-tu sûr de la conf réseau côté client? 
Le protocole VPN utilisé sur le client Mac est-il le même que celui qui marche avec le client seven?
A partir du client VPN Mac, peux-tu pinguer le serveur VPN où d'autres machines de ton Lan?
As-tu essayé de faire un traceroute 192.168.1.17 pour voir jusqu'où tu vas?

Pas simple. Pour avancer, si tu n'as pas d'idée, sur le client Mac, relève son adresse IP privée (celle en 192.168.1.xxx), puis sur le serveur vpn, fais un:
tcpdump host 192.168.1.xxx
Ensuite, sur le client, fais un ping 192.168.1.17
On verra si on sort bien du serveur VPN.


----------



## FruitSellers (23 Octobre 2015)

Salut Polo35230,

Tu as bien compris ce que j'ai essayé d'expliquer, pour expliqué un peu plus précisément, j'ai suivi ce tuto la http://blog.nicolargo.com/2010/10/installation-dun-serveur-openvpn-sous-debianubuntu.html

Du coup lors de la configuration du fichier "server.conf" je me retrouve avec des IP de client avec du 10.8.0.xxx (si j'ai bien compris le tuto).
Et apparement c'est le serveur VPN qui translate les IP client avec un forward vers les IP du réseau local du VPN (192.168.1.xxx)

Du coup j'ai comme adresse sur mon client mac 10.8.0.6.

Est ce que je dois faire un tcpdump host 10.8.0.6 sur le serveur VPN?


----------



## FruitSellers (23 Octobre 2015)

Je viens de faire un essai avec le client Windows, même adresse IP privée que le client Mac et pourtant j'ai bien accès au réseau local distant sur Windows, c'est fou :O


----------



## Polo35230 (23 Octobre 2015)

Perso, je n'aurais pas fait comme ça.
Le principe du VPN, c'est que ttes les machines (locales et distantes) soient dans le même réseau privé.
Dans ton cas, tu dois avoir un réseau local en 192.168.1.0/24  (masque en 255.255.255.0)
La box à 192.168.1.1 comme adresse IP. Elle doit être serveur DHCP sur ton Lan; Plage distribuée de 10 à 50 par exemple.
Tu peux aussi avoir les machines en IP fixes sur ton Lan (par exemple de 51 à 100).
Maintenant, ton serveur VPN doit distribuer des adresses à partir de 101 à 200 (par exemple)et avec un masque 255.255.255.0.
Tout le monde se trouvera ainsi dans le même réseau local sans risquer d'avoir des adresses en double.

Ta conf peut marcher, mais ce n'est pas vraiment naturel… La partie VPN se trouve sur un plan en 10.8.0.0/16 peut-être, et ton lan en 192.168.1.0/24
Le serveur VPN doit donc avoir deux interfaces; L'une en 10, et l'autre en 192.
Pour moi, le serveur ne natera pas; c'est du routage par interface. Ca doit marcher aussi.

Pour le tcpdump, il faut le faire sur 192.168.1.17.

Maintenant, le pb sur le pc, c'est que l'adresse 192.168.1.17 ne passe pas par le VPN (qui lui est en 10.) alors que pour le mac, ça passe (pourquoi?)


----------



## FruitSellers (23 Octobre 2015)

Du coup j'ai fait la modification des Ip, tout est en 192.168.1.xxx
Et même problème, le client Windows ping tout le réseau local par contre rien pour le client .Mac, c'est vraiment étrange, j'ai comme l'impression que ma box ou autre chose refuse ou empêche le Mac d'être routé dans le réseau local distant.


----------



## Polo35230 (23 Octobre 2015)

FruitSellers a dit:


> c'est vraiment étrange, j'ai comme l'impression que ma box ou autre chose refuse ou empêche le Mac d'être routé dans le réseau local distant.


je ne pense pas que ce soit ça.
Un ping, c'est du protocole icmp. Exactement le même message, que ce soit le mac ou un pc qui l'envoie.
Le pb doit être ailleurs.
Il faut essayer de voir où ça coince.

-Sur le client Mac, passer les commandes suivantes:
traceroute 192.168.1.17
ifconfig
netstat -r

-sur le serveur vpn:
tcpdump host 192.168.1.xxx  (adresse IP du client)         
puis faire un ping 192.168.1.17 à partir du client


----------



## FruitSellers (23 Octobre 2015)

Je viens de faire ta procédure, alors pour le tcpdump, parfois je vois des choses passé, parfois rien.

Au niveau du ping toujours rien, enfin si j'ai remarqué que le message que m'affiche le terminal est 
"ping: sendto: No route to host"
puis 
"ping: sendto: Host is down"


----------



## Polo35230 (23 Octobre 2015)

Peux-tu faire un copier-coller du tcpdump stp?


----------



## FruitSellers (23 Octobre 2015)

Polo35230 a dit:


> Peux-tu faire un copier-coller du tcpdump stp?



tcpdump host 192.168.1.106

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

23:17:22.159931 IP 192.168.1.106.56029 > 173.194.135.114.http: Flags [F.], seq 2799739463, ack 2109782072, win 4096, options [nop,nop,TS val 847679439 ecr 162232861], length 0


Ca c'est quand je navigue sur le web depuis le client, lorsque je cherche à ping ou traceroute, rien dans le tcpdump


----------



## Polo35230 (23 Octobre 2015)

192.168.1.106 c'est le client?
Le tcpdump est bien fait sur le serveur?

-Sur le client Mac, peux-tu faire un copier coller des commandes suivantes:
traceroute 192.168.1.17
ifconfig
netstat -r


----------



## FruitSellers (23 Octobre 2015)

C'est bien ca, le tcpdump sur le serveur avec l'adresse du client et le client à bien l'adresse 192.168.1.106

Pour le traceroute : 
traceroute to 192.168.1.17 (192.168.1.17), 64 hops max, 52 byte packets

 1  * * *

 2  * * *

 3  * *traceroute: sendto: No route to host

traceroute: wrote 192.168.1.17 52 chars, ret=-1

 *

traceroute: sendto: Host is down

Pour le ifconfig (juste l'interface du tunnel) :
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

    net 192.168.1.106 --> 192.168.1.105 netmask 0xffffffff

Routing tables



Internet:

Destination        Gateway            Flags        Refs      Use   Netif Expire

0/1                192.168.1.105           UGSc           63        0   utun0

default            192.168.1.1        UGSc            9        0     en0

192.168.1.1/32        192.168.1.105           UGSc            1        0   utun0

192.168.1.105         192.168.1.106          UHr            90        0   utun0

90.23.146.110/32   192.168.1.1        UGSc            2        0     en0

127                localhost          UCS             1        0     lo0

localhost          localhost          UH              4    32001     lo0

128.0/1            192.168.1.105           UGSc           25        0   utun0

169.254            link#4             UCS             1        0     en0

192.168.1          link#4             UCS             5        0     en0

192.168.1.1        24:95:4:5:82:80    UHLWIir         5      264     en0   1197

192.168.1.17       link#4             UHRLWIi         1      490     en0

192.168.1.45/32    link#4             UCS             2        0     en0

192.168.1.45       60:3:8:96:99:42    UHLWIi          1        1     lo0

192.168.1.74       d0:4f:7e:1c:af:d1  UHLWIi          1      553     en0   1147

192.168.1.255      link#4             UHLWbI          1      693     en0



Internet6:

Destination        Gateway            Flags         Netif Expire

localhost          localhost          UHL             lo0

fe80::%lo0         localhost          UcI             lo0

localhost          link#1             UHLI            lo0

fe80::%en0         link#4             UCI             en0

apple-tv.local     d0:4f:7e:1c:af:d1  UHLWIi          en0

macbook-pro-de-ale 60:3:8:96:99:42    UHLI            lo0

fe80::%awdl0       link#8             UCI           awdl0

macbook-pro-de-ale 22:90:dc:5c:66:b8  UHLI            lo0

ff01::%lo0         localhost          UmCI            lo0

ff01::%en0         link#4             UmCI            en0

ff01::%awdl0       link#8             UmCI          awdl0

ff02::%lo0         localhost          UmCI            lo0

ff02::%en0         link#4             UmCI            en0

ff02::%awdl0       link#8             UmCI          awdl0


En tout cas je te remercie de ta patiente et de ton aide


----------



## Polo35230 (24 Octobre 2015)

Pour moi, si on regarde les tables de routage du client, l'adresse 192.168.1.17 n'est pas routée vers le tunnel.
(192.168.1.17 link#4 UHRLWIi 1 490 en0)
Pour que ça marche, elle ne devrait pas être routée vers en0, mais vers utun0

Curieuse,ta table de routage. Plein de choses.
Il y a dû avoir des routes rajoutées manuellement. Certaines sont redondantes….
Il faudrait mettre à plat la conf réseau du client.
Un ifconfig complet aurait donné plus d'indications sur celle-ci. Quelque chose me dit que l'interface en0 est peut-être aussi sur un plan 192.168.1.0/24

Le traceroute ne donne pas d'indications, si ce n'est que les deux premiers équipements traversés sont configurés pour ne pas répondre, et que le troisième ne peut pas router cette adresse. Ces équipements doivent être sur le Lan du client.


----------



## nibbler77 (20 Mars 2020)

Bonjour,

Nous rencontrons actuellement le même problème avec la même configuration que vous.

Nous avons constaté avec un collègue que le problème se rencontre lorsque les utilisateurs ont une box FAI qui leur distribue la même plage d'adresse IP qu'a l'entreprise. (Pas de problème en partage de connexion 4G avec un téléphone portable)

En solution provisoire, nous avons mis en place un petit script qui doit être exécuté par les utilisateurs après la connexion au réseau VPN pour y ajouter une route.

Cette solution reste assez contraignante pour nos utilisateurs, avez-vous une autre méthode pour résoudre cette problématique ?

Vous en remerciant par avance.

Cordialement
Hervé


----------



## hsengler (10 Décembre 2020)

nibbler77 a dit:


> Bonjour,
> 
> Nous rencontrons actuellement le même problème avec la même configuration que vous.
> 
> ...


Bonjour,
je rencontre le même problème avec un utilisateur Macbook pro... pouvez-vous partager le script que vous avez mis en place?

merci

cdt


----------



## lolipale (12 Décembre 2020)

Bonjour,

Inutile de faire un script
Vous pouvez aussi ajouter une route sur une configuration VPN spécifique avec la commande networksetup.
Exemple :
Pour obtenir la liste des services :

```
networksetup -listallnetworkservices
```
Pour ajouter la route

```
networksetup -setadditionalroutes <networkservice> [ <dest> <mask> <gateway> ]
```
Exemple :

```
networksetup -setadditionalroutes "Mon VPN" 10.10.50.0 255.255.255.0 10.10.50.1
```
Pour vérifer que la route a bien été ajoutée :

```
networksetup -getadditionalroutes "Mon VPN"
```
Pour supprimer la route (ne pas mettre les arguments)

```
networksetup -setaddtionalroutes "MON VPN"
```

A noter qu'il n'est donc plus nécessaire d'envoyer tout le trafic sur la connexion VPN


----------



## hsengler (12 Décembre 2020)

Bonsoir,
merci pour votre réponse, n'étant pas spécialiste Mac, je me doutais bien qu'il y avait un problème de route. Je ne comprend pas pourquoi ce même VPN fonctionnera sans créer de route pour un utilisateur Windows...
En tout cas, je testerai cette solution dès lundi et je vous ferais un retour.
Par contre, contrairement à la personne juste au dessus de ma demande, cela ne fonctionne pas même en connexion 4G.

cdt


----------

