Mavericks Server et partage WIFI

[riete]

bonjour,

je suis en train de devenir chèvre avec des questions qui restent sans réponse, votre aide sera bienvenue. Peut être que ce sujet est un sujet réseau, mais comme le Mac est équipé d'un Mavericks et l'application Server et que les choses sont différentes d'avec une version standard, j'ai posté ici.

L'objectif est de pouvoir accéder à Internet depuis des clients WIFI par le biais du partage WIFI du Mac.

Tous se passe sur des classes C.
J'ai un nouveau Mac Pro connecté à un LAN 192.168.10.2, un FW pfsense à l'IP 192.168.10.251, qui est le routeur par défaut du Mac.
J'ai activé le WIFI sur le Mac, créé un réseau et attribué l'adresse IP 192.168.13.1 à l'interface WIFI.
J'ai lancé le services DHCP qui attribue sans problème des IP et aux périph se connectant en WIFI. Le routeur attribué au client WIFI par le DHCP est 192.168.13.1 (l'IP de l'interface WIFI du Mac).
J'ai bien activé l'IP forwarding sur le Mac qu partage son WIFI.

J'ai ajouté une route static sur le pfSense vers 192.168.13.0 en passant par 192.168.10.2

J'accède bien à toutes les machines du Lan 192.168.10 qui ont la route vers le LAN depuis les client WIFI.

Le truc dingue, c'est que le pfSense ping bien une machine du style 192.168.13.4, mais le client lui, ne peut pas le pinger.

Merci de votre aide.

PS: je précise à toutes fins utiles que j'ai essayé d'utilisé le partage de connexion internet dans le panneau de conf, cela ne fonctionne absolument pas.

[fmereo]

Truc bête mais ton routeur PfSense n'est pas en mode furtif ? ça expliquerait sa non-réponse aux demandes de ping…

[riete]

Je ne sais pas ou est le mode furtif. Mais il ne dois pas y être puisqu'il réponds aux pings d'autres machines.

[fmereo]

Effectivement…

Et tu as essayé de désactiver le mode routeur pour voir ?

[riete]

Et tu as essayé de désactiver le mode routeur pour voir ?

Je ne sais pas ce qu'est le mode routeur. En plus il faut bien entrer dans le PfSense une route statique vers le réseau WIFI sinon il va envoyé les paquets vers l'extérieur puisque c'est la route par défaut.

Par contre ce que j'ai réussit à faire qui me dépanne mais qui ne me convient pas est la chose suivante: j'ai affecté un morceau de la classe C de mon LAN au mini réseau WIFI raccordé à mon Mac. C'est un réseau de 6 machines max avec un masque 255.255.255.248. J'ai affecté la route statique correspondante sur le PfSense et tout à l'air de fonctionner, j'accède à internet sans problème.

J'aimerais bien comprendre pourquoi quand je fais la même chose en affectant une nouvelle classe C au réseau WIFI, cela ne fonctionne plus. Il s'agit probablement d'un problème de configuration du FW, mais je ne sais pas ou regarder.

Merci quand même, bonne journée.

[roseau]

et pourquoi pas un bon routeur mixte filaire wifi?, ce serait certainement plus facile au moins les Vlan sont correctement configurés
Le réseaux ce n'est pas mon métier et je me suis arraché les cheveux avec deux routeurs filaire en cascade il y a quand même pas mal de choses à ne pas rater pour que ça fonctionne!!

Ce message a été modifié par roseau - 11 Dec 2014, 12:04.

[riete]

et pourquoi pas un bon routeur mixte filaire wifi?, ce serait certainement plus facile au moins les Vlan sont correctement configuré
Le réseaux ce n'est pas mon métier et je me suis arraché les cheveux avec deux routeurs filaire en cascade il y a quand même pas mal de chose à ne pas rater pour que ça fonctionne!!

Oui, en effet ta question est bien posée. Mais si je fais chi*%@# à faire cela c'est pour éviter plusieurs choses.

D'abord, j'ai déjà un router WIFI sur le site, mais il est coupé pour des raisons de sécurité. J'ai juste des besoins ponctuels de WIFI. Je voudrais juste pouvoir, activer le partage WIFI sur mon Mac quand je dois configurer un IPhone ou un Ipad Neuf pour un utilisateur.

Ma question est aussi liée à mon envie de comprendre comment résoudre ces questions si un jour je suis amené à devoir travailler sur un tel projet. Ce qui me semble tout à fait possible.

La seule question qui subsiste pour moi maintenant, c'est :

Pourquoi cela fonctionne t il bien avec subnet de mon LAN principale et pas avec une classe C indépendante sur mon réseau WIFI. Je pense encore une fois que c'est le NAT qui pose problème.

[fmereo]

Effectivement…

Et tu as essayé de désactiver le mode routeur pour voir ?

Je voulais dire "couper le firewall", désolé…

[trouspinette]

bonjour,

je suis en train de devenir chèvre avec des questions qui restent sans réponse, votre aide sera bienvenue. Peut être que ce sujet est un sujet réseau, mais comme le Mac est équipé d'un Mavericks et l'application Server et que les choses sont différentes d'avec une version standard, j'ai posté ici.

L'objectif est de pouvoir accéder à Internet depuis des clients WIFI par le biais du partage WIFI du Mac.

Tous se passe sur des classes C.
J'ai un nouveau Mac Pro connecté à un LAN 192.168.10.2, un FW pfsense à l'IP 192.168.10.251, qui est le routeur par défaut du Mac.
J'ai activé le WIFI sur le Mac, créé un réseau et attribué l'adresse IP 192.168.13.1 à l'interface WIFI.
J'ai lancé le services DHCP qui attribue sans problème des IP et aux périph se connectant en WIFI. Le routeur attribué au client WIFI par le DHCP est 192.168.13.1 (l'IP de l'interface WIFI du Mac).
J'ai bien activé l'IP forwarding sur le Mac qu partage son WIFI.

J'ai ajouté une route static sur le pfSense vers 192.168.13.0 en passant par 192.168.10.2

J'accède bien à toutes les machines du Lan 192.168.10 qui ont la route vers le LAN depuis les client WIFI.

Le truc dingue, c'est que le pfSense ping bien une machine du style 192.168.13.4, mais le client lui, ne peut pas le pinger.

Merci de votre aide.

PS: je précise à toutes fins utiles que j'ai essayé d'utilisé le partage de connexion internet dans le panneau de conf, cela ne fonctionne absolument pas.

STP, fais nous un schéma, avec les IP de chaque réseau, les gateways, etc...

Ensuite, tu observes les logs du firewall avec un filtre sur une des IP du réseau Wifi => tu regardes si tu as des entrées.

Pour moi, tes paquets du réseau Wifi vers le LAN ne doivent pas passer par le firewall pfSense : c'est ton Mac qui doit agir comme routeur entre les réseaux Wifi et LAN. Effectue des traceroute pour voir quel chemin les machines du réseau Wifi empruntent.

[riete]

STP, fais nous un schéma, avec les IP de chaque réseau, les gateways, etc...

Ensuite, tu observes les logs du firewall avec un filtre sur une des IP du réseau Wifi => tu regardes si tu as des entrées.

Pour moi, tes paquets du réseau Wifi vers le LAN ne doivent pas passer par le firewall pfSense : c'est ton Mac qui doit agir comme routeur entre les réseaux Wifi et LAN. Effectue des traceroute pour voir quel chemin les machines du réseau Wifi empruntent.

Dès que j'ai un moment, je fais un schéma.
C'est bien le cas, mon Mac fait bien le routage entre le LAN et le WIFI. Par contre les clients du WIFI n'arrive pas à aller sur Internet.

Enfin... je vais essayer de faire le clair dans tous cela et je reviens cers vous. Merci en tous cas.

[Polo35230]

Difficile de faire un diag…

Il faudrait dans le Mac Pro faire un ifconfig et un netstat -r (pour voir les interfaces et les routes).

Ensuite, comme l'a dit Trouspinette, il faudrait regarder dans les logs de PFSENSE et faire des traceroute (par exemple vers 8.8.8.8 à partir d'une machine en 192.168.13.x). On verra alors quelle est la machine qui ne peut pas assurer le retour du ping (icmp reponse)

Par contre ce que j'ai réussit à faire qui me dépanne mais qui ne me convient pas est la chose suivante: j'ai affecté un morceau de la classe C de mon LAN au mini réseau WIFI raccordé à mon Mac. C'est un réseau de 6 machines max avec un masque 255.255.255.248. J'ai affecté la route statique correspondante sur le PfSense et tout à l'air de fonctionner, j'accède à internet sans problème.

J'aimerais bien comprendre pourquoi quand je fais la même chose en affectant une nouvelle classe C au réseau WIFI, cela ne fonctionne plus. Il s'agit probablement d'un problème de configuration du FW, mais je ne sais pas ou regarder.

Je ne sais pas si j'ai bien compris, mais si le Mac Pro est en mode ROUTEUR et que le plan IP de ton réseau local ressemble à ça:
PFSENSE———192.168.10.0/24———Eth_MacPro_WiFi——— 192.168.10.248/29— Machines en wifi
Normal que ça marche, car le réseau 192.168.10.248/29 est inclus dans le 192.168.10.0/24.
PFSENSE voit donc les machines en wifi en 192.168.10.249 à 254) comme des machines étant sur sa propre interface Lan.

Maintenant, avec deux plans IP parfaitement segmentés, et le Mac Pro en mode routeur
PFSENSE———192.168.10.0/24———Eth_MacPro_WiFi——— 192.168.13.0/24— Machines en wifi
PFSENSE voit les machines wifi arriver sur son interface Lan en 192.168.13.xxx, un plan IP différent de son interface.
Pour moi, PFSENSE doit prendre ça comme une attaque. D'où le PB.

Perso, j'essaierais d'élargir à 16 le masque de l'interface Lan de PFSENSE pour prendre en compte le plan IP wifi
PFSENSE———192.168.0.0/16———Eth_MacPro_WiFi——— 192.168.13.0/24— Machines en wifi
Le réseau 192.168.13.0/24 sera donc inclus dans le réseau 192.168.0.0, et ça devrait marcher.
Maintenant, la solution n'est pas belle. Internet marchera, mais en local, , il y aura des pbs entre les machines du réseau local situées sur les deux plans privés différents. Un seul sens de connexion marchera…

Il y a quelque chose que je ne comprends pas…
Pourquoi ne fais tu pas un simple partage de la connexion depuis ethernet aux ordinateurs via wifi sans te préocuper du plan IP. Le Mac Pro deviendra alors serveur DHCP et distribuera des adresses (côté wifi) sur un plan privé en 10 (je crois).
En mode partage, le Mac Pro fera aussi automatiquement de la NAT/PAT (en translatant les adresses IP wifi en une adresse IP unique (192.168.10.2; c'est son interface Lan)).
Pour PFSENSE, il n'y aura pas de pbs…

Un autre truc qui pourrait aussi marcher avec le Mac Pro en mode routeur, c'est de déclarer (si c'est possible) dans PFSENSE deux réseaux IP sur sur la même interface Lan (192.168.10.0/24 et 192.168.13.0/24)

Enfin bon, je n'ai peut-être pas bien compris…
Ce sont des idées en vrac.

Ce message a été modifié par Polo35230 - 12 Dec 2014, 16:09.

[riete]

@ Polo35230 et @trouspinette

J'ai trouvé un moment pour faire des tests et regarder vos suggestions.

Voici le plan du réseau et le résultat du netstat -r

Je précise que je n'ai pas oublié d'activé l'ipforwarding, j'ai bien mis les routes 192.168.13.0 par 192.168.10.2 sur les machine MacPro2, ns0 qui est le DNS et sur le PfSense.

Les pings depuis le client WIFI vers les machines du LAN qui ont la route fonctionnent bien. Par contre on ne peut pas pinger le PfSense.
Le PfSense lui ping bien le client WIFI.
Le traceroute depuis le client WIFI block à partir de l'interface WIFI de MacPro 192.168.13.1

Je suis perplexe et écoute vos suggestions.

Merci

Ce message a été modifié par riete - 17 Dec 2014, 17:49.

Fichier(s) joint(s)

 Map_WIFI.jpg ( 27.27 Ko ) Nombre de téléchargements : 9
 netstat.jpg ( 90.48 Ko ) Nombre de téléchargements : 8

 

[Polo35230]

Pour le netstat -r, on voit, par rapport à ton plan qu'il y a aussi un autre sous réseau (192.168.12.0/24); mais bon, c'est pas gênant.
Un truc curieux aussi, c'est que tu as deux routes par défaut:
La première vers PFSENSE (en0), et l'autre côté wifi (en2). Mais là aussi, ça n'est pas gênant, car c'est la première route qui sera prise en compte si elle est opérationnelle.

Par contre, ça, c'est important:

Le traceroute depuis le client WIFI block à partir de l'interface WIFI de MacPro 192.168.13.1

Tu veux dire que sur la première ligne du traceroute, tu vois l'adresse 192.168.13. 1et qu'après tu as des "* * * *" ?
Parce que si c'est le cas, le Mac Pro PEUT assurer le retour et le pb n'est pas chez lui.
L'icmp echo doit donc le traverser.
C'est donc au deuxième saut que ça coince (tu devrais avoir 192.168.10.251 comme saut suivant), c'est à dire que PFSENSE ne peut pas assurer le retour.

J'en reviens à mon hypothèse du post #11 comme quoi PFSENSE prend ça pour une attaque.
Essaye de passer l'interface Lan de PFSENSE à 192.168.0.0/16 pour voir si ça marche.

[riete]

Hello Polo,
Le réseau 192.168.12.0/24 est en effet un LAN qui se trouve sur un autre site via une VPN/SDSL. Il faut donc que l'on ai la route pour le trouver et surtout que les packets venant de ce réseau puissent retrouver le chemin de retour .

Par contre l'histoire des deux routes par défaut dont tu parles je ne comprends pas trop. Le netstat a été réalisé sur le Mac qui "partage" son interface WIFI. en0 est l'interface Ethernet est la en2 l'interface Wifi, je ne comprends pas pourquoi cela pourrait poser un problème (je ne suis pas ingé réseau). en2 est la route par défaut pour le LAN 192.168.13.0, c'est ça? enfin de mon point de vue.

Tu veux dire que sur la première ligne du traceroute, tu vois l'adresse 192.168.13. 1et qu'après tu as des "* * * *" ?

Oui tout à fait, c'est ça.
J'ai bien compris que le prochain hop devrait être le PfSense 192.168.10.251, mais justement pourquoi ne l'est il pas? je n'en sais rien. Alors que lui même arrive à pinger une machine sur le LAN/WIFI 192.168.13.0. C'est THE mystère.

Essaye de passer l'interface Lan de PFSENSE à 192.168.0.0/16 pour voir si ça marche.

Je ne vois rien passé au niveau du FW concernant le LAN 192.168.13.0 et je ne comprends pas ce que tu veux dire par passer l'interface 192.168.0.0/16. Tu veux dire que je devrais autoriser la class B du "niveau au dessus" (excuse moi pour la terminologie)?. Ou es ce que je fais cela dans l'interface du PfSense?
Merci pour tes tuyaux en tous cas.

Ce message a été modifié par riete - 18 Dec 2014, 08:46.

[Polo35230]

Par contre l'histoire des deux routes par défaut dont tu parles je ne comprends pas trop. Le netstat a été réalisé sur le Mac qui "partage" son interface WIFI. en0 est l'interface Ethernet est la en2 l'interface Wifi, je ne comprends pas pourquoi cela pourrait poser un problème (je ne suis pas ingé réseau). en2 est la route par défaut pour le LAN 192.168.13.0, c'est ça? enfin de mon point de vue.

Non, pour moi, ça marche pas comme ça.
Pour un routeur, quand un paquet entre par une interface, il regarde l'adresse IP destination du paquet.
Si l'adresse destination est dans le plan IP d'une de de ses interfaces, il l'enverra sur l'interface correspondante. C'est du routage par interface.
Si l'adresse destination n'est pas dans le plan IP d'une des interfaces, il consulte sa table de routage. Si l'adresse n'est pas routable par une route explicite, alors, il prendra la route par défaut. Dans ton cas, la première de la liste.

Par exemple, si une machine sur ton réseau wifi pingue une adresse sur le web (8.8.8.8), leMac Pro doit l'envoyer sur PFSENSE via la route par défaut.
Comme ça ne marche pas, on peut faire des traces pour savoir avec certitude si le pb vient du Mac ou de PFSENSE.

Dans le Mac Pro, il faudrait ouvrir deux fenêtres Terminal (pour tracer sur les interfaces eth et wifi)
Dans la première, faire:
tcpdump -i en2 host 8.8.8.8
Dans la deuxième:
tcpdump -i en0 host 8.8.8.8

Puis sur une machine en wifi du réseau 192.168.13.0, faire un ping 8.8.8.8
On saura alors si le pb est au niveau de PFSENSE ou du Mac Pro


L'idée de passer le masque de l'interface Lan de PFSENSE à 16, c'était pour élargir le masque (oublie les classes...) afin que les adresses en 192.168.13.xxx soient dans le même plan que cette interface.
Mais bon, en fonction de ce qu'on verra avec les traces, on reviendra (ou pas) sur cette solution.

Ce message a été modifié par Polo35230 - 18 Dec 2014, 12:10.

[riete]

Je crois que je me suis mal exprimé, mais en ce qui concerne la route par défaut, j'avais bien compris les choses de la façon dont tu les explique. Ma route par défaut pour toutes adresse est 192.168.10.251 (le PfSense) sauf pour les LANs 192.168.13.0, 192.168.10.0 et 192.168.12.0.

Le coup de faire un tcpdump sur chaque interface est une très bonne idée. Je vais essayé quand j'ai un moment. Probablement demain.

@+

[riete]

Je viens de faire les test de tcpdump sur le Mac. Les packets passent bien de en2 vers en0.

Code

tcpdump -i en02 host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en02, link-type EN10MB (Ethernet), capture size 65535 bytes
11:05:55.353992 IP 192.168.13.4 > google-public-dns-a.google.com: ICMP echo request, id 47872, seq 0, length 64
11:05:55.425687 IP 192.168.13.4 > google-public-dns-a.google.com: ICMP echo request, id 47872, seq 1, length 64

Code

tcpdump -i en2 host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:05:55.353993 IP 192.168.13.4 > google-public-dns-a.google.com: ICMP echo request, id 47872, seq 0, length 64
11:05:55.425687 IP 192.168.13.4 > google-public-dns-a.google.com: ICMP echo request, id 47872, seq 1, length 64

Par contre si je fais la même chose au niveau du PfSense, ça ne fonctionne pas comme il faudrait. On voit bien les packets arriver sur l'interface LAN mais sur le WAN rien.
J'ai donc changer le mask de l'interface LAN en vr0/16 comme tu me l'as conseillé, mais rien ne change. J'ai même essayé de faire la même chose sur l'interface vr1/WAN mais dans ce cas, je n'ai même plus accès à internet avec les machines du LAN. Donc mauvaise idée de faire cela.

As tu d'autres solution à explorer. Peut être au niveau des paramétrage du FW PfSense?

[Polo35230]

Curieuse ta commande tcpdump -i en02 host 8.8.8.8 (en02 au lieu de en0 ...).
Du coup, on ne sait pas si tcpdump a pris sur en0 ou en2.
Ça doit être en0, car sur l'interface Lan, tu vois bien arriver les paquets icmp echo request.

Bon, ce qu'on sait, c'est que l'icmp echo request traverse bien (à l'aller)le Mac Pro, mais que PFSNSE le bloque…
Tu as fait l'essai en élargissant le masque, et ça n'a rien fait.
Donc, c'est soit PFSENSE qui bloque l'icmp (comme l'a dit fmereo plus haut), soit quelque chose dans les règles.
Je connais mal PFSENSE, et je n'en ai pas sous la main, mais de mémoire, il crée des règles automatiquement en fonction des adresses (et masques) de ses interfaces pour passer du LAN vers le WAN.
Regarde dans la section Nat, je crois…

Dans ton cas, il a donc dû créer automatiquement une règle liée à l'interface wan:
source 192.168.10.0/24 vers destination any
Mais, n'ayant pas d'interface en 192.168.13.0/24, il bloque ce réseau.
Tu pourrais essayer de créer une nouvelle règle:
source 192.168.13.0/24 vers destination any, pour voir si ça change quelque chose.

Ce message a été modifié par Polo35230 - 19 Dec 2014, 17:13.

[riete]

Dans ton cas, il a donc dû créer automatiquement une règle liée à l'interface wan:
source 192.168.10.0/24 vers destination any
Mais, n'ayant pas d'interface en 192.168.13.0/24, il bloque ce réseau.
Tu pourrais essayer de créer une nouvelle règle:
source 192.168.13.0/24 vers destination any, pour voir si ça change quelque chose.

J'avais déjà ajouter une règle de NAT Outbound pour le LAN 192.168.13.0/24 sur le PfSense. Mais cela n'apporte pas d'amélioration. Voici la copie d'écran de la règle.

Ce message a été modifié par riete - 23 Dec 2014, 08:49.

Fichier(s) joint(s)

 Capture_d_____cran_2014_12_23____08.52.43.png ( 97.49 Ko ) Nombre de téléchargements : 5

 

[Polo35230]

Pour moi, la règle est bonne.
Elle apparait bien dans la section Nat?
Elle a exactement la même allure que pour la source 192.168.10.0/24?
Dans les interfaces Lan et wan de PFSENSE, les cases pour bloquer les réseaux privés ne doivent pas êtres cochées.
On pourrait aussi valider le log toutes les règles du firewall et refaire un essai. On doit trouver la trace du rejet.
Pour que ça marche, il faudrait avoir:
Côté lan: source192.168.13.xxx dest: 8.8.8.8 et en sortie, après avoir été naté, côté wan wan: source 192.168.11.251 dest 8.8.8.8

Pas simple...

[riete]

Merci Polo,

je te souhaite de bonnes fêtes en tous cas. Je vais essayer tous cela à mon retour.
J'ai du repartir sur une version antérieur de la config de mon PfSense car à force de bidouiller (c'est normal sur un site comme celui-ci ;-) ), j'ai finit par planter les règles du FW et je ne trouvais plus ou. En repartant propre après Noël, je pense que ce sera plus facile.

Thierry

[trouspinette]

A la vue de ton schéma, tu ne dois avoir qu'une seule règle de NAT sur pfSense :

LAN => WAN

Je vais essayer de me coller dans une config identique à la tienne :

- en0 sur le Mac, 192.168.1.0/24
- en1 (Wifi), 192.168.13.0/24
- Partage de la connexion Wifi
- pfSense comme Default Gateway du LAN 192.168.1.0/24

Je n'ai pas de pfSense en box solo, mais dans une VM : ça fait la même chose

Sur ton pfSense, fais une regle de firewall "From LAN to ANY et ANY Protocol = Allow". Mets là en top list et actives le log de cette règle, si tu bloques un paquet pour une raison ou une autre, tu le verras dans le log du filtrage des paquets.

Ciao