Dérogations spécifiques aux clients - définissez un réseau de tunnels pour chaque client. Le client sera toujours à cette adresse

Ne pas faire NAT, salissante. Définir des itinéraires. Le pfSense sait déjà comment rouler entre 10.30.0 et 10.30.1, mais probablement le client ne sait pas comment obtenir (ou répondre) à 10.30.1, seulement 10.30.0

Ajoutez 10.30.1.0/24 aux réseaux locaux VPN / OpenVPN / Servers / Edit / IPv4, de sorte que l'itinéraire est transféré au client.

Client specific overrides - set a Tunnel Network for each client.  Client will then always be at that address

Don't do NAT, messy.  Set routes. The pfSense will already know how to route between 10.30.0 and 10.30.1, but probably the client doesn't know how to get (or reply) to 10.30.1, only 10.30.0

Add 10.30.1.0/24 to VPN / OpenVPN / Servers / Edit / IPv4 local networks, so the route gets pushed to the client.

Il y a un truc pas clair: j'ai regardé rapidement les règles que tu avais posté et il me semblait qu'il y avait déjà une règle pour le port 389. Qu'as-tu donc ajouté ?

Au passage, 389, c'est du LDAP en clair, donc le mot de passe en base64, c'est à dire en clair aussi (ou presque). LDAPS en 636, c'est mieux  ;)

Bonjour ,

Effectivement cela fonctionne mais je suis obligé de rentrer l'adresse de mon proxy dans les paramètres de mon navigateur pour pouvoir accéder à l'interface WEB , il n'y a t'il pas un moyen pour éviter cette manip et juste accéder à l'interface en tapent l'adresse et le port en étant en transparent ?

Ok solution partiellement trouvée, le problème vient de chrome et non de ntopng. Je poursuit mes recherches.

Merci quand meme

oui et très facile à trouver si vous aviez seulement regarder avec un tant soit peut d'attention les options proposer dans l'interface.

Et, heu … , c'est aussi écris dans la doc.

J'avoue ne pas comprendre cette histoire de "DNS par gateway":

tu définis les DNS publiques au niveau des "general settings" ils faut bien sûr que ces DNS soient joignables par chaque gateway je n'utilise plus "DNS forwarder" depuis longtemps mais dans resolver, tu définis les interfaces sur lesquelles ton DNS server écoute et les interfaces qu'il utilise pour faire les requêtes. Par défaut, il va utiliser localhost qui va s'appuyer sur les settings du "general settings"

Merci pour votre réponse.

Je ne souhaite pas faire plusieurs serveurs vpn car un utilisateur peut avoir besoin de différentes ressources.

Je vais creuser la partie client specific overrides, je ne connais pas du tout.

Comment vous y prenez vous ?
Avec Pfsense 2.3.2-p1. Une fois votre autorité de certification créée, elle apparait dans la page System / Certificate Manager / CAs / Edit
La bouton Add permet d'en créer autant de nouvelles que souhaité.

j'ai bien évidemment passé du temps a rechecker toute la conf de nombreuses fois et souhaite creuser en ayant plus d'élements pour identifier l'origine.
il n'y a pas de rupture de lien ..

je demande juste ou je peux trouver des traces plus détaillées que cette simple erreur.

Changer le plan d’adressage est de loin la meilleure solution. Vous réglerez une fois pour toute une source de problèmes récurrents. Je le redis, évitez les réseaux 192.168.0.0 et 192.168.1.0 (idem avec 10.0.0.0). Prenez ce qui vous parle mais en dehors des réseaux courants. Si 192.168.164.0/24 vous plait, alors en voiture ! Vous pouvez même le jouer aux dés.

En sus du fil, très justement rappelé par Baalserv, il est NECESSAIRE de comprendre que la virtualisation complique la perception, y compris pour ceux qui sont expérimentés !

A minima, à vérifier et indiquer :

adressages complets : chaque matériel doit avoir adresse ip, masque, passerelle, serveur dns test des 3 pings : ping @ip passerelle + ping 8.8.8.8 + ping g.fr

ok j'attends votre Tuto dans ce cas car de mon coté j'ai toujours pas d'adresse Ip sur mon interface Wan.

La réponse est oui, mais peut être pas de la façon dont vous l'entendez.
Un vlan, basiquement, correspond à un domaine de broadcast de niveau 2. Depuis cette définition les constructeurs n'ont pas manqué d'imagination autour des vlans.
En ce qui concerne Pfsense, je suppose que votre configuration définie des vlans possédant chacun leur numéro de réseau. Si tel est le cas il sera très simple dans l'interface de Pfsense (Firewall -> Rules- -> openvpn) d'indiquer avec quel numéro de réseau les utilisateurs connectés en vpn peuvent communiquer (pensez aussi à l'option push route). Le passage du vpn au réseau souhaité se faisant par une opération de routage, il n'y pas de vlan continu depuis le client vpn jusqu'à la destination finale.

Je me permets d'apporter une petite précision, lorsque les vlans n'étaient pas créés, nous n'avions aucun problème. Dès que nous avons ajouté le fichier XML contenant toute la configuration pour les 100 Vlans, c'est là que nous avons eu des ralentissements.

Si jamais vous auriez une idée.

Du coup je fais quoi ?  :-\

Noter les guillemets ajoutés à proxyfiable.
De façon générale une solution de type SSO sera préférable en effet. Nous en sommes d'accord.

Le mauvais adressage client ne pose pas de difficulté pour Pfsense. Pour le reste c'est une autre histoire.
S'agissant des vlans c'est possible sur l'interface re2. Celle ci n'aura pas d'adresse ip mais comportera deux vlans chacun dans leur réseau.

Probleme resolu un souci au niveau du Vlan ID ça je ne comprend pas mais c etait ça la cause de mon probleme  :)

@chris4916:

D'une manière générale, ce n'est pas une très bonne idée d'utiliser pfSense comme point d'accès wifi…

je sais :) c'est pour tests, cependant j'ai mis l'interface urtw0 (l'interface wifi) en tant que point accès, mais quand je vérifie le status de cette interface, il est en down :/

Salut RedQuarck,
as-tu réussi à installer un PFSense sur le public cloud d'OVH ?

J'ai réussi en suivant cette procédure.  Cependant, la VM est super slow et je n'ai pas trouvé le problème après plusieurs heures de recherche.

https://murf.se/freebs/