PfSense en client OpenVPN, aucun trafic ne passe

[adv]

Bonsoir à tous.

Contexte: Antoine, nouveau sur le forum, pas nouveau dans l'informatique mais connaissances réseaux assez basiques. Utilisation dans ce cas à titre perso. Pas vu de problème similaire dans mes recherches, qui doit être pourtant si simple a résoudre, ce pourquoi je fais appel à vous.

Besoin: A la maison un LAN en 192.168.1.0/24 et un NAS Synology en serveur OpenVPN. Au boulot un pfSense en tant que client OpenVPN, LAN en 192.168.2.0/24.
Je souhaite réaliser un tunnel pour, du LAN boulot arriver à joindre les ressources de la maison.

Fonctionnement OK avec OpenVPN GUI du boulot ! Le serveur Syno me donne une IP en 10.8.0.0/24 et j'arrive à joindre le LAN en 192.168.1.0/24 (une option dans le Synology qui doit ajouter la route "qui va bien"). Donc je suis sur de ma config sur le routeur de la maison (NAT)

Sur pfSense boulot: connexion au VPN OK, IP attribuée 10.8.0.6 mais problème… absolument rien ne passe, même pas un ping vers 10.8.0.5 qui semble être l'adresse IP du Syno.

Schéma:

Boulot: WAN -> pfSense -> LAN 192.168.2.0/24
                                    -> OPT1 192.168.0.0/24

Maison: WAN -> routeur -> LAN 192.168.1.0/24

Connexion au serveur VPN établie ! voir image jointe.
Règle firewall:  interface OpenVPN: laisse passer tout trafic, voir image jointe.
Outbound: je vous mets une copie d'écran, je suis en auto. Je ne sais pas si quelque chose manque en auto... si je dois rajouter quelque chose manuellement...
Routes: j'ai des connaissances basiques mais semble OK !?
Ping: même vers le serveur Open VPN sans succès !

Ce que j'ai testé...
dans la config du client VPN, dans le champs "IPv4 Tunnel Network" j'ai testé 10.8.0.0/24, et vide, car cette condition est vraie : Leave blank if the server is capable of providing addresses to clients. -> c'est le cas, le Synology me donne l'adresse IP dynamiquement 10.8.0.6 !

IPv4 Remote network(s): 192.168.1.0/24 et aussi 192.168.1.0/24,10.8.0.0/24

mais cela ne change pas grand chose à la table de routage, qui semble vraiment d’aplomb !

Une idée ?
Cela semble pourtant si basique, c'est un peu la honte de butter sur une broutille mais mes connaissances ne me permettent pas de résoudre le problème seul.
Suis-je assez clair ?

Merci à ceux qui m'auront lu.

[jdh]

Il n'y a guère de réponses car tout cela est très confus !

Cas 1 : (opérationnel)
Synology (srv OpenVpn) <-> Box <-> Internet <-> Box <-> (Wan) pfSense (LAN) <-> pc client

Le cas est indiqué comme opérationnel : pc client avec Openvpn Gui (donc config).
(Suppose qu'il y a une règle dans LAN pour autoriser la sortie vers ip box Maison pour proto OpenVpn et que la Box maison fait le forward vers le Synology)

Cas 2 : (non opérationnel)
Synology (srv OpenVpn)  <-> Box <-> Internet <-> Box <-> (Wan) pfSense

Le souhait est que pfSense soit client OpenVpn, ce dont il est largement capable.
Mais on ne comprend pas l'intérêt : tout le monde sur le LAN aurait accès ? (stupide)

Il y a surtout une évidence : si pfSense doit être client, il doit être dument configuré avec la même config que le PC client, en particulier les certificats !
Mais sur le sujet, rien, nada.
NB : si pfSense est client, il n'y a aucune règle à ajouter pour WAN, LAN, … car les règles WAN, LAN, ... concernent des flux entrants par ces interfaces.
Sauf bien sûr sur l'interface OpenVPN !!

Cela donne l'impression, qu'il n'y a pas de logique pour coller à un fonctionnement, c'est un peu au petit bonheur, ce qui n'est pas la meilleure des méthodes ...

NB : Vous avez de la chance d'avoir un patron qui vous autorise au boulot à accéder à votre chez vous ...

[adv]

Bonsoir et merci pour l’intérêt que vous portez au problème.

Des fois il faut savoir taper là ou ça fait mal, vous n'avez pas été tendre et je vous en remercie  ;)

Vous résumer parfaitement les deux cas, et pour répondre à la question "tout le monde sur le LAN aurait accès ?" je répond oui c'est bien mon souhait.

Bon alors j'ai avancé…

J'ai quand même vérifié "l'état" du tunnel... ça faisait du flip-flop et malgré le statut connecté en fait il ne l'était pas vraiment (vu dans les logs), la faute à:

il doit être dument configuré avec la même config que le PC client

Après avoir ajouté "comp-lzo" coté client (client OpenVPN sur pfSense) je trouve une connexion stable et j'arrive enfin à pinguer 10.8.0.1 depuis l'interface pfSense ainsi que les adresses en 192.168.1.X et enfin j'arrive à pinguer 10.8.0.6 (IP attribuée au client) depuis le NAS à la maison, youpi ! Là je vous dit merci.  :)

Mais ce n'est pas fini… je me retrouve dans la table de routage avec un 10.8.0.5 qui vient me mettre le bazar ! Je ne comprends pas d'où il vient et dans la conf coté serveur sur le Synology rien ne laisse apparaître cette adresse et le NAS ne la ping même pas !

Même après reboot les routes avec ce 10.8.0.5 réapparaissent… je dois me pencher là dessus ! -> capture de la table de routage dans mon premier post.

Quand aux remarques:

NB : si pfSense est client, il n'y a aucune règle à ajouter pour WAN, LAN, … car les règles WAN, LAN, ... concernent des flux entrants par ces interfaces.
Sauf bien sûr sur l'interface OpenVPN !!

C'est très bien compris et sauf erreur de ma part je n'ai jamais laissé entendre que j'aurai besoin de toucher aux règles de LAN ou WAN  :-
J'ai simplement dit: Règle firewall:  interface OpenVPN: laisse passer tout trafic, voir image jointe.
Pour moi votre explication est déjà acquise.

Cela donne l'impression, qu'il n'y a pas de logique pour coller à un fonctionnement, c'est un peu au petit bonheur, ce qui n'est pas la meilleure des méthodes ...

Objection votre honneur !  :P du tout c'est pour ça que je m'adresse à vous… pour être sur de ce que je fais et que ce soit bien fait.

NB : Vous avez de la chance d'avoir un patron qui vous autorise au boulot à accéder à votre chez vous ...
```dans la mesure où le patron c'est moi…  ;)

Merci, je vosu tiens au courant si j'arrive à piger d'où vient ce 10.8.0.5 !

[jdh]

Vous avez fourni des infos, donc on peut interpreter et mettre en forme de façon lisible, c'est l'espérience. (Y compris de parler du patron !)
J'essaie d'être factuel et précis, je situe les problématiques, la question n'est pas d'être 'tendre' ou 'pas tendre'.

Si une config client est à reproduire, il faut observer que le fichier texte de conf du client est plus lisible que le formulaire web de conf client de pfSense !
Et en particulier les certificats sont à importer puisque la config les sélectionne avec une liste !
Et il y a une palanquée d'options qui doivent être en correspondance.

La suite est de comprendre quoi faire sur pfSense avec ce qui est fourni par le serveur, en l'occurence le 'push route' !
Encore une fois, il faut observer le client sur un PC : il reçoit une ip, une push route, où les voit-on ? et vient, comment les utiliser dans pfsense ?

Pour la règle OpenVpn, pourquoi ne pas en écrire 2 en précisant les sources et destinations (en l'occurence 2 réseaux)

Et là, vous devriez prendre conscience que si la conf client doit être identique, il y a une grande différence entre un PC client et un pfSense client !
Dès que la différence sera bien comprise, il restera à trouver l'astuce pour faire croire au Synology qu'il n'y a qu'un client (j'en ai trop dit).