Routage multi wan, multi vpn avec PFSENSE

ccnet

Il y a un point qui ne parait pas dans vos schémas. Je m'explique. Vous utilisez deux interfaces de Pfsense, en plus de lan, pour vos interconnexions. L'une d'elles est probablement interface wan.Par défaut Pfsense translate tout le trafic à destination du wan lors de la sortie par cette interface, ce qui n'est pas le cas pour les interfaces opt. Or nous ne savons pas si le MPLS utilise wan ou une interface opt. Avez vous considéré cela ?

zoummuoz

Bonjour,
Effectivement, le MPLS est bien sur le 192.168.100.X qui est le WAN de PFSENSE.
J'ai bien concidéré cela, et je montre dans mon post que lorsque j'utilise un service redirigé sur un lien VPN, il part bien par ce lien (qui n'est pas forcement le MPLS) arrive bien sur le site distant, repart bien par le bon lien et … se perd ...

ccnet

ok c'est un point éclairci maintenant. Vous savez à quel endroit il se perd ? En sortie du MPLS sur le chemin du retour ?

zoummuoz

Lors du retour, après passage a travers le pfsense distant, sur les routeurs ou les vpn's, je les vois bien sortir sur le reseau VPN, mais ensuite je n'ai aucun moyen de voir ce qui se passe sur les linksys (ai essayé du syslog, mais il ne remonte que les traces du firewall …

Ils partent de mon PC, traversent PFSENSE (packet capture)
10:18:57.685294 00:1b:21:9e:d7:a1 > 00:16:b6:4c:8b:ea, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 40216, offset 0, flags [none], proto ICMP (1), length 60)
16.1.7.240 > 172.31.100.248: ICMP echo request, id 512, seq 18255, length 40

prennent bien le bon VPN, arrivent sur l'autre PFSENSE (packet capture)
10:21:01.083968 1c:17:d3:72:df:53 > 00:16:e6:f6:5a:a2, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 122, id 41004, offset 0, flags [none], proto ICMP (1), length 60)
16.1.7.240 > 172.31.100.248: ICMP echo reply, id 7320, seq 24253, length 40

arrivent sur la machine destination, reparte de la machine, retraversent le PFSENSE distant (packet capture)
10:22:01.061753 00:16:b6:4c:8b:ea > 00:1b:21:9e:d7:a1, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 126, id 1970, offset 0, flags [none], proto ICMP (1), length 60)
172.31.100.248 > 16.1.7.240: ICMP echo request, id 7340, seq 24265, length 40

Puis se perdent -> ils ne reviennent jamais sur le PFSENSE d’origine …

zoummuoz

Bon … j'ai relu et testé votre idée d'interface par defaut.

J'ai mis un des routeurs VPN comme gateway par defaut sur le pfsense distant -> ca passe !!!!!! MAIS QUE DANS UN SENS (du local vers le distant)

Ceci marche :
local ICMP -> PFSENSE gateway par default comme on veut -> regle de routage ICMP pour VPN1 -> PFSENSE gateway default routeur VPN1 -> machine distante ...
Mais du distant vers le local -> nada ...

Le pfsense local a comme gateway par default un routeur situé sur la meme plage IP que les routeurs VPN

MAIS :
Je ne m'explique pas cet état de fait ...
Le MPLS fonctionne alors que ce n'est pas la gateway par default ...
comment faire quelque chose de propre ?

zoummuoz

Bonjour à tous,
ENFIN J'AI TROUVE !

Sur mon interface WAN, je ne sais pourquoi, une gateway par défaut c'est mise en place (routeur MPLS (tiens tiens … le sal....d)).
Si bien que ...
Ceci n'apparaissait pas sur l'interface ...
J'ai fais une machine etst, restoré la machine de prod ... et là c'est apparu !
Une fois cette interface reconfigurée ... cela fonctionne mais une autre incohérence apparait :

Dans Systeme, Routing, Gateway -> si je ne remet pas pas le WAN comme gateway par défaut, (alaos qu'elle est déjà par défaut sur l'interface) mes regles ne fonctionnent pas.
Il suffit que je reselectionne la gateway, que je valide et ... tout part impec !

Avez vous une explication ?
Je pense que je vais réinstaller cette machine avec une base propre ...

ccnet

Je pense que je vais réinstaller cette machine avec une base propre ..

Cela me semble une bonne idée pour voir notamment si l'anomalie qui précède perdure. D'expérience (encore hier) Pfsense ne réagit pas toujours parfaitement lorsque l'on touche aux interfaces (affectation, ip, …). Un redémarrage est en général nécessaire.

zoummuoz

Re bonjour a tous.
Après une reinstall complete : toujours le probleme. Mais j'identifie mieu le pb !

Entre mes deux sites, je veux que les packets utilisant le port 5900 passent sur le VPN2 :
Site 1 : regle : tout ce qui sort en 5900 à destination de l'autre site passe par la gateway VPN2
Site 2 : regle : tout ce qui sort en 5900 à destination de l'autre site passe par la gateway VPN2

J'initie ma connexion VNC, les paquets partent bien via le VPN2 (packet capture), arrivent sur le site distant (packet capture), arrive a la machine destination, qui répond, les packets de réponses repartent, arrive sur le pfsense distant, et là …. prennent la route par défaut ! PLUTOT QUE DE PRENDRE LA MEME ROUTE DE RETOUR QUE CELLE D'ARRIVEE !
J'ai bien essayé de doubler les règles (tout ce qui sort en 5900 et tout ce qui entre en 5900) mais rien ...

Avez vous une piste ? Moi je me désole ...

zoummuoz

up

wazadex

bonjour,

il est possible de forcer la gateway pour chaque rules du firewall, en bas des rules dans "Advanced features".
De base la gateway etant paramétré sur "default" pour chaque rules.

a tester.

zoummuoz

Bonjour et merci de votre réponse …
C'est bien mon soucis, et c'est ce que j'utilise.

Mais dans mon cas, impossible de faire REVENIR le paquet par la meme route ... les packet avec un port 22 par ex, partent bien du site 1 vers le site 2 par la gateway spécifiée dans la rule du site 1, mais reviennent TOUJOURS par la gateway par défaut du site 2 ...
Meme si je met une contre regle sur le site 2 (les packet en provenance du serveur SSH port 22 vers le site 1 passent par telle gateway) ....

Cela fait plus d'un moi que je suis là dessus et ce n'est pas faute de temps a y consacrer ...

Même des collègues a moi, pourtant pas mauvais en réseau, s'y sont cassés les dents ...

Par contre attention : l'ICMP (couche 3) fonctionne dans tous les cas !!! c'est quand on passe a la couche 4 que ca merde ... donc ne pas se fier au ping qui passe et revient sur le bon, lien (via un packet capture par ex).

Merci de votre soutient et avis ou idées (meme les plus dingues ...)

wazadex

la règle est placée au bonne endroit, dans l'onglet ipsec j'imagine ? essayez aussi dans LAN peut être ?
De même la règle est à la bonne position, en haut pour être sur ?

zoummuoz

Wazadex merci de ton suivi.
Oui tout cela a bien évidement été vérifié et testé. Sans succes.
Je n'ai pas de VPN via PFSENSE. Ce sont mes routeurs LINKSYS qui montent les VPN entre les sites.

Ce qui se passe systemeatiquement : les paquets partent bien sur le bon lien en suivant la bonne regle, mais reviennet systematiquement sur la passerelle par défaut du pfsense distant.

POURTANT : plusieurs fois j'ai eu un système FONCTIONNEL. Mais un reboot d'un des deux pfsense (ou des deux) mettait fin à cet état de grâce …. RHAAA !!! Frustrant !

zoummuoz

Bonjour à tous,

Hé oui, je me cramponne a mon topic !!! :P

Mes derniers tests et ma conclusion : (j'ai été aidé car mes compétences on bien sur des limites … hélas)

J'ai fait des tests sur divers protocole, et il s'avère qu'ils ne réagissent pas de la meme facon :

Comme je vous l'ai dit plus haut, ICMP fait partit de ceux ci. Avec un ping, les paquets ICMP sortent bien par l'interface designée sur la règle ICMP du firewall 1 vers le firewall 2, arrive sur le site 2, arrivent à la machine destination, repartent et ... reprennent bien la route spécifiée dans la règle du PFSENSE du site 2 et arrivent enfin a destination en prenant le bon lien VPN de bout en bout ! (pour rappel, pour tout ce qui n'est pas ICMP, le retour se fait TOUJOURS SUR LA PASSERELLE PAR DEFAUT !).

ICMP -> couche 3 max du modele OSI -> pas de pas de FLAG TCP ACK !!!!

En fait : PFSENSE revoit sur l'interface par défaut TOUS LES PAQUETS ACK ! (lorsque qu'un packet traverse une règle PFSENSE et qu'il passe, il est tagué ACK par PFSENSE).

Donc nouvelle question aux utilisateurs avancés : comment résoudre mon problème sachant cela, sans monter une usine a gaz avec des règle flottantes et un proxy pfsense sur chaque site ...

J'espère que mon topic intéresse quelques personnes, car je trouve la solution que je cherche a mettre en place avantageuse ... et suis surpris que personne n'ai eu ce soucis avant moi ...