[résolu] Pb avec PPTP (Passerelle par défaut)
-
Il faut vérifier que les paquets en provenance des clients PPTP subissent bien un NAT en sortie par le WAN (réécriture de l'adresse source des paquets avec l'adresse publique WAN). Il faut aller faire un tour dans le menu NAT.
-
Pour l'instant je suis en configuration automatique des règles NAT sortantes.
Ca fonctionne parfaitement pour le LAN et la DMZ mais visiblement pas pour les clients PPTP.
Peut-être faut-il passer en mode manuel.
?? -
J'ai tenté le mode manuel mais rien ne change.
Voici ma config : (dans Firewall: NAT: Outbound)
Bon c'est marqué Auto created rule sur toutes les règles mais c'est parce-que j'ai fais un copier/coller depuis la description de la règle créée automatiquement pour le LAN. -
up!!
Je précise que tout fonctionne correctement maintenant et que pfsense est entré en production depuis hier.
Seulement toujours pas d'accès internet via le VPN (PPTP).
Le système précédent, malgré un grand nombre de dysfonctionnements, permettait cela alors on attend de moi que je puisse aussi le faire sur le nouveau système.
Qu'en dites vous ?? -
Cela doit marcher.
j'ai plusieurs dizaine de configurations ou les personnes surf via PPTP !
Problème DNS ? pas de résolution extérieur ? -
Cela doit marcher.
j'ai plusieurs dizaine de configurations ou les personnes surf via PPTP !
Problème DNS ? pas de résolution extérieur ?+1 ou problème de filtrage?
Maintenant, tu peux décocher l'utilisation de la passerelle et ajouter une route dans ton Windows qui pointe ton LAN via ta connexion PPTP…
Avantage: tes users surfent par leurs propres connexions.
Problème: à chaque déconnexion, tu perds la route:
Solution: Il existe un Admin Kit chez Microsoft qui te permet de créer des connexions PPTP avec des routes incluses. C'est le CMAK.
Problème à la solution: l'Admin kit ne fonctionne que sous Win. -
Merci pour vos idées, la première était la bonne.
J'ai trouvé la solution à ce problème depuis trois jours mais j'ai oublié de poster la réponse.
Alors voilà il s'agissait bel et bien d'un problème de DNS ET de filtrage.
En effet j'avais bêtement imaginé que le relais DNS était fait sur toutes les interfaces du firewall … erreur !
J'avais mal regardé mais l'adresse du DNS principal fournie aux clients par l'interface (virtuelle) PPTP était l'adresse de l'interface LAN du firewall.
Il suffisait donc tout bêtement de créer une règle permettant aux utilisateurs PPTP d'accéder à l'interface LAN du firewall.
ET ça marche !
En fait, je n'ai pas tout à fait fait comme ça car je préfère que les clients Windows accèdent au DNS du contrôleur de domaine mais la solution reste identique.
Ça m'amène à une autre question :
Pour l'instant, je bloque l'accès au DNS principal fourni par le firewall au clients (pour rappel l'adresse de l'interface LAN) tout simplement en ne créant pas la règle et je crée une règle pour accéder au DNS du contrôleur de domaine (qui est le DNS secondaire fourni aux clients PPTP par le firewall).
Ce serveur DNS est le DNS principal configuré dans le firewall.
Problème : cela provoque une latence lors de l'accès internet car il faut attendre le timeout du DNS principal pour accéder au DNS secondaire.
Donc la question : est-il possible de faire en sorte que le serveur PPTP (le firewall) distribue directement l'adresse du DNS du contrôleur de domaine comme DNS primaire au lieu de son adresse LAN ?? -
On fini toujours par trouver !!!
;D
-
Un autre problème se pose. Il est désormais impossible de s'authentifier sur le domaine depuis les postes nomades. (Par exemple avec runas /user:DOMAINE\utilisateur "cmd").
Mon responsable pense que cela est dû au fait que les clients pptp n'aient pas l'adresse du contrôleur de domaine comme serveur DNS principal mais seulement comme secondaire.
J'ai essayer d'éditer le fichier /etc/ppp/ppp.conf et de commenter l'option permettant de récupérer les DNS depuis /etc/resolv.conf mais cela ne fait aucune différence.
DNS principal : IP de l'interface LAN du firewall
DNS secondaire : IP du contrôleur de domaine (DNS principal configuré sur le firewall).
Il faut absolument que je trouve un moyen d'inverser ce comportement.
(Peut-être faut-il que je crée un nouveau topic…) -
Hum,
Vérifier :
DNS (faire un nslookup sur le nom du domaine windows, c'est censer répondre avec l'IP d'un des DC). LE DNS forwarder de la pfsense possède t-il une règle de forward vers le DNS AD ?
Vérifier l'heure entre le client et le serveur
Vérifier les règles de filtrage -
Le nslookup "nom du domaine" renvoi bien l'ip du PDC.
Toutefois c'est normal puisque c'est le PDC lui-même qui résoud.
(je rappelle que j'ai autorisé uniquement les accès DNS vers le PDC afin que les noms locaux soient correctement résolus).Pour le DNS forwarder, voici ma config :
L'heure est identique sur le client et le serveur.
J'ai testé ceci dans /etc/ppp/ppp.conf :
(par défaut l'option enable dns est décommentée)
Ca n'a absolument rien changé, mes clients pptp reçoivent toujours l'ip de l'interface LAN comme DNS principal et l'ip du PDC comme DNS secondaire et WINS.Et les commandes "runas" ne fonctionnent toujours pas.
-
J'ai testé ça aussi :
C'est le paramètre préconisé pour la version 2 ou supérieur de ppp.
(Et oui, le paramètre précédent était celui préconisé pour la version 1)Ça ne marche pas mieux. Je désespère un peu.
-
Correction : les nom de domaine n'est pas résolu avec nslookup.
Le serveur DNS ne donne pas d'adresse.
Il indique : domaine.domaine et pas d'adresse. -
Quand vous dites
je rappelle que j'ai autorisé uniquement les accès DNS vers le PDC afin que les noms locaux soient correctement résolus"
vous parlez des règles de firewall sur la carte PPTP. Si c'est le cas alors il est normal que les authentifications ne fonctionnent pas.
Il faut entre autres activer les requête kerberos UDP/88, DCE TCP/445 NetBios (pas obligé normalement) TCP/137-139. -
Les ports 445/TCP ainsi que les ports netbios sont dores et déjà ouverts.
J'avais omis le port 88/UDP, merci pour l'info.
Je suis resté sur cette piste et ai loggué les paquets bloqués par la règle par défaut.
Ca a été trés enrichissant et j'ai découvert plusieurs ports nécessaires.
389(UDP) (LDAP) (active directory)
135(TCP/UDP) DCE endpoint resolution (procédure d'appel RPC)
mais surtout :
1026(TCP) : nterm : Remote Login Network Terminal
Tout fonctionne maintenant.Mon responsable avait planné, rien à voir avec le DNS.
Merci à tous et surtout .. merci pfSense !!