Encore meci pour vos réponses,
je vais opter pour la suggestion de Chris, je vas rajouter un autre Switch à l'autre extremité du cable.
Je viens de commander le même switch manangeable (TPLSG108E).
je vous tiens informé dès la fin de l'installation.

C'est une question dont la réponse est dans la documentation Orange, ou à voir avec le support Orange. Je n'ai pas de Livebox sous la main pour suppléer le support Orange. Et puis il faut un peu vous prendre en main, c'est formateur.

Stop aussi.

Bonjour, et merci pour votre réponse.

En creusant les docs de FreeBsd j'ai pu trouver et éditer la Crontab pour commenter les lignes faisant références à Sarg : Ça n'est pas le plus propre mais cela devrai éviter les messages log parasites.

NB : Attention, certaine règles semblent trop larges : LAN subnet -> pfsense pour 3128/tcp (Squid) : inutile d'aller vers 'any' !

Merci, cela réponds indirectement à une question que je me posais sur le filtrage proxy vs le filtrage sans proxy => à travailler.

En faite il ne s'agit pas d'une ip virtuel que j'ai crée en plus,
mais de l'ip que le serveur openvpn ces attribué pour le tunnel.

Je l'ai rajouté dans le schéma en rapport avec le tcpdum de mon 1er poste

Il y a un sérieux problème d'explication/compréhension :

Par ailleurs, je ne dois pas être seul à ne pas connaitre Beronet … (j'assimile ce beronet à un serveur xen à plusieurs interfaces physiques mais j'ignore les définitions d'interface et donc liens entre VM.)

Dans mon message d'origine je précise qu'il s'agit d'une appliance qui tourne sous Linux Alpine et qui embarque Xen

Je fais donc une assimilation correcte : le lecteur qui recherche 'Beronet', qui tombe sur une appliance hardware, ne se représente pas instantanément un serveur Xen !

Ce que vous découvrez est le fonctionnement (parfaitement) 'normal' d'un firewall : le flux sortant par WAN utilise (forcément) l'ip source de WAN.

Dans mon second message je précise que les paquets sortent vers Internet avec l'IP source d'un réseau privé, la 192.168.10.78 du PfSense et non celle de l'interface WAN (IP publique du Routeur/FW du LAN #1), c'est bien là le problème!

Désolé, les flux sortants de pfSense DOIVENT sortir et SORTENT avec l'ip WAN de pfSense, c'est une certitude ! Dans le schéma 2, vous indiquez 192.168.10.78 pour WAN, ils sortent avec cette ip; et Il ne peut y avoir d'accès Internet avec une ip privée (regardez le schéma 2 : vous placez le firewall entre Internet et WAN, donc le WAN est le LAN du firewall !

Je ne vois pas ce PC sur vos schémas, mais je suppose qu'il se positionnerait comme VM #2 (et via une interface physique spécifique).
Si ce PC fonctionne correctement (et donc via pfSense)

Je précise: les liens xDSL entrent dans un serveur sur lequel tourne Sophos UTM en VM (Routeur/FW du LAN#1). Il s'agit d'une Debian avec KVM. Deux VLAN 1001 et 1002 sont dédiés respectivement aux liens #1 et #2. Je peux donc vérifier le traffic sortant vers Internet à partir de cette Debian en capturant les paquets des VLAN

Comme dit plus haut, ce n'est pas du PfSense, Sophos UTM

Vos explications indiquent que le PC, non rappelé dans le schéma est situé côté LAN de pfSense : il DOIT traverser pfSense avant d'aller vers Internet. Dans les 2 réponses, on comprend que le PC est en fait une Debian virtualisée placé avant ou après pfSense, ce qui ne correspond pas à l'explication initiale 'Dans le même temps, un PC est connecté au réseau local géré par ce même PfSense.'.

Il est très difficile de comprendre votre problème car vous n'avez pas compris ma demande 'les choix en matière de réseau concernant la virtualisation'.
Etant devant votre installation, il est nécessaire de vous relire car les lecteurs ne sont pas devant, et ne peuvent deviner vos réglages et le schéma !

Clairement, ce qu'on comprend, en final,

Xen (ou KVM), par défaut, active une option 'tcp checksum offloading' qui joue un rôle important dans le cadre de la virtualisation, spécifiquement avec les drivers 'VirtIO' (sensés être les plus performants). l'explication du fil indiqué est particulièrement explicative du problème et donc de la solution.

NB : à OFF dans ESXi 5.5 et 6.0

Le mécanisme de 'tcp checksum offloading' est connu, notamment soit par du hardware soit par des réglages bios. Il est sage, quand on balaye une installation de mettre ce genre de mécanisme à OFF …
De plus pfSense sait aussi s'y adapter ...

Une fois de plus, on voit la pertinence à utiliser un formulaire dans lequel on fournit dès le départ des informations plus complètes ...
Je ne répondrai pas à une demande aussi incomplète ...

De rien  ;)

Merci de modifier le titre du post avec [Résolu]

Cdt

@matosman:

J'aurai voulu utiliser 2 ports de pfsense comme le fait un switch.
C'est à dire basculer l'acces wan sur le lan de pfsense et le port de livebox.

De cette maniere, je configure l'acces internet sur le lan et la livebox se connecter à internet avec les identifiants "fti/"

Ce que tu décris ne me semble pas cohérent d'un point de vue réseau. Cela n'a rien à voir avec pfSense d'ailleurs  ;)

Ton fournisseur d'accès va t'attribuer une (ou plusieurs selon ton abonnement) adresse IP qui doit correspondre à une adresse MAC.
Si pfSense fonctionnait, comme tu le veux, "comme un switch" pour que ta Livebox se connecte en PPPoE, alors pfSense ne pourrait pas prendre en charge le contrôle de ce qui se passe au niveau IP. Pour faire simple, ça ne marche pas  :P

Si tu veux absolument conserver ta Livebox, il faut que celle-ci soit connectée à ta fibre.
Je ne te dis pas qu'il faut que tu ais absolument une livebox. Il doit être possible, comme pour l'accès ADSL, d'utiliser les services d'Orange sans Livebox mais si celle-ci doit être présente sur ton infrastructure, il faut qu'elle soit en bordure de la connexion avec Orange.

Si tu mets à la place pfSense, il y a des montages possibles pour faire un bridge du VLAN vidéo (il y a un autre sujet ouvert il y a très peu de temps à ce sujet) mas ça ne ressemble pas du tout à un "switch"  ;D ;D ;D

Merci pour vos réponses,
il va falloir que je passe par une bonne phase d'étude des réseaux avant de penser à mettre en place une telle solution  ;D.

Le débat 'Squid sur firewall' est récurrent.

Forcément, les arguments s'évaluent en fonction de SES propres critères.

Néanmoins les restrictions à Squid sont assez claires :

package : aucune garantie, limité aux fonctionnalités incluses charge : impact sur le fonctionnement, sur le besoin mémoire.

Face à cela, le proxy dédié offre des avantages nets et clairs :

aucun impact particulier sur firewall fonctionnement tel qu'on le souhaite gestion complète et affinée du filtrage, des logs, … capacité à respecter la loi de janvier 2006 !

Il est clair que cela exige plus de compétence pour créer un proxy dédié et qu'on ne bénéficie pas de l'interface, mais on fait exactement ce qu'on veut (et sans impact sur le firewall).

Bref c'est à recommander dès qu'il y a un trafic qui commence à devenir important : disons un ligne fibre et 15 utilisateurs ...

Comme souvent, il y a la réponse en 2', puis la réflexion sur la bonne méthode, le bon schéma, ...

Pour revenir au sujet, j'ai répondu, non sur la question qui demandait juste 2' de recherche, mais sur l'esprit, le fond.
Comment allez vous gérer les milliers de lignes de Squid dans syslog ?

@jdh:

Dans la doc de base https://doc.pfsense.org/index.php/Captive_Portal on lit

The Captive Portal function in pfSense allows securing a network by requiring a username and password (or only a click through), entered on a portal page.

If authentication is used, this can be performed using pfSense's built-in user management, or an external authentication server such as a RADIUS server.

The best source of captive portal information can be found in the pfSense book.

Captive Portal is configured from Services > Captive Portal.

Le stockage des données utilisateurs est (forcément) réalisé par le serveur RADIUS (external).

NB : cela n'a rien à voir avec les 'utilisateurs' pfsense !

:-\

Dans l'extrait de doc que tu mets en avant, et c'est parfaitement clair dans l'interface du portail captif également, il est spécifié que tu peux, au choix :

t'appuyer sur la base de comptes créés dans pfSense utiliser un serveur Radius

Après, ce qui est un peu plus tordu, et c'est, si je comprends bien, justement la demande de Manu2607  ::) , c'est de vouloir utiliser un serveur Radius (externe donc) qui s’appuierait sur la base de comptes pfSense.

Bonjour,

Merci à tous de vos conseils! J'ai changer le port en 443 TCP et depuis tout fonctionne :)
En revanche le Nmap ne me remonte pas le port ouvert ce qui est étrange tout de même ?
Je ne sais pas comment se comporte la règle crée automatiquement par OpenVPN sur le firewall donc peut être qu'elle "n'ouvre" pas le port en temps que tel (IPv4 UDP * * WAN address 443 (HTTPS) * none   OpenVPN OPEN_VPN_NE wizard )
En tout cas je vous remercie tous de vos conseils constructifs!

Bonsoir,

Je m'excuse de ne pas avoir pu revenir vers vous plus tôt mais Steven tu avais raison j'avais bel et bien un problème au niveau des règles de mon pfsense.

L'une de mes règles n'autorisais pas la communication vers mon autre site (j'ai honte).

En tout cas je vous remercie, ça marche niquel !

Dans ce contexte (milieu, charge induite, responsabilité, …), il n'y a pas d'hésitation à séparer les fonctions

un firewall (non virtualisé) (ou, mieux, 2 pour faire un cluster) une machine Snort, avec la config d'écoute  adapté sur le LAN. une machine proxy avec Squid/SquidGuard + gestion logs + gestion blacklist ...

Les 2 dernières machines peuvent être virtualisées.

@chris4916:

Je ne me souviens pas avoir vu le paramètre "keepalive" exposé dans l'interface d'admin de OpenVPN mais tu peux toujours essayer de le préciser dans les options de configuration. Je n'ai cependant pas fait de test pour voir si cette valeur personnalisée va remplacer la valeur par défaut.

je vais tester dans ce cas et je te redis quoi  ;)
merci

@lololo:

donc j'utilise Haproxy non pas pour faire du load balancing mais pour faire du reverse proxy (beaucoup plus léger que nginx). il me permet de pouvoir accéder à toutes les machines de mon réseau par leurs noms d’hôte et un port assigné (ex syno.mondomaine.com arrivera directement sur mon synology sur le port 5001)

Le problème est que depuis le lan cela ne fonctionne pas car apparemment c'est le dns forwarder qui prends le dessus.

Si tu veux pouvoir accéder à ton Synology à la fois depuis le LAN et depuis internet en utilisant la même config "client", il suffit que (toutes les assertions suivantes sont liées par un "ET") :

le DNS interne pointe le nom de ton serveur "syno" vers Synology  (pas de HAproxy ici) le DNS publique pointe le CNAME "syno.tondomaine" vers ton IP publique (sur laquelle écoute HAproxy) le port d'écoute du Synology est le même que le port d'écoute du HAproxy pour ce service

Depuis internet, tu accèdes au HAproxy qui fait le relai vers le service en interne
Depuis le LAN tu accèdes en direct su Synology

et ça marche  8)

Si les ports sont différents… ça ne marche pas sauf à avoir une config client différente selon que tu es sur le LAN ou sur internet. Et ce n'est pas un problème de HAproxy  :P

Merci d'utiliser le formulaire de présentation : par exemple, il est nécessaire de chercher avant de poser une question et d'indiquer le résultat des recherches …

Chris4916 présente une 'bonne réflexion'  (explications progressives correctes) :

il y a une mauvaise compréhension du terme 'portail captif' (surtout dans un contexte 'log de navigation') le proxy est certainement la bonne réponse fonctionnelle pfSense (firewall et non proxy) n'est certainement pas adapté compte tenu de la charge et des limites du/des package/s

Il faut vous orienter sur l'install d'un proxy Squid avec les questions :

l'authentification (obligatoire) : quel protocole, quelle source le filtrage de blacklist (obligatoire) : cf la blacklist de Toulouse le log, la visu des logs, le stockage des logs : obligation légale (loi de janvier 2006)

Il reste un rôle à un firewall : assurer que SEUL le proxy peut accéder à Internet.

(Voyez que je ne dis pas toujours du mal de Chris4916 ... quand il écrit des choses correctes).

merci beaucoup a tous!!
je me suis beaucoup enrichie à travers vos interventions.
J'aimerai pouvoir être aussi ingénieux que vous et pouvoir apporter souvent ma contribution mais malheureusement je suis novice dans pfSense et j'espère me perfectionner a travers mes recherches et avec votre soutien.

Là maintenant je vais m'attaquer au volet VPN (OpenVPN) avec des recherches d'abord et si après j'ai des difficultés je vous en ferai part!! ;)

Merci et que Dieu vous bénisse!!!
Cordialement

Soyons encore plus précis,

Le wiki de Squid est (nécessairement) la référence à regarder : http://wiki.squid-cache.org/ConfigExamples/#Authentication
La section 'Overview …' est indispensable !

On trouve donc une authentification

par Radius par Kerberos par NTLM (protocole tradi du monde Windows, dépassé par Kerberos) par LDAP (ActiveDire est un LDAP un peu spécifique)

Il est très clair que cela suppose que Squid ait été compilé avec les bonnes options de librairies et que les dites librairies soient présentes. (Sans compter le niveau de Squid nécessaire ...)

Dans le mode Windows, il me semble fréquent d'utiliser soit NTLM soit LDAP. (Mes souvenirs sont lointains ...). L'idéal devrait être Kerberos qui est aujourd'hui le protocole le plus sûr.
Et il faut savoir que les librairies nécessaires viennent parfois d'autre logiciels : ex NTLM suppose des lib de Samba ...

Bref Squid + une authentification sera bien plus possible ... hors de pfSense, car il n'y a aucune garantie que le (ou les) 'package' comportent et Squid et les librairies nécessaires.
(Sans compter, ce que méprend pas mal de gens, la charge machine et mémoire inhérente à un gros trafic et grand nombre d'utilisateurs ...)

Bref la question n'était pas tout à fait un besoin ni tout à fait une solution : 'authentification transparente' = besoin, 'authentification par Radius' = solution.