Quand on ne peux pas accéder au proxy ce n'est pas trés pratique. J'ai essayer le commande export mais ça ne fonctionne pas donc on ne doit pas pouvoir dommage.
Merci

Bonjour,

Moi aussi j'ai ce probléme et je n 'est pas encore trouvé de solution mais j'ai une petite technique pour savoir. Lorsque tu regarde les logs d'authentification de ton portail captif tu voit quel utilisateur s'est connecté et surtout quelle adresse ip pfsense lui a attribué. Donc dans lightsquid il te suffit juste de regarder l'adresse ip correspondant à la personne recherché.

Cordialement.

Bon je n'étais pas loin.

Dans squid.conf j'ai décommenter/modifier 'acl our_networks src 192.168.221.0/24' qui je rappel est mon interface LAN et 'http_access allow our_networks password' au quelle on peux voir que j'ai rajouter 'password' afin que mes utilisateur s'identifie pour allez sur le WEB.

Voila si cela peut être utile à quelqu'un.

Titofe

tu peut jeter un œil sur http://forum.pfsense.org/index.php/topic,20973.0.html
y a des tutos intéressants

Merci :)

Je reviens sur ce post,
Dans la config décrite plus haut et ses dérivés pour obtenir le résultat désiré, je constate un trou de sécuritédans ma configuration:
Le client peut à tout moment ajouter une route dans son fichier de config qui va lui donner accès à d'autres segments du réseau ou des Vlans qui n'ont pas été autorisés ni sur le serveur ni dans le scc
Comment puis-je palier à cette situation? :'(

Je te remercie pour ton retour.

Je vais suivre ton conseil concernant le site Christian CALECA

A une prochaine, peut-être

C'est maintenant clair. La première et importante différence que je vois réside dans le fait qu'une règle avec une passerelle différente de la passerelle par défaut peut s'appliquer qu'à un protocole, port ou groupe de ports de destination. Ce qui n'est le cas d'une route statique.

Je ne suis pas très versé sur ce type de configuration "domstique" où le proxy tourne sur Pfsense. Je ne le fais jamais.

Pourriez vous m'indiquer quelques pistes pour un tutorial sur les Firewall rules pour une configuration simple et les plus utiles ?

Pas de recette. Bloquez dans les deux sens tous ce qui n'est pas nécessaire. le trafic sortant est aussi dangereux que le trafic entrant.

Dans Firewall: Schedules vous pouvez définir des plages horaires utilisables dans les règles. Servez vous en !

<mode joke="" musical="">Ca m'énerve</mode>

Il n'y a pourtant pas beaucoup d'éléments à brancher : (je suppose qu'il y a 1 pc pour pfSense + 1 pc de test + 1 switch + 1 routeur wifi + 2 cartes ethernet)

2 cartes réseaux (je suppose ethernet) : vont dans le pfSense (?), cela va FORCEMENT distinguer 2 réseaux : l'un WAN, l'autre LAN. routeur wifi : de quel côté on peut le brancher ? FORCEMENT du côté LAN. PC (de test) : de quel côté on peut le brancher ? FORCEMENT du côté LAN en ethernet ou en Wifi. 2 éléments à placer : d'où le switch

Bref, prendre 2 minutes de réflexion permet d'éviter de poser sur un forum une question aussi aisée …

(Va falloir s'y mettre parce que réussir un portail captif demande un peu de réflexion ... cf le n° du mois de Linux Magazine ...)

bonjour
j aurai du verifier, il etait en live cd  :(

a+

J'ai fini par ajouter du NAT en sortie du routeur_bis, ce coup-ci tout fonctionne.

Je pense que BSD réagit différemment des autres systèmes au niveau des routes avec pfSense.

Merci pour votre aide

C'est bien que vous ayez trouvé dans la doc le bon paramétrage des interfaces VMware.

Si j'écris/nous écrivons que chaque système de virtualisation a sa conception de la partie réseau de la virtualisation, c'est que c'est une réalité.
Pour VMware, il faut connaitre les switchs virtuels, leur affectation à une interface réelle, leur mode d'attachement à cette interface, et d'autres subtilités que j'ignore ayant peu travaillé avec. La doc doit forcément être parcouru et tout particulièrement la partie "networking", et ce quelque soit le système de virtualisation.

On peut gagner du temps en soumettant cela sur un forum, mais il ne faudrait pas cantonner un forum à trouver la bonne page du manuel. Sur ce forum (et d'autres), c'est la fonctionnement de la distribution qui est le sujet, pas la doc des virtualiseurs sur lequel on fait tourner …

Nous déconseillons aussi la virtualisation en prod de tout firewall, ce qui n'est pas contradictoire avec l'essai d'une distribution firewall (avec toute la prudence qu'il faut).

Effectivement, j'ai confondu le bridge de l'interface elle-même avec le bridge au sein de pfSense : bien que pfSense soit capable de fonctionner en bridge (c'est à dire intercalé de façon transparente), ce n'est pas un mode à conseiller. D'où ma réflexion.

Néanmoins la description du contexte est insuffisante : par exemple, il aurait fallu préciser les switchs virtuels (vmnet0 et vmnet ?), le lien avec l'interface et son mode (host-only, bridged, NAT traditionnellement chez VMware). Le mode usuel étant "bridged".

Ignorant le terme de "host virtual mapping", je trouve ceci http://www.vmware.com/support/ws55/doc/ws_net_configurations_changing_bridged_windows.html qui n'est peut-être pas exactement le cas mais doit s'en approcher ... A partir de 2 interfaces, il faut bien 2 switchs virtuels distincts : vmnet0 (de base) et vmnet1 ou vmnet3, laissant vmnet2 à son réglage standard.

Bref, problème pas assez décrit, doc peu approfondie, réponse un peu sèche, ... vous conviendrez qu'avec un peu d'effort de présentation, ce fil aurait pu avoir une réponse plus efficace ...

Oui, c'est ce que j'avais supposé.
Le serveur Voip étant connectée à OPT2 cela devrait marcher si la règle est en premier.
Dans la configuration d'OPT1 avez vous renseigné la bonne passerelle ?
Opt1 est connectée directement à un équipement télécom ou bien a un réseau comportant un routeur qui lui même serait connecté à l'extérieur ?
Dans le champ source de votre règle sur OPT2 utilisez plutôt l'ip de votre serveur Voip que any.

Vérifiez votre routage en réalisant des captures de trames, activez les logs sur les règles pour vérifiez quelle règle est appliquée. Si le problème persiste, postez votre plan d'adressage.

@gregober :

mynetworks :

Je peux me tromper mais "mynetworks" permet de désigner l'origine des machines dont le serveur mail accepte de relayer les mails (pour toutes destinations : pas seulement ceux gérés par le serveur : "mydestination" ou "relay domains" ou "virtual alias domains").

En clair,

un, le courrier est accepté, quelque soit l'adresse ip, si le courrier est à destination des domaines que gère le serveur ("mydestination" …), deux, le courrier est accepté, pour les adresses indiquées dans "mynetworks", pour les domaines gérés mais aussi les autres.

En quoi l'adresse publique aurait besoin d'être dans "mynetworks" ? En rien !
Un serveur Postfix, dans un réseau interne, peut avoir dans "mynetworks" le réseau dans lequel il est.
Un serveur Postfix, dans une dmz, pourra avoir le reseau Lan et le réseau DMZ (s'il y a des hôtes qui doivent envoyer des mails).
Mais, l'adresse ip public (externe) n'a nul besoin d'être dans "mynetworks".

Enfin, moi, je ne mets QUE ce qui est nécessaire dans "mynetworks" dans les serveurs internes que je gère.

Tu raisonnes (peut-être) sur le smtp du fai ... sur lequel ce qui est nécessaire est (forcément) déjà fait ! (Et sur lequel il parait impossible de faire quoi que ce soit !)

contexte du fil d'origine :

Il n'y a pas de serveur de mail interne. Il est mentionné seulement "serveur de l'ISP" comme si les connexions n'était que des smtp sortants de clients.
Je vois mal demander au FAI d'augmenter le nombre de connexions smtp entrantes simultanées !

Mais il y a forcément quelque chose d'incompris compte-tenu de la présentation ne précisant rien du tout (sans compter une config en bridge inutile) ...
Je pense plutôt au package "spamd" incompris (et inutile puisque destiné au trafic smtp entrant d'après ce que je comprends).

Mais faute d'informations ... 
(La question ne doit pas être très importante puisque le problème n'est pas relancé et puisqu'il n'y a presque pas d'informations !)

AMHA nul besoin de "split view" ici !

Je pense qu'il y a une confusion d'utilisation : une "split view" n'a d'intérêt que d'être interrogé depuis 2 zones bien distinctes (dont l'une est généralement internet).

Là, il s'agit de fournir localement des valeurs peut-être différentes des valeurs internet :

le serveur mail interne peut porter le même nom que celui externe (smtp.xxx.xxx) MAIS a, localement, une valeur différente de la valeur internet !

C'est très utilisé et fréquent (mais ce n'est pas du "splt-view") : il suffit de vouloir utiliser en interne le même nom que sur internet.

someferdi, qui s'est endormi, a déjà mélangé les choses en pensant ouvrir l'accès à son serveur dns interne ce qui est … totalement improbable !

Bonjour,

J'ai eu la même config à faire et après pas mal de recherches, tests et autres tentatives en particulier sur le NAT, j'ai trouvé une solution qui permette de réaliser cela.

J'ai installé squid sur la pfsense et je l'ai juste configurée en mode transparent et dans l'onglet "upstream proxy" j'ai configuré mon proxy externe.

Tout fonctionne correctement.

Bon courage

@jdh:

Je ne vois pas le rapport ! On a droit aussi d'être conseil (c'est une obligation) et de rappeler ce qui nous semble plus sûr.

C'est chose faite pour le conseil, mais avant de tout casser, je préfère y aller étape par étape : remplacement du roteur existant puis rélaisation d'une liaison VPN site à site.

@jdh:

PPTP est à bannir : il n'est pas sûr qu'il soit possible de passer 2 tunnels PPTP simultanés au travers d'un firewall !

Chez mon client, c'est possible au travers d'une box SDSL de Oléane.

@jdh:

=> Il est clair que, s'il y a une livebox devant un pfSense,

l'adresse ip cible (de chaque côté) doit être l'adresse ip publique de l'autre extrémité, la livebox devra renvoyer le flux (udp/1194, ou autre, éviter tcp !) vers le pfSense, il m'a semblé lire qu'il n'est pas possible, en 1.2.2 ou 1.2.3, que les 2 extrémités soient en ip dynamique.

(Je l'ai réalisé entre une ip dynamique/Livebox et une ip fixe/wan pppoe. Ainsi qu'entre une ip dynamique/sfr-neufbox et une ip fixe/wan statique. Sans problème, et les 2 fois avec certificats, même si cela prend plus de 5')

Merci pour ce retour d'expérience car pour l'instant je me suis cassé les dents sur le VPN site à site via IPsec. Je vais donc explorer la solution avec OpenVPN. Le problème dans mon cas est que l'IP WAN arrive sur la box de Oléane et que mon IP WAN sur le PF est en 192.168.1.X. D'après FT, tout ce qui arrive sur l'adresse IP WAN est automatiquement transféré sur mon IP 192.168.1.X de façon transparente, c'est un pont à la Oléane…

Merci encore pour ton retour, je reviendrais pour vous tenir informé de la suite.

Nusa

Bonjour,

savez-vous si l'on peut utiliser Squid et le traffic shapper en même temps? Je n'y étais pas parvenu sur la version 1.2.3.

Merci