VPN IPsec : interface, routage et filtrage
-
Il ya visiblement un problème sur votre installation car vous ne devriez en aucun cas devoir vous connecter pour créer quoi que ce soit sur le firewall.
Ensuite vous ne devriez en aucun cas manipuler ipfw, celui-ci est par défaut désactivé et ne se retrouve actif que lorsqu'on utilise le portail captif. Le filtre de paquet de pfsense c'est pf. Les règles que vous voyez grace a pfctl sont normales ce sont les regles par defaut de pfsense.
Quoi qu'il en soit un principe de base, vous ne devez rien avoir a modifier en ssh.Réinstallez un snapshot plus récent (si possible) ou réinstallez car la vous avez un dysfonctionnement que je n'ai encore jamais rencontré (et j'ai quelques dizaines de concentrateurs IPSEC qui concentrent des dizaines de tunnels).
-
Merci pour votre réponse.
Je vais essayer de réinstaller une version stable (1.2.2), ou effectivement un snapshot plus récent.
Concernant le problème de routage, c'est assez surprenant car avant d'installer pfSense nous nous servions d'un vieux NetASQ F50-2 (qui utilise du FreeBSD4.4 "en dessous", avec racoon pour l'IPSec) et le comportement était similaire (tunnel établi, ping dans un seul sens).
Nous utilisons une Livebox Pro comme routeur, le NetASQ et maintenant pfSense sont connectés directement dessus (ip de la livebox comme passerelle).
Si je ne crée pas les interfaces manuellement, j'obtiens un message du type "traffic prohibited by filter", d'une adresse IP 83….. qui est visiblement une machine oleane/orange nommée "TRANSIT-VPN".
Tout se passe en fait comme si les paquets à destination des sous-réseaux privés distants (e.g. 10.1.1.0) sortaient directement via l'interface WAN sans transiter par le tunnel IPSec (d'ou l'obligation de créer la route manuellement après paramétrage des interfaces gifX).
Dans le cas de vos tunnels IPSec, faites-vous dialoguer différentes implémentations ou s'agit-il de pfSense à chaque extrémité ?
En effet, je n'ai jamais rencontré ce problème en faisant par exemple du site-to-site avec deux boitiers NetASQ de chaque coté, et le responsable des sites distants ne l'a lui non plus jamais rencontré, mais il utilise du freeswan de chaque coté. -
Je viens de lire cette page : http://www.freebsd.org/doc/en/books/handbook/ipsec.html .
Puisque pfSense est basé sur FreeBSD, son comportement ne devrait-il pas être similaire à celui décrit ci-dessus ?
Et dans ce cas, pourquoi les interfaces gifX ne sont-elles pas créées ? -
J'ai des tunnels pfsense<->freeswan (sans inteface GIF !), pfsense<->Cisco, pfsense<->juniper,pfsense<->arkoon …. tout est ok et se deroule sans aucun soucis.
Les subnets sur chaque site sont bien des subnets différents ?
Je pense avoir mal saisi depuis le début ce que vous tentez de faire mais ne seriez vous pas en train d'essayer de router des subnet via vos tunnels IPSEC ? D'où votre volonté de monter des tunnel GIF par dessus le tunel primaire.
Si c'est le cas alors en effet cela ne marchera pas, il faut faire un tunnel ipsec par réseau présent sur l'autre site. Pour l'instant pfsense fonctionne comme cela et à mon avis pour longtemps car c'est la façon standard de fonctionner de tous les principaux acteurs du monde IPSEC (pour optimiser les MTU et s'affranchir de tunnelisation). -
Hum, à priori ce que j'essaye de configurer correspond à une situation relativement classique :
subnet local subnet gateway ip publique Oleane ip publique Site distant subnet gateway subnet distant
172.17.0.0/16 –--> 172.17.20.254----->81.252.X.X---------------------------------80.124.X.X<--------------10.10.10.254<------------10.10.10.0/24Sans effectuer les manipulations précitées, et que j'affiche la liste des routes, aucune route n'est créée vers le sous-réseau 10.10.10.0/24, et donc les paquets sortent par l'interface publique (81.252.X.X).
-
Il y a donc vraiment quelque chose de pas normal.
Cela devrait fonctionner directement… normalement monter un tunnel ipsec avec pfsense ca se fait en moins de 5 min.
Je n'arrive pas a comprendre ou le problème se situe car selon le diagramme donné c'est du classic...
-
Mon problème a été résolu, au moyen des opérations suivantes :
- suppression des interfaces gif0 et gif1 (via ssh).
- ajout des routes statiques vers les sous-réseaux distants (via l'interface web).
- suppression de la règle de filtrage "any to any" dans les règles de l'interface IPSec (enc0), et ajout de règles en spécifiant comme source les sous-réseaux distants (e.g "10.10.10.0/24 to any"), aussi via l'interface web.
C'est ce dernier point qui posait principalement souci.
Apparemment la règle initiale était (peut-être ?) trop laxiste et c'était la règle "default deny to all" qui s'appliquait.
En tout cas, merci pour les suggestions.
-
suppression des interfaces GIF : OK
Ajout de routes static vers les sous réseaux distants : PAS NORMAL => qu'avez vous mis en gateway? pfsense lui même ? si c'est le cas alors il doit générer de l'ICMP redirect a chaque paquet venant du LAN a destination du site distant…le drame (faites un ping depuis une machine linux de votre LAN vers un site distant, il y a de grande chance de voir du redirect de pfsense sur lui même).
Suppression du any to any sur IPSEC: aucune incidence, vous autorisiez tout en provenance des sites distants.
Je vous rappel le concept fondamental de pfsense (avant la 2.0 ;) ) le trafic est filtré en entrée sur l'interface par ou il rentre. Cela donne donc:- une règle sur l'interface IPSEC filtre ce qui arrive dans le tunnel, en provenance du site distant et a destination des réseau connus localement et déclaré dans l'association de sécurité.
- pour autoriser à destination des sites distant il faut placer une règle sur la carte où rentrera le trafic, qui est généralement l'interface LAN.
Dernier conseil, si vous comptez démarrer une production avec ce firewall, sauvegardez votre configuration, réinstaller la machine et restaurez votre configuration. Vous serez sûr de ne laisser aucune trace de vos actions manuelles.
-
Je dois avouer que c'est assez étrange…
Si je supprime les routes statiques, et que, depuis la machine pfSense, connecté en ssh, je ping, disons, la passerelle d'un des sous-réseaux distants (10.10.10.254), j'obtiens le message "prohibited by filter" en provenance d'un routeur d'oleane (ip publique 83.X.X.X) rattaché à un ensemble "TRANSIT-VPN". Il semblerait donc que depuis la machine pfSense, les paquets à destination de 10.10.10.0/24 qui devraient sortir via enc0 (l'interface IPSec) sortent en fait par fxp0 (interface publique 82.109.X.X).
J'avoue ne pas avoir, dans cette configuration, pratiqué cette opération depuis un poste dans le sous-réseau local (m'étant dit, "si ça ne pinge pas depuis le firewall, ça ne pingera pas non plus depuis un poste client", raisonnement qui est peut-être erroné).
Dans le cas contraire, (c-à-d en conservant les routes, et j'ai effectivement indiqué l'adresse IP privée rattachée à l'interface LAN/rl0 en tant que passerelle (suite à un message vu ailleurs)), en pingant depuis autre chose qu'un poste Windows, on voit bien de l'ICMP redirect...(Addendum: en me relisant, je me dis que le problème est probablement là : la passerelle par défaut de pfSense est l'ip publique de la Livebox connectée en direct, alors que la passerelle par défaut du LAN est l'adresse rattachée à l'interface LAN/rl0, e.g 172.17.20.254, il est donc logique qu'en pingant 10.10.10.X depuis pfSense, je sorte via la Livebox... Si c'est ça, merci la maïeutique ;) ).
Concernant la règle "any to any" sur l'interface IPSec, celle-ci semblait vraiment ne pas s'appliquer, puisque, alors que cette dernière était active, les postes distants pouvaient uniquement pinger, et que tout le reste du trafic était indiqué comme dropé dans les logs du firewall, par la règle "default deny...".
Je comprends que le trafic en entrée soit filtré par défaut, mais le comportement indiqué ci-dessus a disparu dès lors que j'ai supprimé la règle "any to any" pour la remplacer par une règle "10.10.10.0/24 to any", qui est pourtant plus restrictive que la première.Sur l'interface LAN, il y a une règle par défaut autorisant tout le trafic en provenance de "LAN Subnet", pourquoi alors rajouter une règle autorisant le trafic vers les sous-réseaux distants ?
Je pratiquerai d'autres tests Lundi.
-
En effet j ai oublié de préciser que les tests devaient etre fait depuis un poste client et non depuis pfsense lui même…dans ce cas il faut effectivement une route statique mais a eviter au possible (generalement utilisée lorsque que le DNS forwarder a besoin de remonter vers un dns via ipsec).
Je pars en vacances @plus et bonne chance.
-
Bonjour,
J'ai supprimé les routes statiques, aucun problème depuis les postes clients, et plus d'ICMP redirect :)
Merci et bonne vacances.