migration ipcop vers pfsense

[elkabore]

Bonjour,
je voudrais remplacer mon ancien ipcop 1.4.21 par pfsense 2.0-RC1
Mon schéma réseau est le suivant:
LAN: 10.10.1.0/24
DMZ: 10.10.3.0/24
WAN: 196.x.x.218/29

J'ai 2 serveurs dans la DMZ: un pour le mail et un autre pour le web (10.10.3.4/24 et 10.10.3.5/24)
La configuration que j'ai côté ipcop est la suivante:
alias IP: 196.x.x.220/29, 196.x.x.222/29
Serveur DNS FAI: 206.x.x.195

Sur ipcop ma configuration coté transfert de port est la suivante:
TCP 196.x.x.220 : 53(DOMAIN) => 10.10.3.4 : 53(DOMAIN)
UDP 196.x.x.220 : 53(DOMAIN) => 10.10.3.4 : 53(DOMAIN)
TCP 196.x.x.220 : 25(SMTP) => 10.10.3.4 : 25(SMTP)
TCP 196.x.x.220 : 80(HTTP) => 10.10.3.4 : 80(HTTP)
TCP 196.x.x.220 : 110(POP3) => 10.10.3.4 : 110(POP3)
TCP 196.x.x.220 : 143(IMAP) => 10.10.3.4 : 143(IMAP)
TCP 196.x.x.220 : 465(URD) => 10.10.3.4 : 465(URD)
TCP 196.x.x.220 : 993(IMAPS) => 10.10.3.4 : 993(IMAPS)
TCP 196.x.x.220 : 995(POP3S) => 10.10.3.4 : 995(POP3S)
TCP 196.x.x.220 : 5262 => 10.10.3.4 : 5262
TCP 196.x.x.220 : 5222 => 10.10.3.4 : 5222
TCP 196.x.x.222 : 80(HTTP) => 10.10.3.5 : 8080
TCP 196.x.x.220 : 22(SSH) => 10.10.3.4 : 22(SSH)
TCP 196.x.x.222 :443(HTTPS) => 10.10.3.5 : 8443


Ma configuration pfsense est la suivante:
- virtuals IP de type other:
196.x.x.220 et 196.x.x.222

-Aliases:
portMail 25, 110, 143, 993, 995, 5222, 5262 mail port
portWeb 80 port web mail
srvMail 10.10.3.4 serveur de mail
srvWeb2 10.10.3.5 server web

- Les rules
LAN: TCP LAN net * srvMail portMail * none
UDP LAN net * 206.82.130.195 53 (DNS) * none
TCP LAN net * * 80 (HTTP) * none
TCP LAN net * * 443 (HTTPS) * none
TCP LAN net * srvWeb2 portWeb2 * none

WAN: TCP * * srvMail portMail * none
TCP * * srvWeb2 portWeb2 * none

DMZ: je sais pas quelles règles il faut mettre pour autoriser l'accès au serveur de mail et web en interne et en externe

Les virtuals IP adresses definies ne sont pas accessibles de l'extérieur et en interne
J'ai également un routeur cisco entre mon pfsense et la connexion internet
merci pour l'aide

[jdh]

NB: masquer les adresses publiques !

Je lis l'adresse publique WAN 196.x.x.216/29
Ceci est une adresse de réseau ! cf http://www.faidherbe.org/tutoriel/calculs.php

196.x.x.216 : adresse du réseau
196.x.x.217 : (première) adresse ip utile
196.x.x.218 : (deuxième) adresse ip utile
196.x.x.219 : adresse ip utile
196.x.x.220 : adresse ip utile
196.x.x.221 : adresse ip utile
196.x.x.222 : (dernière) adresse ip utile
196.x.x.223 : adresse de broadcast réseau

L'adresse ip WAN à choisir n'est donc pas .216 mais sans doute .217.

NB : Il est probable que le routeur utilise une de ces adresses (et qu'il est donc la passerelle).

Sauf besoin spécifique, il serait préférable d'utiliser la version 1.2.3 au lieu de 2.0-RC1.

Je pense inutile les renvois de 53/tcp et 53/udp : vous n'êtes pas serveur DNS !
Je suis circonspect sur les ports 110 (pop3), 143 (imap) et leur déclinaison ...s : usuellement on préfère un accès vpn puis accès aux ports par les clients. Il est de plus étonnant de ne pas avoir choisi un accès unique normalement imap.
Le port 25/tcp suppose que vous recevez les mails : le serveur mail (relais mail ?) doit être sécurisé au minimum contre l'open-relay.

Utiliser des alias pour 2 serveurs est inutile, de plus cela oblige à considérer (faire) le "manual outbound".

Le trafic vers les serveurs en DMZ s'effectue via une règle NAT et une règle dans Rules > WAN.
(Avec pfSense 1.2.3, la règle est créé à la création du NAT mais les modifs ne sont pas synchronisées, alors que c'est le cas avec 2.0-RC1)

Attention à bien comprendre que le filtrage dans pfSense se comprend par interface d'arrivée du trafic !

L'utilisation d'alias (et d'une norme de nommage) est à chaudement recommander ! Et vous l'avez compris !
(ipxxx pour les ip virtuelles, portxxx pour les ports, srvxxx pour les serveurs, ...)

(Il reste quelques règles un peu laxistes comme autoriser le LAN à accéder au serveur DNS : seul le serveur DNS interne devrait être autorisé).


Sinon, bravo pour votre présentation, un exemple pour un premier fil ! Je ne suis pas inquiet : vous allez assurer et votre chef sera content !
(Si seulement tout le monde faisait cet effort de présentation !!)

[elkabore]

Bonjour,
merci pour l'aide.
Effectivement une erreur s'est glissée dans la description des adresses de mes interface la WAN a 196.x.x.218 et comme gateway 196.x.x.217

J'ai toujours pas la réponse concernant mes virtuals IP adresses non accessible par ping et les règles côté DMZ

J'ai maintenu l'utilisation des virtuals IP adresses car il sur l'ancien IPCOP il ya des VPN construits avec ces alias IP (196.x.x.220 et 196.x.x.222) d'où la nécessité pour moi d'utiliser des virtuals IP adresse

[jdh]

Concernant les virtual ip, le type n'est pas précisé !

cf http://doc.pfsense.org/index.php/What_a ... dresses%3F
(c'était facile à trouver : g + "pfsense ip virtual" = 1er lien !)

[elkabore]

Concernant les virtual ip, le type n'est pas précisé !
J'ai précisé le type dans le message; ce sont des virtuals IP addresses de type other

cf http://doc.pfsense.org/index.php/What_a ... dresses%3F
(c'était facile à trouver : g + "pfsense ip virtual" = 1er lien !)

[elkabore]

J'ai précisé le type dans le message; ce sont des virtuals IP addresses de type other

[jdh]

Exact, je n'ai pas vu ! (encore une fois, bonne présentation !)

Avec pfSense 2.0-RC1, j'utilise
- des ip virtual de type "IP Alias" qui servent pour les transferts de ports (NAT),
- une règle sur l'interface WAN avec accept icmp/echo sur "WAN Net" (et non seulement "WAN Address").
Et on peut pinguer ces dites adresses.

Avec pfSense 1.2.3, je n'ai pas cette problématique : utilisation d'une seule adresse pour tout !

Cela dit, ce sera jamais que le firewall pfSense qui répondra au ping, pas le serveur réel (sauf à faire un NAT du icmp).
Donc le ping de l'adresse usuelle du firewall suffit AMHA.