PfSense OpenVPN problème de routage, NAT


  • Bonjour,

    J'ai un problème avec mon pfSense qui est client OpenVPN tun. Le réseau distant est un 10.25.5.0/27. Le réseau du tunnel est 10.25.10.0/24.
    Le réseau local est 10.30.100.0/24.

    Le problème est que quand je ping une machine distante, exemple 10.25.5.5 via ma machine en local qui à par exemple l'adresse 10.30.100.50, je ne reçois pas de réponses à mes ping.

    J'ai fait une règle NAT outbound pour que sur l'interface client OpenVPN la source 10.30.100.0/24 qui veut joindre 10.25.5.0/27 NAT avec l'adresse de l'interface ovpnc1 (10.25.10.6).

    Si je fait un packet capture dans pfSense sur l'interface client OpenVPN ovpnc1 quand je ping, je vois ceci :

    01:35:50.411811 IP 10.25.10.6 (adresse interface client OpenVPN (ovpnc1), NAT) > 10.25.5.5: ICMP echo request, id 17408, seq 695, length 40
    01:35:50.454515 IP 10.25.5.5 > 10.25.10.6: ICMP echo reply, id 17408, seq 695, length 40
    

    Donc le ping passe bien, la machine distante me réponds, mais après, pfSense ne renvoi pas à mon pc 10.30.100.50 ce que l'interface client OpenVPN (ovpnc1) 10.25.10.6 à reçu. Comme si elle ne savait pas ou envoyer le packet à "dénater".

    Si je regarde dans la table NAT de pfSense, le NAT est correct :

    10.30.100.50:1 (mon pc) -> 10.25.10.6:52636 (adresse de l'interface client OpenVPN qui NAT) -> 10.25.5.5 (pc distant que je ping)
    

    Une idée de pourquoi mon packet ne revient pas sur ma machine avec le dénat ?

    Si je fais un ping de mon pc sur l'adresse de l'interface (10.25.10.6) la j'ai bien des réponses par contre…
    Aussi, si je ping 10.25.5.5 depuis l'outil Ping Diagnostic de pfSense, ça ping si je met en source adresse l'interface OpenVPN client ovpnc1. C'est dès qu'on tente de ping depuis une autre interface que je n'ai pas de réponse.

    Dans les règles firewall pour l'interface OpenVPN client (ovpnc1), j'autorise tout.

    Schéma simplifié :

    Une idée d'ou le problème pourrait venir ?
    Merci pour votre aide :)

    Fabien


  • Bonjour,

    Pourrais tu fournir les masque de réseaux associés à ta maquette ?


  • Une idée de pourquoi mon packet ne revient pas sur ma machine avec le dénat ?

    Les routes retour nécessaires sont elles en place ? Au passage je pense que le nat ne sert à rien. Tout devrait se régler avec un routage approprié.


  • @ycuaz:

    Bonjour,

    Pourrais tu fournir les masque de réseaux associés à ta maquette ?

    Hello ycuaz,

    J'ai rajouté les masques aussi sur le schéma

    @ccnet:

    Une idée de pourquoi mon packet ne revient pas sur ma machine avec le dénat ?

    Les routes retour nécessaires sont elles en place ? Au passage je pense que le nat ne sert à rien. Tout devrait se régler avec un routage approprié.

    Hello ccnet,

    La route de retour existe il me semble puisque lors du packet capture, on voit que le packet de retour à l'air de rester bloquer au 10.25.10.6 (adresse interface ovpnc). Pour arriver à destination il aurait encore du continuer son chemin jusqu'à 10.30.100.1 (adresse de l'interface du réseau ou j'ai mon pc) puis 10.30.100.50 (adresse de mon PC). Et pour ca les routes existent. Si je regarde dans "Diagnostics" > "Routes" j'ai bien toutes les routes nécessaires :

    Je pense que le NAT est nécessaire puisque le réseau distant 10.25.5.0/27 ne connait pas les réseaux 10.30.x.x. Il connait juste les deux réseaux 10.25.5.0/27 et 10.25.10.0/24. Pour ça que je NAT avec ce réseau là. Ce n'est pas correct ?

    merci pour vos réponses :-)

    Bonne journée


  • Pour OpenVPN Server et client 'roadwarrior', nul besoin de NAT !

    Pour OpenVPN Site-2-Site, je suis surpris par l'utilisation de NAT : cela n'est pas du tout nécessaire.

    Le premier point est d'avoir des routes installées de chaque côté : utilisation de push route conseillée
    Le deuxième point est de tester par ping et par traceroute (tracert -d sous Windows).


  • @jdh:

    Pour OpenVPN Server et client 'roadwarrior', nul besoin de NAT !

    Pour OpenVPN Site-2-Site, je suis surpris par l'utilisation de NAT : cela n'est pas du tout nécessaire.

    Le premier point est d'avoir des routes installées de chaque côté : utilisation de push route conseillée
    Le deuxième point est de tester par ping et par traceroute (tracert -d sous Windows).

    Bonjour jdh,

    Du côté de la configuration serveur, j'ai 2 push route :

    push "route 10.25.5.0 255.255.255.224"
    push "route 10.25.10.0 255.255.255.0"
    

    Avec ca, le client connait les réseaux distants.
    Mais le serveur lui ne connait pas les routes du réseau qui émet les ping request (10.30.100.0/24). Il y a une possibilité de faire un push route pour le serveur ? Que le client puisse annoncer ses réseaux ?


  • pfSense, en serveur, sait envoyer un "push route" qui sera bien interprété par le client (XP, Seven, …).
    pfSense, en client, sait-il bien interpréter le "push route" ?
    Il ne mange pas de pain de

    • ajouter, à la main, la route vers le serveur OpenVPN (en site-2-site, il n'y a que 2 ip qui communiquent)
    • vérifier pas à pas (ping et traceroute) là où ça coince

  • @jdh:

    pfSense, en serveur, sait envoyer un "push route" qui sera bien interprété par le client (XP, Seven, …).
    pfSense, en client, sait-il bien interpréter le "push route" ?
    Il ne mange pas de pain de

    • ajouter, à la main, la route vers le serveur OpenVPN (en site-2-site, il n'y a que 2 ip qui communiquent)
    • vérifier pas à pas (ping et traceroute) là où ça coince

    J'ai ajouté les routes à la main, mais ça ne change rien (vu qu'elles existent déjà comme montré dans mon screenshot ci-dessus).
    Concernant le ping et traceroute, je l'ai fait dans tout les sens :-( J'ai même précisé ou ça coinçait dans mon premier post.
    La j'ai enlever ma règle NAT outbound, et si je fait un packet capture sur mon interface ovpnc1, j'ai ceci :

    18:01:47.015553 IP 10.30.100.50 > 10.25.5.5: ICMP echo request, id 1, seq 37, length 40
    

    Mais forcément pas de réponse car 10.25.5.5 ne connait pas le réseau 10.30.100.0/24. Comment faire pour que les machines distantes sachent ou répondre si je n'utilise pas de NAT ? C'est la que quelque chose m'échappe…
    10.25.5.5 veut répondre au ping de 10.30.100.50, mais cette machine ne connait pas ce réseau.. Donc la machine va interroger va envoyer la réponse ping à la passerelle par défaut qui est un autre router qui ne connait pas ce réseau non plus.


  • 10.25.5.5 veut répondre au ping de 10.30.100.50, mais cette machine ne connait pas ce réseau.. Donc la machine va interroger va envoyer la réponse ping à la passerelle par défaut qui est un autre router qui ne connait pas ce réseau non plus.

    La machine n'interroge pas la passerelle par défaut. Elle lui envoie les paquets parce que justement elle ne possède pas d'autre indication. Je n'ai pas vraiment le temps de décortiquer votre histoire. Votre diag me semble bon mais il faut en tirer les conclusions. Vite fait il me semble que 10.25.5.5 devrait ne pas employer la passerelle par défaut mais l'interface de votre tunnel pour répondre. Donc une route qui passe par 10.25.10.1 pour atteindre 10.30.100.0/24. Ceci sans nat ajouté. J'ai regardé ca vite fait, je n'ai pas beaucoup  de temps.


  • @ccnet:

    La machine n'interroge pas la passerelle par défaut. Elle lui envoie les paquets parce que justement elle ne possède pas d'autres indication. Je n'ai pas vraiment le temps de décortiquer votre histoire. Votre diag me semble bon mais il faut en tirer les conclusions. Vite fait il me semble que 10.25.5.5 devrait ne pas employer la passerelle par défaut mais l'interface de votre tunnel pour répondre. Donc une route qui passe par 10.25.10.1 pour atteindre 10.30.100.0/24. Ceci sans nat ajouté. J'ai regardé ca vite fait, je n'ai pas beaucoup  de temps.

    Effectivement dans un routage logique on devrait avoir 10.30.100.50 > 10.25.10.1 > 10.25.5.5.

    J'ai enlever la règle NAT que j'avais mise et maintenant, mon ping va encore moins loin qu'avant si j'analyse avec un packet capture.

    Si je ping et que je lance un packet capture sur mon interface du réseau 10.30.100.50 j'ai bien ceci :

    10:15:57.092025 IP 10.30.100.50 > 10.25.5.5: ICMP echo request, id 1, seq 16, length 40
    
    

    Par contre si je fait un packet capture sur l'interface ovpnc1, la je n'ai déjà plus rien. Comme si il ne trouvais pas la route de 10.25.5.5.

    Pourtant si je regarde dans Diagnostics > Route, j'ai bien ma route. Mais qui à comme passerelle 10.25.10.5 :

    Je ne comprends pas pourquoi il n'arrive pas à aller plus loin. Pourquoi le ping bloque alors que la route existe ? Une idée ? :)

    Merci


  • Est ce bien utile d'avoir ces routes ?

    • la route 10.25.10.1/32 est déjà incluse dans 10.25.10.0/24 !

    La seule route utile est le réseau distant via l'ip (tunnel) du firewall distant.

    ex :
    zone G : lan = 192.168.55.0/24; fw lan 192.168.55.254/24; fw tunnel 10.0.8.2
    zone D : lan = 192.168.133.0/24; fw lan 192.168.133.1/24; fw tunnel 10.0.8.4

    de G vers D, la route est 192.168.133.0/24 via 10.0.8.4
    de D vers G, la route est 192.168.55.0/24 via 10.0.8.2

    à adapter …


  • @jdh:

    Est ce bien utile d'avoir ces routes ?

    • la route 10.25.10.1/32 est déjà incluse dans 10.25.10.0/24 !

    La seule route utile est le réseau distant via l'ip (tunnel) du firewall distant.

    ex :
    zone G : lan = 192.168.55.0/24; fw lan 192.168.55.254/24; fw tunnel 10.0.8.2
    zone D : lan = 192.168.133.0/24; fw lan 192.168.133.1/24; fw tunnel 10.0.8.4

    de G vers D, la route est 192.168.133.0/24 via 10.0.8.4
    de D vers G, la route est 192.168.55.0/24 via 10.0.8.2

    à adapter …

    Je n'ai jamais créer une seule de ces routes… C'est pfSense et OpenVPN qui m'ont pondus ces routes... Je voudrais bien supprimer les routes plus précises, mais comment ? Je ne vois pas de moyens de suppression.

    Je ne vois pas ce que je peux adapter ne sachant pas modifier ces routes générées toutes seules


  • Je n'ai jamais créer une seule de ces routes…

    Donc les routes se créent par réception des "push route" !

    Je pense qu'il y a trop de route créées : 3 réseaux semblent accessibles !


  • @jdh:

    [Donc les routes se créent par réception des "push route" !

    Je pense qu'il y a trop de route créées : 3 réseaux semblent accessibles !
    [/quote]

    J'ai un peu fait le ménage, notamment dans la configuration client OpenVPN et maintenant je n'ai plus que ceci :

    10.25.5.0/27	10.25.10.5	UGS	0	44	1500	ovpnc1	 
    10.25.10.0/24	10.25.10.5	UGS	0	10	1500	ovpnc1	 
    10.25.10.1/32	10.25.10.5	UGS	0	0	1500	ovpnc1	 	 
    10.25.10.10	link#16	UHS	0	0	16384	lo0	 
    

    Mais mon problème reste identique quand au ping. Ça cale toujours au même endroit


  • Cela fait toujours 3 réseaux accessibles via cette gateway ! Ce sont les push route qu'il faut nettoyer !

    Moi, je configurerai le serveur sans aucune push route, puis "connexion" puis vérif des routes côté client, …


  • @jdh:

    Cela fait toujours 3 réseaux accessibles via cette gateway ! Ce sont les push route qu'il faut nettoyer !

    Moi, je configurerai le serveur sans aucune push route, puis "connexion" puis vérif des routes côté client, …

    Ok j'ai mis un route-nopull dans la config client et à présent je n'ai plus qu'une GW allant vers le réseau distant :

    10.25.5.0/27	10.25.10.5	UGS	0	0	1500	ovpnc1	 
    10.25.10.5	link#16	UH	0	27	1500	ovpnc1	 
    10.25.10.6	link#16	UHS	0	0	16384	lo0	 
    

    De ce côté la ça parait propre. Par contre mon ping de 10.30.100.50 vers 10.25.5.5 reste bloqué après la sortie de la première interface LAN (réseau 10.30.100.50/24) :

    14:48:35.115193 IP 10.30.100.50 > 10.25.5.28: ICMP echo request, id 1, seq 30, length 40
    

    Si je fais un packet capture sur l'interface ovpnc1, je ne vois rien arriver. Ni de ping request ni de ping reply. Comme si il ne savait pas quelle route prendre… Pourtant comme montré ci-dessus, il sait que pour accéder au réseau 10.25.5.0/27 il doit passer par 10.25.10.5. Tiens au fait pourquoi il veut utiliser 10.25.10.5 comme GW ? Ce n'est pas 10.25.10.1 qu'il faudrait ?


  • Côté client, vous refusez les routes, pourquoi pas, mais au moins ajouter la seule bonne route nécessaire sinon pfSense ne sait pas par où passer !

    Si je fais un packet capture sur l'interface ovpnc1, je ne vois rien arriver. Ni de ping request ni de ping reply. Comme si il ne savait pas quelle route prendre… Pourtant comme montré ci-dessus, il sait que pour accéder au réseau 10.25.5.0/27 il doit passer par 10.25.10.5. Tiens au fait pourquoi il veut utiliser 10.25.10.5 comme GW ? Ce n'est pas 10.25.10.1 qu'il faudrait ?

    La bonne passerelle est, forcément, l'ip tunnel du côté opposé : 10.25.10.5 !

    Attention, il est bien sûr nécessaire d'avoir des Firewall > Rules nécessaires dans l'onglet voulu (OpenVPN) !


  • @jdh:

    Côté client, vous refusez les routes, pourquoi pas, mais au moins ajouter la seule bonne route nécessaire sinon pfSense ne sait pas par où passer !

    La bonne passerelle est, forcément, l'ip tunnel du côté opposé : 10.25.10.5 !

    Attention, il est bien sûr nécessaire d'avoir des Firewall > Rules nécessaires dans l'onglet voulu (OpenVPN) !

    Donc si la bonne GW est 10.25.10.5, je suis bon au niveau des routes avec ce que j'ai montré dans mon post précédent, non ?

    Dans le firewall, pour l'interface OpenVPN, ovpnc1 et LAN, j'autorise tout :

    Sans succès :-\


  • Il faut savoir interpréter la sortie de la commande 'route' (sous BSD) :
    UH -> désigne un Host accessible
    UGS -> désigne un réseau accessible par une Gateway

    Le serveur sait-il bien accéder à une machine de ce réseau (étroit) 10.25.5.0/27 (soit de 10.25.5.1 à 10.25.5.31) ?


  • @jdh:

    Le serveur sait-il bien accéder à une machine de ce réseau (étroit) 10.25.5.0/27 (soit de 10.25.5.1 à 10.25.5.31) ?

    Oui, si je ping depuis l'interface ovpnc1, j'ai bien des réponses aux ping.
    C'est quand je ping depuis une autre interface (comme LAN) que ça ne fonctionne plus