[RESOLU] pfsense 2 openvpn navigation internet

yob

Sinon, vous n'êtes vraiment pas bavard sur les informations …

Votre copie d'écran nous apprend que vous utilisé une autre version que la version 1.2.3-RELEASE, je suppose la v2 !?(personnellement je ne la connais pas)

Elle nous apprend aussi que des champs bien utile ne sont pas remplie !?

On à aucune information sur le serveur sur lequel la connexion OpenVPN s'établit, pourtant c'est lui qui fourni l'accès au net à vos client !?

On ne connais pas les règles (Rules) utilisé, une p'tite copie d'écran peut nous être utile.

Vous nous ne dite pas si il y a au moins quelque chose qui fonctionne, exemple : ping du réseau hôte !?

Etc.

La copie d'écran confirme que c'est la v2 comme je l'avais indiqué dans le titre, plus précisément il s'agit de la v2 beta4
Le serveur vpn fonctionne correctement car on peux tout à fait s'y connecter et naviguer sur internet avec un client openvpn classique.
En ce qui concerne les rules : une règle autorise tout ce qui proviens du lan d'aller vers le wan. Et bien entendu quand le vpn n'est pas actif tout fonctionne correctement.
Pour ce qui concerne les pings à partir des postes clients le ping est ok vers :
-l'adresse lan de pfsense 192.168.0.12
-l'adresse wan de pfsense
-l'adresse du client vpn pfsense 10.8.0.6

le ping est ko pour n'importe qu'elle adresse wan comme par exemple google.com mais la résolution dns elle fonctionne.

Pour résumer il manque une route / rule pour que les clients puissent accéder au web à travers le vpn.

titofe

…

@yob:

En ce qui concerne les rules : une règle autorise tout ce qui proviens du lan d'aller vers le wan. Et bien entendu quand le vpn n'est pas actif tout fonctionne correctement.

Bien, mais cela nous parle de WAN !?

Donc si on récapitule, un client OpenVPN autre que pfSense ce connecte bien au serveur OpenVPN mais ce qu'on ne sait toujours pas:

quand le client est pfSense pouvez-vous accédez au réseau distant une fois le VPN établie ? par un ping ou autre?
j'ai crue comprendre que pfSense v2 pouvez filtrer OpenVPN avec les rules, avez-vous regarder par là ?

yob

quand le vpn n'est pas actif tout fonctionne correctement. c'est à dire accès internet sans problème que ce soit à partir des postes derrières pfsense ou à partir de pfsense directement avec les outils de diagnostics comme ping ou traceroute.
Quand le vpn est actif l'accès internet à travers le vpn est accessible à pfsense c'est à dire que les pings et traceroute sont parfaitement fonctionnels depuis l'interface pfsense alors que les pcs derrières pfsense n'ont plus l'accès internet.

Concernant les rules wan actuellement il n'y a aucune règle en place.

Je confirme qu'avec pfsense v2 ont peux filtrer l'interface virtuelle de l'openvpn actuellement aucune règle mise en place.

titofe

@yob:

Je confirme qu'avec pfsense v2 ont peux filtrer l'interface virtuelle de l'openvpn actuellement aucune règle mise en place.

Hormis changement de politique avec la v2 …, sinon aucune règle (rules) de définie veux dire que rien ne passe ... donc pas d'accès web, réseau distant, etc.

yob

Comme je l'ai indiqué une seule règle activée celle qui permet à tout ce qui est lan d'accéder au wan. Et je confirme la politique n'a pas changé tout est bloqué par défaut.

pour plus de précision voici une capture des règles wan et lan.

titofe

Et quelles sont les règles (rules) établie dans l'onglet 'OpenVPN', sauf erreur de ma part, mais le filtrage doit aussi ce faire même si pfSense n'est que client.
Donc pas de rules qui donne explicitement l'accès dans le tunnel, pas d'accès.

yob

l'onglet OpenVPN ne contient actuellement aucune règle

titofe

@yob:

l'onglet OpenVPN ne contient actuellement aucune règle

Eh alors …!!? ne faut-il pas justement une règle (rules) pour que cela fonctionne?

yob

je pense que oui mais justement je ne sais pas trop quelle règle mettre en place

titofe

Pour effectué un test, la même règle (rules) que le Lan conviendra, ensuite il faudra restreindre par rapport à vos besoin.

yob

@titofe:

Pour effectué un test, la même règle (rules) que le Lan conviendra, ensuite il faudra restreindre par rapport à vos besoin.

la même règle que le lan a été mise en place mais le problème n'a pas changé.

titofe

Peut on avoir une copie d'écran de la rules pour le tunnel OpenVPN.

Vous n'êtes décidément vraiment pas bavard, on aimerais savoir quelle sont les test que vous avez effectué et leur résulta pour en arriver à cette conclusion …

yob

voici une capture des rules qui ont été testées pour l'openvpn

Même test qu'avant cad ping et traceroute à partir de fpsense avec vpn actif aucun problème.


Traceroute output www.google.fr

 1  10.8.0.1 (10.8.0.1)  136.710 ms  43.986 ms  43.027 ms
 2  xxxxxxxxxxx (212.117.xxx.x)  44.324 ms  73.355 ms  117.091 ms
 3  40g.lxb-fra.as5577.net (83.243.12.2)  231.473 ms  249.051 ms  252.606 ms
 4  de-cix10.net.google.com (80.81.192.108)  89.033 ms  249.517 ms  212.826 ms
 5  209.85.255.170 (209.85.255.170)  277.888 ms  247.145 ms  193.864 ms
 6  72.14.233.104 (72.14.233.104)  258.132 ms  295.940 ms  263.036 ms
 7  64.233.175.115 (64.233.175.115)  258.678 ms  195.587 ms  217.760 ms
 8  par03s01-in-f104.1e100.net (66.249.92.104)  223.683 ms  232.377 ms  208.161 ms

Avec vpn actif les postes derrières pfsense n'accèdent pas à internet. (que ce soit avec un navigateur web, client ftp, client ssh …)
à partir de ces postes ping ok de l'interface lan (192.168.0.12) et de l'interface wan de fpsense et pink ok aussi pour l'adresse du client vpn (10.8.0.6)
un traceroute google.fr s'arrête à l'adresse lan de pfsense

jdh

Compte tenu des règles, cela me semble très logique !

Pour info, "LAN net" ne saurait guère être identique au réseau des clients VPN !

yob

@jdh:

Compte tenu des règles, cela me semble très logique !

Pour info, "LAN net" ne saurait guère être identique au réseau des clients VPN !

si l'erreur vous saute aux yeux pouvez vous m'aiguiller sur la solution à mettre en place ?

jdh

Et je n'ai pas déjà répondu ?

En effet, c'est assez instantané de voir qu'il n'y a pas la règle qu'il faut !
Je rappelle qu'une règle décrit le paquet initial d'une session avec une source, une destination, un protocole (et son port le cas échéant).
Alors il suffit de caractériser la source, la destination …

Relisez bien ce que j'écris ... Normalement ça doit faire "beh oui, que je suis c."

yob

problème résolu non pas en créant une règle (rules) mais en activant tout d'abord Manual Outbound NAT rule generation
(AON - Advanced Outbound NAT) puis un créant une règle autorisant le lan à accéder au vpn.

Merci à tous.

jdh

Incompréhensible !

Le manque de précision, d'informations, de logique est étonnant.

Quant Titofe écrit "la même règle (rules) que le Lan conviendra", il s'agit d'écrire une règle pour le réseau VPN.
Et on retrouve sous l'onglet "OpenVPN", une règle qui autorise "LAN net" … ce qui n'a AUCUN sens aucun !

Il est clair que même le problème est incohérent ; avec un client VPN, les clients LAN n'ont plus accès à Internet.
Déjà là, on voit que tout cela est vague puisqu'en principe cela n'a rien à voir.

La solution serait un Outbound NAT manuel et spécifique (d'ailleurs non décrit !). Alors que WAN est une simple ip derrière une box !

Je rappelle que la 2.0 est en BETA : cela signifie qu'il est possible (lire probable ou certain) que certaines fonctions ne fonctionnent pas ou pas comme attendues. Ceux qui veulent tester doivent en être parfaitement conscient et avoir suffisamment d'expérience pour décrire et remonter les problèmes

Bref un fil qui devrait se trouver dans un autre sous-forum, qui ne comporte que TRES peu d'informations et qui est résolu par une méthode étonnante et pas décrite !

De toute façon, le "redirect gateway" n'est pas très intelligent AMPSHA parce qu'un client VPN a tout intérêt à pouvoir surfer sur sa propre ADSL plutôt que passer par la SDSL du site auquel il est connecté en VPN. Il est possible que cela ait une utilité mais je la vois faible. A moins que l'on imagine pouvoir surveiller ainsi le flux des utilisateurs VPN ... qui arrêtent le VPn et font ce qu'ils veulent !

(En plus ce réglage "bizarre" n'est pas même mis en cause ...)

titofe

@jdh:

Incompréhensible !

Le manque de précision, d'informations, de logique est étonnant.

Quant Titofe écrit "la même règle (rules) que le Lan conviendra", il s'agit d'écrire une règle pour le réseau VPN.
Et on retrouve sous l'onglet "OpenVPN", une règle qui autorise "LAN net" … ce qui n'a AUCUN sens aucun !

Il est clair que même le problème est incohérent ; avec un client VPN, les clients LAN n'ont plus accès à Internet.
Déjà là, on voit que tout cela est vague puisqu'en principe cela n'a rien à voir.

La solution serait un Outbound NAT manuel et spécifique (d'ailleurs non décrit !). Alors que WAN est une simple ip derrière une box !

Je rappelle que la 2.0 est en BETA : cela signifie qu'il est possible (lire probable ou certain) que certaines fonctions ne fonctionnent pas ou pas comme attendues. Ceux qui veulent tester doivent en être parfaitement conscient et avoir suffisamment d'expérience pour décrire et remonter les problèmes

Bref un fil qui devrait se trouver dans un autre sous-forum, qui ne comporte que TRES peu d'informations et qui est résolu par une méthode étonnante et pas décrite !

De toute façon, le "redirect gateway" n'est pas très intelligent AMPSHA parce qu'un client VPN a tout intérêt à pouvoir surfer sur sa propre ADSL plutôt que passer par la SDSL du site auquel il est connecté en VPN. Il est possible que cela ait une utilité mais je la vois faible. A moins que l'on imagine pouvoir surveiller ainsi le flux des utilisateurs VPN ... qui arrêtent le VPn et font ce qu'ils veulent !

(En plus ce réglage "bizarre" n'est pas même mis en cause ...)

+1

yob

@jdh:

Incompréhensible !

Le manque de précision, d'informations, de logique est étonnant.

Ne sachant pas d'où provenait le problème il est difficile de savoir quoi indiquer de plus, j'ai fourni toutes les informations demandées ou qui me semblaient pertinentes.

@jdh:

Il est clair que même le problème est incohérent ; avec un client VPN, les clients LAN n'ont plus accès à Internet.
Déjà là, on voit que tout cela est vague puisqu'en principe cela n'a rien à voir.

La solution serait un Outbound NAT manuel et spécifique (d'ailleurs non décrit !). Alors que WAN est une simple ip derrière une box !

Problème qui peut apparaitre incohérent cependant il semble être assez répandu car justement j'ai trouvé plusieurs fil de discussions en parlant sur le forum anglais.

@jdh:

Je rappelle que la 2.0 est en BETA : cela signifie qu'il est possible (lire probable ou certain) que certaines fonctions ne fonctionnent pas ou pas comme attendues. Ceux qui veulent tester doivent en être parfaitement conscient et avoir suffisamment d'expérience pour décrire et remonter les problèmes.

Je suis tout à fait conscient qu'il s'agit d'une version beta plus précisément beta 4 built on Sat Sep 18 23:15:00 EDT 2010 et je pense que les problèmes avaient été bien décrit même si il est peut-être vrai qu'il manquait certaines informations.

@jdh:

Bref un fil qui devrait se trouver dans un autre sous-forum, qui ne comporte que TRES peu d'informations et qui est résolu par une méthode étonnante et pas décrite !

voici la règle mise en place en image.

@jdh:

De toute façon, le "redirect gateway" n'est pas très intelligent AMPSHA parce qu'un client VPN a tout intérêt à pouvoir surfer sur sa propre ADSL plutôt que passer par la SDSL du site auquel il est connecté en VPN. Il est possible que cela ait une utilité mais je la vois faible. A moins que l'on imagine pouvoir surveiller ainsi le flux des utilisateurs VPN … qui arrêtent le VPn et font ce qu'ils veulent !

(En plus ce réglage "bizarre" n'est pas même mis en cause ...)

Ce réglage n'a pas été mis en cause car comme je l'avais indiqué le vpn fonctionnait correctement avec un client vpn classique comme OpenVPN
Je suis d'accord sur le fait qu'en règle générale il est judicieux de laisser l'accès web avec la "connexion internet locale" cependant dans le cas présent cela était nécessaire par l'utilisation.

J'espère qu'avec ce post j'aurais tiré certaines choses au clair.

En tout cas merci jdh & titofe.