Bonjour,

Je suis d'accord avec JDH, il ne peut y avoir qu'un DHCP sur le bridge.
Le premier serveur qui répond à la requête fournis l'adresse.

Bien à toi

Bonjour,

Je suis nouveau dans le forum.

Je n'ai malheureusement pas les réponses à tes question, mais J'ai, comme toi des problèmes avec pfsense et squidgard.

J'ai une infrastructure complètement virtualisée et mon pfsense l'est aussi. J'ai ajouté squid et squidgard sur le pfsense 2.4.4

Mon traffic vers internet devient incroyablement lent quand j'active squid.
Vu les commentaire ci-dessus je vois que c'est normal, car pas conseillé d'installer squid sur pfsense.
Mais pourquoi ?
N'y  at'il pas moyen de gonfler la vm pour le faire quand même ?
J'ai encore de la marge pour du cpu et de la ram, mais combien peut en supporter la vm pfsense a votre avis ?

Merci

PS: je dois ajouter que j'ai 150 personnes qui utilisent cette ligne :-)
De plus j'ai activé 10 vlan sur l'interface LAN

@baalserv:

reste plus qu'à placer la règle à la bonne place sachant que la bonne place dépend des autres règles et vu que vous ne nous donner aucune info …

Un screenshoot des règles de l'interface concerner EST le STRICT minimum à nous fournir si vous nourissez l'espoir que l'on vous réponde autre chose qu'une banalité !

Bonjour, je laisse tomber la connexion de secours en 3g

Test:
clé 3g huawei e182E et une antenne yagi connecteur crc-9 (voir photo)
pour les azimuts chercher la position des antennes en 3g sur http://www.antennesmobiles.fr ou http://www.cartoradio.fr/ puis l'azimut grace à http://www.geoportail.gouv.fr/

Résultat:
En forçant la 3g/4g sur la clé et me mettant sur le toit du bâtiment (assez dangeureux  d'ailleurs) j'obtient sans l'antenne une connexion 3g de 0 à 1 barre et avec l'antenne je perd complètement le signal. j'ai bien essayer d'orienter l'antenne dans plusieurs direction, aucun signal

conclusion:
Bien que cela fonctionne chez d'autres personnes en voyant les articles ou les vidéos sur internet, dans la zone ou je test ceci n'est pas viable (je manque peut etre aussi des connaissances requises)
Je vais rester sur l'adsl voir le sdls/efm (le standard va peur être passer en ipbx donc connexion fiable obligatoire

Merci à vous.

yagi.png
yagi.png_thumb

J'ai récupéré une carte mère générique et un Intel Pentium E2180 @ 2.0GHz et 4Go de DDR2, j'ai branché la Intel Pro Dual Port dessus pour faire des tests, après vérification ce CPU est moins puissant qu'un Celeron J1900, en même temps il y a 7 ans d'écart entre les deux.

J'ai aussi une possibilité de récupérer des serveurs à mon boulot, il y en a 3 dans la réserve qui prennent la poussière, des Dell mais pas rackable, des grosses tours, j'ai vu l'autocollant Xeon, mais bon je ne connais pas la date d'achat donc ça peut aussi bien être pire  ;D

Re,

FT est intervenu 3 ou 4 fois pour corriger des problèmes qui étaient pour eux des problèmes. Comment dire, maintenant pour eux la ligne est plus que parfaite mais pour moi les problèmes restent identiques. J'ai cherché un moment dans cette direction mais sans succès. Je penchais aussi pour un problème avec un quelconque boitier style alarme ou je ne sais quoi accessible ou accédant au web par la ligne adsl. Il m'est aujourd'hui impossible de le savoir. Merci pour ta réponse jdh.

Résolu.
L'interface pfsense wifi était tagué sur deux ports, et le VLAN data était par default.
Je l'ai mis sur un seule VLAN, tout fonctionne.

Merci a vous.

Je prends note pour mes futures postes.

Merci pour cette réponse.

C'est bien ce que je craignait, c'est donc un peu plus complexe que prévu. Je vais donc essayer la piste du proxy, vu que je ne souhaite pas faire modifier les paramètres des navigateurs.

Je vais tester avec les packages PFsense pour voir.

A partir d'une certaine taille (disons 15 utilisateurs un peu actifs), ce qui est judicieux

un firewall pfsense

un proxy dédié avec Squid, SquidGuard (filtrage blacklist), et lightSquid (log d'utilisation)

le réglage des pc clients par WPAD : fournit le proxy à utiliser pour chaque protocole géré par Squid (http, https, ftp)

des règles qui autorise la sortie pour le proxy et l'interdiction pour les autres

La contrainte sur les PC clients sera minimale : juste config auto (=détection par WPAD).
Les PC clients fonctionneront à la fois dans le réseau de l'entreprise et ailleurs.

Cela s'appelle un model hub and spoke, a opposer au model full mesh ou vous etablissez un tunnel entre chaque point (plus complexe a configurer mais plus efficace en termes de debits/latence)

C'est faisable et plutot simple a mettre en oeuvre.
Faudrait il encore savoir sur quel protocole vous souhaitez implementer…. Ipsec ? Ssl (openvpn)

Le lien VPN IPsec fonctionne correctement. Seul des tests de débits sont à effectuer !
Je vais faire le test du failover avec un DNS dynamic.

Je reviendrai vers vous une fois mes tests effectués.

YAHOOOOU

Bon bah installation de la dernière version sur machine physique et ça à l'air de bien fonctionner.
Réponse au problème: Virtualisation pas adaptée.

Merci d'avoir pris du temps pour m'aider,
Cordialement,
Risen.

ok.jpg
ok.jpg_thumb

Moi aussi je voir se même message et franchement je suis tres  >:( "Eror sending request : No valid RADIUS responses received"

Bonjour,

Pour que les Vlans ne puissent pas communiquer entre eux, dans ce que je connais de PFsense, tu es obligé de passé par des règles.

Le moyen idéal serait que Quagga supporte plusieurs instances de routage (VRF ou VPN-MCE chez Cisco/HP) ou encore mieux le MPLS. tu peux bloquer les réseaux intervlans en rajoutant à la bonne position une règle flotante par exemple sur toutes les interfaces concernées. En gros, tu bloques les réseaux de classe A/B/C sur ces interfaces, mais en positionnant correctement le fait que tes serveurs puisse réponde.

exemle : ton vlan10 est en 172.16.0.0/16(sur sa patte et tout ses sous réseaux si il y a des routeurs derrières). Ton serveur DHCP est en 10.1.1.1.,  ton dns est en 192.168.1.1 et les autres vlans sont en 172.17.0.0/16, 172.18.0.0/16  et 192.168.2.0/16

Dans la règle du vlan 10, tu auras en gros

drop any classeC (un alias du 172.16.0.0/12)
permit any 10.1.1.1 udp 67
drop any classeA (un alias du 10.0.0.0/8)
permit any 92.168.1.1 udp 53
drop  any classeB (un alias 192.168.0.0/16)
et après des règles. Dans ce cas, ton vlan 10 ne pourra pas communiquer avec les autres réseaux mais pourra surfer etc.. selon ce que tu l'autorise. Si besoin, tu rajoutes la ressource entre les règles drop concernées si besoin. La limite de PFsense et de cette solution c'est que tu ne peux pas superposer des réseaux identiques sur tes interfaces à cause de la limite que j'ai énnoncée au début.

l'ordre est important car toutes les règles générés par l'interface pfsense sont en "quick" pour plein de raison que je ne résumerai pas ici.

Pour la fausse bonne idée. Non, cela dépend de tes besoins, de tes ressources machines etc… Séparer est plus idéal mais si c'est pour un accès avec 8 vlans, très peux de traffic, un pfsense non redondé, c'est peut-être adapté. Difficile de juger une archi sans avoir le détail et les poyens qui sont à ta disposition. Bonne chance

Bonjour,

@Tatave:

un schéma, les adressages (avec des x pour les ip externes) la config des interfaces, les règles de NAT créés, le type de serveurs web, sa config

Voir le fichier joint.
Les IP WAN sont sur le même RIPE. L'environnement est complètement virtualisé sous Promox.
Les IP Public utilisent les MAC Groupées de Online (IP Public associé à la même MAC addresse).
Par contre, comme pour les IP failover d'Online, la passerelle par défaut n'est pas sur le même subnet que le RIPE (D’où l'usage de shellcmd basé sur ce tuto : http://forum.online.net/index.php?/topic/1240-tuto-esxi-pfsense-comme-firewall/)

@Tatave:

les tests effectués, les résultats

@ymolinet:

Comment j'ai déterminé que la pfsense était concerné ? tout simplement parce que les services web sur cette IP répondent parfaitement en interne, idem pour le ping. Hors, depuis le shell de la pfsense, le ping ne passe pas. Idem depuis une source VPN (OpenVPN de la pfsense).
De plus, un redémarrage de la pfsense résout le problème, puis après plusieurs jours, le problème réapparaît. Aucune log dans le journal du firewall n'indique un rejet ou un drop de paquet sur cette IP.
Les autres IP de ce serveur web fonctionne parfaitement, même depuis la pfsense.

Autre test réalisé: Un telnet sur le port 80, 21 ou 443, qui n'accroche pas non plus.
J'en déduit donc que le module firewall bloque le traffic, mais je n'ai pas trouvé de log indiquant que pfSense à bloquée du traffic.

img012-2.jpg
img012-2.jpg_thumb

Si on "réfléchi" un peu, un proxy qu'est ce que c'est, si ce n'est un "man in the middle" précisément ?