il y a un bug avec les interfaces ppp sur un vlan suite au changement de nommage des vlans sur FreeBSD 11

correctif attendu pour la version 2.4.2

Oui je suis d'accord le service n'est pas rendu et il n'est certainement pas inutile de regarder les logs (est-ce jamais inutile 😉)  mais je suis à peu près certain qu'avec ce type de dysfonctionnement, le log de Squid dans pfSense ne va pas être très bavard.

Je persiste mais il serait certainement plus efficace pour la personne qui a choisi ce type de design, d'aller exposer son problème (avec plus d'inputs également car là il n'y a vraiment pas grand chose) dans la section anglaise.

Contrairement à ce que pense jdh, dans la section anglaise, il trouvera des interlocuteurs qui s'intéresseront probablement au problème au lieu de considérer systématiquement que:
1 - ce n'est pas la solution state-of-the-art donc n'en discutons pas sauf pour signaler qu'il ne faut pas le faire
2 - c'est un package donc ce n'est pas bien donc n'en parlons pas

Pour ceux qui sont convaincus qu'il faut systématiquement bannir le proxy de pfSense, la démarche la plus constructive et efficace serait à mon sens d'aller discuter ce sujet justement dans la section anglaise pour convaincre le board pfsense que cette solution n'est pas bonne. Car, oui c'est un package mais n'oublions quand même pas que celui ci fait partie des packages "approuvés". Le bon moyen de le voir disparaître, c'est de travailler au niveau de cette approbation. AMHA

Bien que n'utilisans jamais chez mes clients de sréseaux tel que 192.168.0.0/024, 1.0/24, 10.0.0.0 qui sont très souvent utilisés et qui pose le problème que vous décrivez. Malgré ces précautions il m'arriver de trover utilisé entre mon client et un des ses clients à lui un numéro de réseau commun alors qu'il fallait monter un canal vpn. Il s'ageissait d'un lien UpSec entre Pfsense et un Cisco ASA. J'ai pu résoudre le problème en natant le trafic avant d'emprunter le tunnel vpn.  De cette façon mon numéro de réseau, vu depuis la destination, était différent. C'est ce que vous propose votre client. C'est donc possible avec Pfsense.

Je te confirme que cela ne fonctionne pas (j'ai plusieurs cluster en 10G sur IX) et je te confirme aussi que les limiters sont à proscrire dans un cluster CARP/pfSync.

@ccnet:

Mon "point de vue" est celui e l'internaute qui accède au serveur depuis l'extérieur.

Ah en effet. Mais dans ce cas, je ne pense pas que le code erreur soit lié à un problème de certificat (et de hand-check) entre le client (l’utilisateur internaute) et le serveur (le reverse proxy)

La mise en œuvre de HTTPS au niveau de HAproxy demande de bien comprendre la notion de "passthrough" et de "SSL termination" ("bridging" ou "re-encryption" dans le vocabulaire HAproxy)
La doc de HAproxy consacre une section complète à décrire les différents modes.

Deux généralités tant je ne sais par ou commencer dans ce plat de spaghettis.
1. Si une configuration Pfsense + reverse fonctionne alors rien à toucher sur Pfsense. Celui ci est ouvert sur wan pour Tcp 80 etg 443: règle de filtrage. Puis translation vers le reverse qui fait l'aiguillage selon l'URL de base vers le serveur web de destination.
2. Une architecture rationnelle et plus sûre serait en effet Pfsense avec la configuration wan déjà décrite. Une troisième interface pour une dmz dans laquelle se trouve le reverse HAproxy ou autre (Kemp Free Loadmaster est très bien). Les serveurs web sont dans lan. Ceux ci n'acceptant de connexion que venant de la dmz. Les règles de filtrage sont dans Pfsense. Le reverse fait l'aiguillage selon l'URL de base demandée.
Que vous ayez un, deux ou trente domaines ne change strictement rien.

Faites simple, maintanable et en prime sûr. Vous pourrez centraliser la gestion de nombreux paramètres sur le reverse.

Je ne comprend pas ce que vous essayez de faire avec vos règles notamment 443 en port source.
Et le précédente qui ouvre tout, ou presque !

@jdh:

si il y a renvoi vers un autre serveur web, il faut être capable de 'revenir' vers pfsense pour que l''interrupteur' s'ouvre.

C'est justement mon 1er problème. J'ignore vers quelle adresse rediriger l'utilisateur après le serveur web.

@jdh:

confier des choses complexes comme envoyer un SMS, remplir des champs d'une table de Radius, à un serveur web sous Windows, parait étrange.

Je suis en phase de test et je dois tout virtualiser. De plus, mon PC fonctionne normalement sous Windows. Lorsque je crée une machine virtuelle fonctionnant sous Ubuntu, je rame.
Mais jusqu'à présent, mon serveur web remplit chacune de ses tâches sans aucun problème.

@jdh:

Un tel projet suppose

d'avoir une vue d'ensemble du processus (global) et une vue détaillée de chaque mécanisme, de découper en étapes suffisamment simples, solides et fiables.

En fait, j'ai déjà une idée précise de ce que seront les étapes une fois le projet terminé:

lorsque l'utilisateur se connecte au point d'accès connecté à l'interface LAN de pfSense et essaie d'accéder à une page, il est renvoyé vers le portail captif; ce dernier le renvoie vers le serveur web; celui-ci effectue toutes les tâches que j'ai déjà décrites; il le redirige vers le portail captif avec un formulaire caché contenant son nom d'utilisateur et son mot de passe; ces infos sont attribuées aux variables $_POST['auth_user'] et $_POST['auth_pass'] de la page web du portail captif; puis, le formulaire sur la page web du portail captif est automatiquement envoyé; enfin, les infos ayant été entrées dans la base de données par le serveur web, l'utilisateur devrait se connecter.

Premièrement, je bute au niveau de la redirection du serveur web vers le portail captif.
Ensuite, radiusd s'arrête tout le temps dans Status / Services.
Enfin, l'erreur affichée par le portail captif lorsque j'essaie un utilisateur enregistré dans radcheck pour FreeRadius : Error sending request: No valid RADIUS responses received

Cordialement,
Twenty21

En fait, la recherche sur le forum devrait toujours être un préalable.

Pour peu qu'un problème soit bien défini … et que les mécanismes, ainsi que leur conséquences, soient bien compris (voire précisés par un intervenant).

En l'espèce, quand on va sur Google, on ne s'aperçoit pas, instantanément, que l'on passe en HTTPS, ... donc le portail ne peut pas fonctionner !
Comme la tendance est aux sites HTTPS, il va être difficile de faire fonctionner des portails captifs ...

Il est toujours utile de bien comprendre un mécanisme (un portail capif), c'est à dire comment il fonctionne.
Et il est aussi essentiel de connaitre les conséquences sous-jacentes ...

Ce forum n'est pas là pour détecter, éradiquer les virus, ni pour faire la pub de son site … Point

Il y a des problèmes de compréhension.

Un portail captif est un 'interrupteur' entre WIFI et WAN :

avant identification, il n'y a aucun accès entre WIFI et WAN l'identification (=ouverture de l'interrupteur) se fait par le premier accès HTTP détourné vers la page d'authentification.

Donc, bien sûr,

un, le dns d'un client NE PEUT-ETRE côté WAN deux, l'ouverture ne PEUT PAS se faire par détournement d'une session HTTPS
Il est important de comprendre pourquoi ces 2 conséquences surviennent …

Il y a en effet au moins deux risques techniques à ne pas contrôler le trafic dns.
1 Le déni de service par amplification de trafic exploite le fait que les réponses dns sont d'une taille nettement supérieures aux requêtes.
2. Dns peut être utilisé pour acheminer un trafic qui ne devrait pas l'être. Citons dns2tcp http://www.hsc.fr/ressources/outils/dns2tcp/ et tous les outils qui permettent d'utiliser UDP DNS pour établir des connexions vpn. Par exemple :
https://www.splitbrain.org/blog/2008-11/02-dns_tunneling_made_simple

Il est donc tout à fait nécessaire de ne pas laisser sans contrôle le trafic entrant comme sortant qui utilise UDP 53 ne se faisant passer pour du trafic dns légitime.

@ ccnet :
J'ai une carte mere superMicro avec 2 port ethernet.
mais le Pfsense tourne sur une VM qui est hebergé par une esxi
Donc je ne suis pas sur que cela soit un pb de driver.

Mais je vauis quand meme regarder cette piste.

Merci

Voir les derniers messages : https://forum.pfsense.org/index.php?topic=134971.15

J'ai envie de hurler : il manquait la route retour …

C'est tellement simple et évident, que je m'était lancé dans l'analyse des trames réseau ...

Quand je pense au temps perdu sur ce problème ...

Merci grandement.
Merci grandement.
Merci grandement.

Je vous invite à créer un nouveau sujet. Votre problématique n'a de commun que le vpn avec le sujet sur lequel vous répondez. PornicFR traite de client nomade, vous de vpn intersite. C'est très différent.
Pour ce nouveau sujet je vous recommande la lecture de A LIRE EN PREMIER : https://forum.pfsense.org/index.php?topic=79600.0

En l'état je ne comprend que très partiellement à votre problème. En gros çà marche dans un sens mais pas dans l'autre. Aucune information technique n'est fournie  : plan d'adressage, topologie, règle, … Pas plus que la description de tests basiques qui ont été effectués, ou non. En gros votre question est du type : Quel âge avait Henri IV ?
Si vous répondez à cette question vous deviez comprendre dans quelle gêne nos sommes ou bien ne pas avoir besoin de notre aide.

Edit : Pas plus clair après votre second post !

salut salut

je dirais même plus, vous avec un char d'assaut et vous lui rajoutez des coussins tout au tour de lui pour ne pas qu'on lui égratigne la peinture ?

image forte mais pas si éloigner que cela, petit rappel de conception et de sécurité, un proxy doit être en retrait du pare feu pas sur le pare feu lui même.
en ne faisant pas comme cela vous vous rajouter une fragilité sur votre infra et facilité le travail pour une attaque de l'extérieur.

sinon comme la indiqué ccnet, c est un module rajouté , pas forcement maintenu coté support par cette communauté, voyez plutôt du coté du bon forum applicatif.

cordialement.

Rien compris non plus. Surtout avec ceci :

ce qui m’évite d’allumer le serveur pFsense inutilement

On se demande donc bien quel rapport avec Pfsense. Surtout éteint !

Bonjour,

Je ne vais pas répondre spécifiquement à la question posé mais, si tel est la demande, il est très facile de doubler la vitesse de téléchargement d'un seul est unique fichier en disposant de 2 lignes ou plus en load-balancing :D

Dans les faits il y aura bien 2 sessions distincte (1/ligne) mais la vitesse de dl du fichier serra à peut de chose près le cumul de la bp disponible sur les liens.

Il suffis pour cela d'utiliser Firefox ou Waterfox et avec l'add-on : DownThemAll
En fait, DownThemAll ouvrira 1 sessions par lien à sa disposition; de la même façon si l'on dispose d'une ligne type fibre et qu'il trouve plusieurs sources pour le fichier, il ouvrirra plusieurs sessions jusqu'a saturation de la bp disponible.
Il a aussi d'autres fonctions très pratique, perso, j’aurai vraiment du mal à me passer de cet outils ^^

Il doit surement en exister d'autres

My2Cents

La rotation des log définie au niveau de pfSense ne s'applique pas au niveau du package Squid, de mémoire.