Provya

@Cyril :
Bonjour Cyril,

Je pense que le problème soulevé par Florent n'est pas exactement celui que vous soulevez. Florent souhaitait s'assurer de conserver la même adresse IP de sortie au cours d'une navigation (d'une session) sur un site donné (comme un site bancaire, par exemple) afin de ne pas en être déconnecté. La solution réside, entre autre, dans le paramétrage des sticky connections.

Dans votre cas, si je comprends bien, vous souhaitez additionner votre débit. Ce sera effectivement le cas pour plusieurs sessions parallèles (qui seront bien load-balancées sur les 2 connexions Internet) ; vous accéderez bien à la totalité du débit offert par vos 2 connexions. En revanche, ceci n'est pas possible nativement pour une seule session (un mono-téléchargement, par exemple) - ce qui est logique car pour une session vous sortez sur Internet avec une adresse IP et vous êtes donc forcément rattaché à une seule connexion Internet. Si c'est ce que vous recherchez (additionner le débit de vos 2 liens pour une mono-session, c'est-à-dire un mono-téléchargement), vous pouvez regarder du côté des solutions type OverTheBox.

Cordialement,

Guillaume
--
Provya

@Guillaume

Bonsoir Guillaume,

Ma question faisait suite au paramétrage du double WAN et à l'interrogation de Florent évoquant le fait qu'une requête pouvait, du fait du double WAN, se présenter avec l'une et l'autre des adresses IP.

Mon objectif étant de "doubler" mon débit, j'envisageais de prendre un deuxième accès auprès de mon opérateur actuel. Mais le problème souligné par Florent m'interroge. J'ai en effet déjà été confronté à ce problème sans réussir à le résoudre (un accès WAN xDSL et un accès WAN satellitaire), je n'ai jamais réussi à "additionner" les deux débits ; ça passait par l'un ou par l'autre, ou ça échouait tout simplement.

Dans votre réponse (https://www.provya.net/?d=2017/11/24/11/31/31-pfsense-configurer-un-dual-wan-plusieurs-connexions-internet#id709fbc), vous dites que la solution à ce problème est très simple. Malheureusement pour moi, je ne la trouve pas, d'où ma précédente publication.

En vous remerciant pour votre précieuse aide. Bien à vous,

Cyril

@Cyril :
Bonjour Cyril,

Je ne suis pas sûr de bien comprendre votre besoin.

Si vous recherchez une aide communautaire sur un problème spécifique, je vous invite à poster votre demande sur le forum officiel pfSense : https://forum.netgate.com/category/8/fran%C3%A7ais

Cordialement,

Guillaume
--
Provya

@Guillaume :
Bonjour Guillaume,

J'écume depuis quelques jours votre site et les commentaires, mais je ne trouve pas l'article ou le cours que vous évoquez dans ce commentaire :
https://www.provya.net/?d=2017/11/24/11/31/31-pfsense-configurer-un-dual-wan-plusieurs-connexions-internet#id709fbc

Auriez-vous la gentillesse de m'orienter, s'il vous plait ?

Bien à vous,

Cyril

Super Merci

@FloLaco :
Je me répond tout seul ... En fait, il faut mettre dans la partie NAT 1:1 l'interface OpenVPN et non pas WAN. En effet le fonctionnement du 1:1 se fait dans les deux sens j'ai l'impression. A savoir, le PfSense local, quand il envoie le trafic dans le tunnel, il change l'IP source du site A puis l'envoie au site B, et le site B se charge de NAT l'IP destination.

Ainsi :
10.0.0.4 to 192.168.151.10 ---PfSense site A---> 192.168.150.4 to 192.168.151.10 ---PfSense site B---> 192.168.150.4 to 10.0.0.10

Bonjour ,

Merci pour votre article. En revanche, êtes vous sur qu'il ne manque pas une partie de la config ?
En effet, quand le site A envoie au site B, son IP source est toujours en 192.168, or, quand le site B voudra répondre, il va répondre à 192.168, qui est sont propre LAN et ainsi le flux ne partira dans le VPN mais restera dans le LAN.

Merci à vous

@nico :

ou pas.

Prétendre qu'il y a une seule solution absolue en matière de sécurité est la marque d'une grande méconnaissance pour ne pas dire incompétence, et est dommageable aussi bien pour la réputation de l'auteur que pour le domaine de la sécurité en général.

Une utilisation par clé uniquement complexifie sensiblement les choses, il faut maintenant avoir une politique de gestion des clés correspondant au modèle de menace, et ça impose un peu de gymnastique pour traverser la machine qui sert de rebond pour accéder au réseau interne. voir https://blog.octo.com/le-bastion-ssh/ pour plus de détails.

Au delà de cette complexification, elle introduit des incompatibilités avec certains usages et introduit des failles et des problèmes de sécurité avancées qui n'existent pas forcément avec un mot de passe.

L'usage de clé est souvent un bon choix mais ce n'est pas toujours le cas. Par rapport à mon modèle de menace personnel l'usage d'un bastion ssh dont le service est masqué derrière du port knocking apporte le niveau de sécurité suffisant sans avoir besoin de recourir à l'usage de clés.

Fail2ban ce n'est pas que du ssh. C'est aussi du contrôle pour le smtp, le pop, l'imap, le http, le ftp et de manière générale tout ce qui peut générer des logs utilisables, donc oui c'est très intéressant.

De plus même si vous avez des briques d'authentifications solides comme du roc, fail2ban permet de réduire le nombre de tentatives de connexion et d'éviter des dénis de service sur l'auth.

SSH c'est keypair auth only. Du coup fail2ban ne sert absolument à rien dans ce cas.

Par contre certain logiciel qui repose sur du mot de passe n'ont pas de sécurité de ce type par défaut et la oui un Fail2ban peut être intéressant.