OpenVPN : comment router les sous-réseaux ?

chris4916

Les routes coté client ont l'air correct.
As-tu regardé coté pfSense dans les logs ?
Lorsque tu accèdes à une machine du site distant, il faut t'assurer que sa route par défaut est bien le serveur VPN (dans ton cas pfSense).
Dans le wizard de pfSense (de mémoire), il te demandes si tu veux ajouter automatiquement les règles de FW. Vérifie celle-ci.

Quelques points (en marge de ta question):

1 - Si le but est d'avoir à la fois une agence et des utilisateurs nomades, il est peut-être intéressant d'avoir 2 config VPN distinctes:

du peer-to-peer pour le site à site (connexion de l'agence)
du mode client - serveur pour les road warriors (les clients nomades)

2 - TUN est définitivement mieux mais pour accéder à du partage Windows, je me demande si tu n'auras pas besoin de TAP ? (encore que l'utilisation du partage, dans ton cas, semble être locale)

3 - attention, lorsque tu lances le client OpenVPN sur la machine Windows, de bien le faire en mode "administrateur" ;)

jdh

Quand on veut avoir des réponses efficaces, on commence par lire https://forum.pfsense.org/index.php?topic=79600.0 et respecter la forme de présentation.

J'ai mis en place un système pfSense dans une entreprise afin de permettre à une autre agence (et éventuels usagers nomades) de se connecter au serveur principal

C'est 2 questions distinctes ! Merci de préciser quel est le véritable sujet : je présume que c'est l'utilisateur nomade.

Côté serveur (entreprise), le WAN de pfSense est une Livebox (avec DMZ). Le LAN est en 192.168.1.0/24
Côté client (nomade), je peux tester depuis un poste Win7 ou un poste Linux, avec un LAN en 192.168.2.0/24
Le tunnel se fait en 10.0.8.0/24

Vous avez compris qu'il y a un serveur et un client, c'est bien.

Concernant le côté serveur, il y a une livebox entre le serveur et Internet, il suffit juste de bien configurer le transfert de port nécessaire au niveau de la livebox, puis on peut l'oublier.
Concernant le côté client, il est essentiel de bien comprendre qu'OpenVpn a besoin de droit 'administrateur' (en Windows et Linux) car il va recevoir une route (la route interne liée au serveur passé par le 'push route' de la config serveur).
Par contre il est parfaitement inutile de s'intéresser à l'adresse locale de ce client : elle ne joue aucun rôle (sauf évidemment est serait accessible directement sur le serveur !)

Il est notable qu'il y a des logs des 2 côtés ! Il est grandement utile de s'y référer (et de les indiquer : la section est prévu dans le formulaire !).

Depuis le client, je ping l'ip LAN de pfSense mais pas de ping sur les machines du LAN qui sont derrière pfSense.

Hélas typique ! (Pinger l'ip LAN du firewall ne donne aucune information.)

Un ping étant constitué de 2 paquets 'icmp', 'echo' en envoi et 'reply' en retour, il faut vérifier le passage de l'un et de l'autre : ce passage peut conrolé sur le pfSense.
Il y a une raison évidente d'échec : le PC du LAN a-t-il bien comme passerelle par défaut le pfSense ?

Mouftik

@chris4916:

Dans le wizard de pfSense (de mémoire), il te demandes si tu veux ajouter automatiquement les règles de FW. Vérifie celle-ci.

Si les routes sont présentes sur le client, je dirais que le souci doit surement tourner autour d'un souci de routage. J'avais essayé de mettre en place un OpenVPN Site-Site, et dans ton schéma, tu as bien ouvert le port UDP pour OpenVPN dans les rules pour le WAN. Mais il faut aussi penser a accepter les connexions dans les rules de OpenVPN, sinon le paquet arrivera bien sur l'interface WAN, sera accepté, mais au moment du routage il sera bloqué par le filtrage de l'interface OpenVPN ( Enfin arrêtez moi si je me trompe :) )

renz0fr

Merci pour vos réponses :)
@jdh : j'avais lu le post sur la présentation, et j'ai pensé que mon dessin apporterait les informations nécessaires.
Si ma demande est confuse et/ou incomplète, veuillez m'excuser.

Je suis utilisateur de gnu/linux depuis 10 ans, les aspects client/serveur, droits, ligne de commande, me sont familiers.
J'ai plus de mal à appréhender les choses sous windows (outils et logs moins accessibles à mes yeux).

@chris4916 : Quel serait l'inconvénient d'utiliser une config nomade pour du site à site ?

@jdh : le PC du LAN obtient son ip depuis le serveur DHCP de pfSense. Mais je n'ai pas ajouté manuellement de push route sur la config OpenVPN pour le moment.

@Mouftik : je vais regarder de ce côté !

jdh

Mais je n'ai pas ajouté manuellement de push route sur la config OpenVPN pour le moment.

Je pense que cela fait normalement de la config serveur (pfSense). En tout état de cause, je mets, perso, toujours un 'push route' dans la config.

Si ma demande est confuse et/ou incomplète, veuillez m'excuser

Je ne demande pas ça : plusieurs bons spécialistes se sont mis d'accord sur ce formulaire qui consistent juste en une liste de sections faciles à remplir. La (petite) contrainte de rédaction facilite la compréhension de tous et gagne du temps.

La demande prête à confusion :

un pc distant (roadwarrior) doit disposer d'OpenVPN dument configuré
un pc d'un réseau distant (site-to-site) bénéficie du lien configuré sur le pfsense local pour accéder à l'autre site : rien d'installé.

NB : il serait assez stupide d'installer OpenVPN sur tous les pc du sites distants.

chris4916

@renz0fr:

@chris4916 : Quel serait l'inconvénient d'utiliser une config nomade pour du site à site ?

Le site-à-site permet au réseau qui se trouve derrière le serveur OpenVPN local d'accéder au réseau derrière le serveur distant. En mode client-serveur, le fonctionnement est un peu différent puisque le réseau "local" est réduit à l'adresse du client.
Ceci a par exemple un impact direct sur les routes annoncées de part et d'autre.

Si tu as l'intention d'accéder au site central depuis plusieurs clients de l'agence, le mode peer-to-peer et LA bonne solution. Si c'est un seul client, il peut bien sûr se connecter en mode roadwarrior.

A noter également que si tu as un mode peer-to-peer connecté, tu peux autoriser (ou pas) les utilisateurs nomades à accéder bien sûr au site central mais également au site de l'agence sans établir de tunnel supplémentaire.

renz0fr

Ok je comprends, et en effet je n'ai qu'un seul poste dans l'agence.
Voici mes règles firewall. Une fois que le tunnel est autorisé, tout passe dedans non ?
J'ai essayé en retirant les 2 premières règles (block private/bogon networks) et cela ne change rien.

Mouftik

@chris4916:

As-tu regardé coté pfSense dans les logs ?

Avec cela je dirais que les logs serait un bon moyen de savoir où le paquet a dû être bloqué …
Peut être en regardant la routing de PFSense aussi, le client semble avoir la bonne, mais ce dernier ne redirige peut être pas sur la bonne gateway.

chris4916

@Mouftik:

@chris4916:

As-tu regardé coté pfSense dans les logs ?

Avec cela je dirais que les logs serait un bon moyen de savoir où le paquet a dû être bloqué …

oui… et non si c'est un problème de route retour.
Cependant, il est facile de vérifier, une fois le tunnel établi, si la route retour est correcte: il suffit sur la machine cible de tenter de joindre le client OpenVPN.
La route par défaut devrait être pfSense et celui-ci devrait rediriger vers le tunnel la route vers le client.

chris4916

Je ne sais pas quelles recherches tu as fait sur le forum mais ce sujet peut éventuellement t'aider.

renz0fr

Merci, ce post est proche de mon cas en effet.
Plutôt que de m'arrêter au ping, j'ai tenté d'utiliser vnc à travers le tunnel et ça fonctionne :

(client) 192.168.2.144 –-> (tunnel) 10.0.8.6 --- 10.0.8.5 (tunnel) --- 192.168.1.1 (pfSense) ---> 192.168.1.11 (vnc server, NAT port 5900 configurée sur pfSense)

Finalement mon tunnel a l'air de fonctionner via la NAT.
Voici un scan fait depuis 192.168.2.144 :

$ nmap 192.168.1.11 -Pn

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-16 15:08 CET
Nmap scan report for 192.168.1.11
Host is up (0.087s latency).
Not shown: 998 filtered ports
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
5900/tcp open  vnc

Devrais-je faire une NAT des ports souhaités plutôt qu'un éventuel routage ?

jdh

Méconnaissance :

(client) 192.168.2.144 –-> (tunnel) 10.0.8.6 --- 10.0.8.5 (tunnel) --- 192.168.1.1 (pfSense) ---> 192.168.1.11

Schéma incorrect !

Le schéma correct est :
(client) 10.0.8.6 <– tunnel --> 10.0.8.5 (pfSense) 192.168.1.1 <-- LAN --> 192.168.1.11
En effet, n'importe quelle machine, avec plusieurs ip, établit une liaison avec une seule ip : celle du réseau emprunté.

Vous n'avez pas lu ce que j'ai écrit : "Par contre il est parfaitement inutile de s'intéresser à l'adresse locale de ce client : elle ne joue aucun rôle"

Le NAT ?
A quoi servirait de réaliser un NAT quelconque ? Grâce au VPN, le pc distant (en roadwarrior) voit le réseau LAN 'en direct' : tout est dit et fait !
Le NAT sert à autre chose !

Je repose la question : pourquoi ne pas mettre de 'push' dans la config serveur ?
C'est la manière normale de config d'un serveur, et le client ajoute automatiquement la route ainsi fournie par le serveur !
Si vous ne mettez pas de 'push route', il faut en ajouter une manuellement sur chaque client !
Il faut penser simple donc la config serveur permet d'automatiser ce qui est nécessaire au client !

renz0fr

Merci pour ces infos.
Je sais à quoi sert une NAT et le principe du VPN. J'ai fait l'erreur de penser que ma NAT avait un rôle ici, mais en effet je peux utiliser VNC à travers le VPN après avoir désactivé la NAT.
C'est que mon VPN fonctionne a priori, mais je n'ai pas accès au partage de fichiers cependant.

Je voudrais bien mettre un push dans la config serveur, mais j'avoue ne pas savoir quoi mettre. Mes essais ont été sans succès, avec bien souvent un message d'erreur sur le client.

chris4916

@renz0fr:

…/... je peux utiliser VNC à travers le VPN après avoir désactivé la NAT.
C'est que mon VPN fonctionne a priori, mais je n'ai pas accès au partage de fichiers cependant.

Je voudrais bien mettre un push dans la config serveur, mais j'avoue ne pas savoir quoi mettre. Mes essais ont été sans succès, avec bien souvent un message d'erreur sur le client.

Donc ton tunnel fonctionne et c'est le ping qui n'est pas autorisé, c'est ça ?
(j'ai un peu du mal à comprendre exactement ce qu'il en est)

Pour le partage: j'avais compris d'un post précédent que le partage était accédé par une machine distante , je veux dire une application tournant sur le site distant accédant un partage sur SON réseau local. Dans ce cas, la machine à l'autre bout du tunnel ne serait pas impactée.
Si au contraire tu veux accéder ua partage depuis la machine qui monte le tunnel, il faut comprendre comment, d'un point de vue réseau, ce partage est accédé.
Il est probablement nécessaire, au niveau du serveur VPN, d'activer "NetiBios over TCP/IP". J'ai des doutes sur l'impact de TAP vs. TUN dans ce cas.

Tu évoques des messages d'erreur coté client: il serait plus efficace de décrire ces messages plutôt qu'uniquement les évoquer ;)

Si tu veux absolument faire un push (mais je ne vois pas pourquoi puisque ta config fonctionne, si je comprends bien), tu peux le faire dans la fenêtre "advanced" avec, par exemple:

push "route 192.168.1.0 255.255.255.0";keepalive 10 60;

si cette route n'existe pas coté client une fois le tunnel établi.

Tu peux également le spécifier (ainsi que décrit dans le sujet que je t'ai indiqué dans mon message précédent) au niveau du "client overrides"

renz0fr

Oui, mon tunnel semble bien fonctionner finalement :)
Je m'étais bêtement arrêté au ping qui ne répondait pas.
Pour le partage, c'est bien la machine distante qui monte le tunnel et qui veut accéder au partage de fichiers qui est côté serveur vpn.
J'ai activé Enable NetBIOS over TCP/IP sans résultat pour le moment.
Mais si la machine distante n'est pas vraiment vue comme locale, je dois configurer le parefeu windows sur le serveur de fichiers ?

En ajoutant le push route que tu m'indiques, voici le message (qui semble indiquer que la route existe déjà) :

Sat Jan 16 16:32:44 2016 TUN/TAP device tun0 opened
Sat Jan 16 16:32:44 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jan 16 16:32:44 2016 /sbin/ip link set dev tun0 up mtu 1500
Sat Jan 16 16:32:44 2016 /sbin/ip addr add dev tun0 local 10.0.8.6 peer 10.0.8.5
RTNETLINK answers: File exists
Sat Jan 16 16:32:44 2016 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Jan 16 16:32:44 2016 Initialization Sequence Completed

Et quand je faisais des tests, je voyais donc cette ligne :

Sat Jan 16 16:32:44 2016 ERROR: Linux route add command failed: external program exited with error status: 2

J'ai aussi accès à l'admin web de pfSense depuis la machine distante, cependant dans ce cas isolé j'ai de nombreux timeouts et le vpn est relancé :

Sat Jan 16 16:24:18 2016 Initialization Sequence Completed
Sat Jan 16 16:26:08 2016 [veto_ServCert] Inactivity timeout (--ping-restart), restarting
Sat Jan 16 16:26:08 2016 SIGUSR1[soft,ping-restart] received, process restarting
Sat Jan 16 16:26:10 2016 UDPv4 link local (bound): [undef]
Sat Jan 16 16:26:10 2016 UDPv4 link remote: [AF_INET]90.*.*.*:1194
Sat Jan 16 16:26:11 2016 [veto_ServCert] Peer Connection Initiated with [AF_INET]90.*.*.*:1194
Sat Jan 16 16:26:14 2016 Preserving previous TUN/TAP instance: tun0
Sat Jan 16 16:26:14 2016 Initialization Sequence Completed

chris4916

distante vs. locale

Je savais que ça n'allait pas être simple. un glossaire s'impose ;D ;D ;D

Locale, c'est dans mon esprit, du point de vue de l’application.
C'est la machine depuis laquelle tu te connectes, donc en l’occurrence le road warrior quand tu accèdes via le VPN, à une application distante.
Pour l’application qui tourne sur le site central, le serveur de fichier est en revanche local.

Une fois ce point établi, relis mes messages précédents car je sens que ta réponse n'est pas claire de ce point de vue.

Il serait plus simple de nommer les sites selon l’extrémité du serveur VPN.

Donc dans ma compréhension, depuis le site "client", tu veux accéder à une application sur le site "serveur", laquelle application accède à un partage sur le même site "serveur". C'est du moins ce que je comprends de ton schéma et donc je ne vois pas pourquoi NetBeui traverserait le tunnel.
As-tu bien redémarré ton tunnel une fois activé Netbiois over TCP/IP ?
Un autre aspect, mais qui n'est directement lié au protocole, est celui de WINS. Lorsque tu dis ne pas arriver à accéder au partage, est-ce que c'est un problème d'accès d'un point de vue SMB ou un problème de résolution de nom parce que tu n'accèdes pas au serveur WINS ? Pour faire le tests, tente un accès au serveur en utilisant sont adresse IP 8)

Pour les time-out, n'hésite pas à tester un tunnel en TCP au lieu de UDP ;)

Pour la route: c'est sans surprise. Tu ne peux pas pousser plusieurs fois la même route d'où mon propos: fait un push route si la route n'existe pas une fois le tunnel établi.

renz0fr

En effet il y a eu confusion sur ces termes ::)
C'est pourquoi j'ai ajouté les notions de client et serveur vpn sur ma réponse… merci de ton indulgence.

Mais le besoin n'est pas exactement celui que tu cites. L'application est une sorte de poste à poste, et le site "client" a bel et bien besoin d'accéder directement au partage SMB du site "serveur".
Je tente tous les accès via les IP donc pas de soucis WINS pour le moment.
J'avais relancé le tunnel après le réglage, mais je pourrai tester à nouveau lundi.

Pour les time-out, j'ai vu dans l'autre post que TCP était une alternative, je vais tester merci !

chris4916

@renz0fr:

Je tente tous les accès via les IP donc pas de soucis WINS pour le moment.

Il serait intéressant alors d'avoir le message d'erreur… une fois que ton tunnel est stable

Pour les time-out, j'ai vu dans l'autre post que TCP était une alternative, je vais tester merci !

UDP est plus rapide mais n'embarque pas, contrairement à TCP, de correction d'erreur, ce qui fait que TCP est moins sujet à déconnexion ;)

renz0fr

Finalement mon tunnel s'avère stable en UDP.
Pour le message d'erreur, j'avais ceci sous linux :

Impossible d'afficher « smb://192.168.1.12/ ».

Erreur : L'obtention de la liste des partages du serveur a échoué : Connexion terminée par expiration du délai d'attente

Suite à quoi j'ai lancé nmap sur l'ip du serveur :

$ nmap -Pn 192.168.1.12

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-18 16:39 CET
Nmap scan report for 192.168.1.12
Host is up (0.44s latency).
Not shown: 995 filtered ports
PORT     STATE SERVICE
1947/tcp open  sentinelsrm
6002/tcp open  X11:2
7001/tcp open  afs3-callback
7002/tcp open  afs3-prserver
8180/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 173.35 seconds

J'ai donc désactivé le pare-feu windows, et relancé nmap :

$ nmap -Pn 192.168.1.12

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-18 16:45 CET
Nmap scan report for 192.168.1.12
Host is up (0.25s latency).
Not shown: 975 closed ports
PORT      STATE    SERVICE
135/tcp   open     msrpc
139/tcp   open     netbios-ssn
445/tcp   open     microsoft-ds
554/tcp   open     rtsp
880/tcp   filtered unknown
1090/tcp  filtered ff-fms
1123/tcp  filtered murray
1947/tcp  open     sentinelsrm
2869/tcp  open     icslap
5357/tcp  open     wsdapi
6002/tcp  open     X11:2
7001/tcp  open     afs3-callback
7002/tcp  open     afs3-prserver
8093/tcp  filtered unknown
8180/tcp  open     unknown
10243/tcp open     unknown
15004/tcp filtered unknown
19315/tcp filtered keyshadow
40911/tcp filtered unknown
49152/tcp open     unknown
49153/tcp open     unknown
49154/tcp open     unknown
49155/tcp open     unknown
49156/tcp open     unknown
49160/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 97.84 seconds

Et cela fonctionne, j'ai accès au partage de fichiers !
Je vais tenter de configurer le pare-feu windows, en ajoutant 135, 139, 445.
C'est plutôt troublant car l'accès au partage était déjà coché dans les paramètres du pare-feu, j'imagine qu'il est autorisé de manière limitée. Je vais creuser ce point et je ferai un retour.

renz0fr

J'ai réussi à mettre en place ce que je voulais, mais j'ai quand même quelques déconnexions.
J'essaie donc de passer le VPN en TCP, tout a l'air de fonctionner, table de routage identique à l'UDP, mais rien ne passe comme si le parefeu bloquait (alors que la règle qui autorise est bien présente).
Où dois je regarder pour voir ce que le parefeu bloque ?