2 IP publiques sur une patte WAN ?
-
@pascalb41 said in 2 IP publiques sur une patte WAN ?:
Je voudrais revenir sur ma question et la partie de votre réponse qui la concerne plus particulièrement :
"Côté pfSense et côté WAN, la box Orange ftth est en mode routeur : vous disposez d'un réseau /29 soit 5 adresses ip publiques disponible : l'interface WAN de pfsense utilise une de ces 5 ip publiques, mais les règles de NAT Outbound ou 1-to-1 permettent de sortir avec une des 4 adresses ip restantes. (Je préconise de créer des alias type 'ip154', ... pour lire l'ip de sortie instantanément). Pour votre Pabx/Ipbx, ce sera 1-to-1, et ce sera très simple puisque la règle NAT 1-to-1 se suffira à elle-même !"
La Livebox Business d'Orange n'est pas en mode routeur mais en mode bridge. Tout peut sortir et tout peut rentrer, c'est à mon pfSense de gérer les accès sortants et entrants. J'ai bien 5 adresses IP publiques et c'est là que je ne comprends pas bien comment je peux dédier une de ces adresses à mon PABX sur IP car mon pfSense utilise effectivement la première de ces adresses IP publiques. Ce que je ne vois pas c'est comment je peux faire en sorte que le trafic entrant sur une autre de ces adresses IP (la 2ème) soit redirigé vers mon PABX. J'ai un lien matériel unique entre un des ports Ethernet de mon routeur Orange xxx.xxx.xxx.158 et le port WAN1 de mon pfSense qui a pour adresse xxx.xxx.xxx.153. Si par exemple je veux dédier l'IP publique xxx.xxx.xxx.154 à mon PABX, comment dois-je procéder sur mon pfSense qui n'a pour adresse que xxx.xxx.xxx.153 ?Votre Livebox n'est pas en bridge, car ce n'est pas le même réseau de part et d'autre : côté de votre réseau, il y a juste un réseau /29 et côté Orange il y a Internet en totalité (sauf votre petit réseau). Plus simplement, Orange sait très bien que le réseau /29 est routé via votre Livebox. Donc la Livebox est en mode routeur AMHA. (en tout état de cause, tous paquets émis depuis la patte WAN du pfSense est envoyé à la gateway = la Livebox, et ce quelle que soit l'ip source du paquet.)
L'opération qui affecte une adresse ip publique comme ip source, est la translation d'adresse réseau = NAT = Network Address Translation.
Dans Firewall NAT, il y a 3 sous-menus :
- Port Forward : flux dans le sens entrée (Internet -> local)
- Nat Outbound : flux dans le sens sortie (local -> Internet)
- Nat 1-to-1 : flux dans le sens sortie (local -> Internet) pour le cas de machine spéciale
Avec le NAT 1-to-1, vous définissez une adresse ip publique associée à une machine : tous les flux entrants avec cette ip ira vers ce serveur interne, et le serveur interne sortira automatiquement avec cette adresse ip. C'est exactement ce qu'il convient pour votre Ipbx. Je ne suis pas certain que cela vous dispense de réaliser le NAT Port forward qui autorise le flux entrant ... mais au moins vous n'avez pas besoin de regarder le NAT Outbound.
Le NAT Outbound est, justement, la technique générale de changement de l'ip source : par défaut, il n'y a qu'une règle : tout le LAN utilise l'ip WAN du pfSense. Mais on peut très bien définir des règles spécifiques (attention à bien les placer en tête !) : le trafic de tel serveur (pour tel trafic) utilisera l'ip définie au choix des 5 dispos.
En fait le NAT 1-to-1 est juste une écriture simplifiée de règles Port Forward et Outbound bien spécifique pour la machine choisie.
Je vous conseille le NAT 1-to-1 pour votre Ipbx, c'est très adapté.
Quand on a 5 adresses ip, on peut bien réserver 1 adresse pour un serveur donné. Mais quand on a pas mal de serveur interne et peu d'adresses ip publique, on est bien obligé de limiter les 1-to-1. Exemple, un serveur SMTP, s'il reçoit sur une adresse ip donnée (MX) doit aussi utiliser cette ip en sortie, mais cela ne concerne que le trafic smtp=25/tcp. Donc on peut partager cette adresse avec un serveur SFTP ou un serveur WEB car ils n'utilisent pas le même port (exemple mal choisi car ce ne sont pas des serveurs 'bi-directionnel' comme smtp).
-
Merci pour ces explications, je pensais que c'était plus compliqué et qu'il allait me falloir une interface WAN par adresse IP publique.
Je vais créer la règle de NAT qui convient.
Pascal -
Si vous voulez jouer, aucune difficulté : ajoutez une règle dans NAT Outbound ... au début
- pour le LAN
- pour le trafic 80/tcp et 443/tcp (2 règle)
- avec sortie sur une autre ip que WAN Address
En allant sur un site 'quelle est mon adresse ip', vous verrez de suite le résultat !
-
C'est exactement ce que je voulais utiliser comme test ;-)
Parce que jouer avec la connexion du PABX ça serait mal vécu ici :-)
Pascal -
Bon, ça ne fonctionne pas et pour cause, on en revient à ma question d'avoir sur mon pfSense 2 adresses IP différentes sur le même sous réseau /29.
J'ai appelé mon support Orange Business qui m'a confirmé que tout trafic entrant sur une de mes 5 adresses IP publiques xxx.xxx.xxx.153 à 157 était redirigé vers le noeud qui avait cette adresse IP xxx.xxx.xxx.153 à 157.
Mon pfSense a sur sa patte WAN1 l'adresse xxx.xxx.xxx.153/29 et il répond bien lorsqu'on pingue cette adresse. Et j'ai des flux entrants qui arrivent par cette adresse et qui sont redirigés vers les machines qui vont bien sur mon réseau.
J'ai donc pris un PC, je lui ai mis l'adresse xxx.xxx.xxx.154/29 avec pour adresse de passerelle xxx.xxx.xxx.158.
Je l'ai branché sur le même réseau que le routeur Orange et le WAN1 de mon pfSense.
Ensuite, de l'extérieur, j'ai pingué l'adresse xxx.xxx.xxx.154 et j'ai eu une réponse de ce PC.
Si je débranche le PC, le Ping ne répond plus.Donc pour que je puisse utiliser l'adresse xxx.xxx.xxx.154 via pfSense il faut que celui-ci ait une patte avec cette adresse.
Pascal.
-
(J'ai eu des pfSense dans ce type de config il y a ... 4 ans : je suis passé à d'autres firewalls où cette gestion était différente ... J'ai oublié quelque chose ... Mea culpa !)
Au delà du NAT (Port Forward ou Outbound voire 1-to-1), il est préférable, en effet, que le pfSense réponde sur les 5 adresses disponibles d'un réseau /29. (Votre test était bon !) (en fait il faut que pfSense répond aux requêtes ARP venant de la LiveBox : ARP = qui a l'adresse X ?)
Pour cela, il faut créer 4 ip virtuelles de type 'IP Alias' pour l'interface WAN dans Firewall > Virtuel IPs selon la doc https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses.html (entrer les adresses avec /32).
Je suggère de créer aussi un simple alias pour chacune des ip publiques dans Firewall > Aliases : de 'ip153' à 'ip157'. Par la suite, au lieu d'utiliser 'WAN Address' vous pourrez utilisez 'ip153'. (entrer les adresses sans /)
Le reste est identique :
- soit Port Forward + NAT Outbound
- soit NAT 1-to-1 + règles dans onglet WAN
(perso, je n'ai utilisé que Port Forward et NAT Outbound pour des sites allant d'une ip publique à un /29 voire un /29 plus un /28, il faut de gros besoin pour autant d'ip ...)
La doc sur le NAT est https://docs.netgate.com/pfsense/en/latest/nat/index.html
Une fois les alias et IPAlias créés,
je préconise d'ajouter une règle dans l'onglet WAN pour accepter 'ICMP/echo request' à destination de chacune des 'ipxxx', afin de tester, par ping, de l'extérieur que pfSense répond sur chacune des 5 ip publiques,
vous pouvez, sans risque, tester le changement d'ip de sortie pour les trafic http/https par ajout des règles dans NAT Outbound :
- il faut sélectionner 'Hybrid Outbound' puis Save + Apply (pour activer les règles spécifiques en sus des automatiques),
- et ajouter dans 'Mappings' les règles spécifiques (puis Save + Apply)
Ces 2 opérations permettent de réaliser des tests qui vous rassureront.
Concernant le NAT,
- avec le NAT 1-to-1, il faut déclarer l'ip publique choisie et l'associer à l'ip interne (cf doc); ensuite il faut créer des règles dans l'onglet WAN pour chaque port autorisé (je n'ai pas testé),
- avec le Port Forward + NAT Outbound, il faut à la fois une règle Port Forward et une règle de NAT Outbound spécifique, pour un port autorisé (j'ai testé).
-
Oui, merci, entretemps je suis allé voir le forum US sur le Multiwan où il y a 2 ou 3 cas qui ressemblent au mien et effectivement il est question des Alias.
J'ai navigué jusqu'à la page de la doc que vous citez et j'ai lu rapidement avant de partir, ça nécessite que je me penche sur le sujet.Et donc ça répond à mon interrogation, pour qu'il y ait une réponse sur ces multiples adresses IP publiques il faut qu'une interface réponde sur ces adresses.
J'ai fait le parallèle avec un serveur IIS que j'avais installé un jour et sur lequel j'avais hébergé plusieurs sites Web qui étaient sur des adresses IP différentes.
Sur Windows dans les propriétés d'une interface réseau on peut indiquer plusieurs adresses IP, les Alias semblent permettre la même chose.Merci de l'aide, je reviendrai dire ce que mes essais ont donné.
Pascal
-
Bonjour,
J'ai donc créé les IP virtuelles et les alias (au passage, je ne connaissais pas cette notion d'alias dans pfSense qui s'avère bien pratique pour désigner des machines de mon LAN, car en cas de changement d'IP de ces dernières il est plus facile de modifier l'alias que d'aller à la recherche de tous les endroits où on a mis l'IP directe...).
Mon pfSense répond maintenant aux pings envoyés sur toutes les IP publiques qui m'ont été attribuées.L'utilisation de pfSense pour passer le trafic entrant à mon PABX fonctionne parfaitement, je n'ai eu aucun problème depuis la mise en service en novembre.
In fine, mon pfsense me sert maintenant pour :
- donner l'accès à Internet à mes utilisateurs présents sur le LAN
- connecter les roadwarriors à mon LAN avec OpenVPN (3 à 10 connexions simultanées max)
- établir un tunnel IPSec permanent avec notre bureau secondaire
- publier mon DAG Exchange sur Internet
- publier un serveur FTP
Le tout avec une consommation des ressources CPU, RAM, disque quasi nulle en permanence.
J'ai comme l'impression qu'une configuration bien moins puissante aurait suffit...
Là j'ai : CPU Intel Core i5-10500K @ 4,10 Ghz, 16 Go RAM PC4-24000, SSD 500 Go 980 PRO, 1 carte réseau Intel 4 ports I350, 1 carte réseau Intel Gigabit, 1 carte réseau Realtek intégrée
J'ai fait des tests de débit, côté LAN et côté WAN, ça ne semble pas être différent, les retours utilisateurs sont excellents.Maintenant j'ai 2 chantiers, je dois réussir à utiliser un reverse-proxy pour ne pas brancher mon DAG Exchange directement sur Internet (enfin les flux SMTP sont protégés par mon FAI) et puis compte-tenu du fait que toutes nos coms passent maintenant par ce pfSense (Internet, mails, FTP, téléphonie...) il faudrait que je m'intéresse à la HA parce que si le boitier tombe en rade...
Pascal.
-
Cela fait plaisir de voir un retour comme celui !
En sus, les quelques conseils, issus d'une expérience pratique, sont remontés comme bons ce qui prouvent qu'ils sont et judicieux et utiles. Pour les alias, j'encourage à utiliser une 'norme' de nommage : ipxxx pour les ip sur WAN, srvxxx pour les serveurs, portxxx pour préciser un port spécifique, ... cela facilite la lecture des règles ...Un firewall (sans packages inutiles) ne demande que peu de ressources : regardez les caractéristiques des appliances proposées par Netgate ... (elles ne sont pas si chères mais vous pouvez trouver aussi des alternatives ...)
Par contre, il est judicieux de créer les 'proxies' qui vont bien autour du firewall.
Avec un serveur Exchange, il est utile (indispensable ?) de mettre en oeuvre :
- un relais mail (pour smtp) : par exemple un simple Postfix, j'encourage à essayer Proxmox Mail Gateway qui fera du filtrage antispam
- un reverse proxy (pour le trafic http/https) : par exemple un Squid ou un Apache/Nginx
-
@jdh oui le proxy c'est mon prochain chantier car actuellement la sécurité repose sur la confiance que j'ai dans mon opérateur.
J'avais installé HAProxy il y a quelques temps déjà mais je n'ai pas encore toutes les infos nécessaires à son paramétrage.La HA me semble aussi importante à mettre en place pour les raisons que j'ai évoquées.
Pour le choix de l'assemblage du matériel, j'ai choisi cette voie car je maitrise depuis longtemps et je voulais une souplesse à tous les niveaux, extension de la RAM, ajout de cartes réseau, avec une appliance je ne sais pas si j'aurai la même liberté.
Pascal
-