[RESOLU] pfsense 2 openvpn navigation internet

titofe

…

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.

jdh

Ce que j'attends dans un onglet de "Rules", c'est que la source soit bien correspondante !

Dans l'onglet LAN, les règles ne doivent concerner que des machines issues de "LAN Net". Idem pour DMZ.
De même, dans l'onglet OpenVPN, il ne devraient y avoir que des règles avec comme source des machines recevant une adresse fournie par OpenVPN.

Ne connaissant pas le code généré en pf, je peux quand même supposer que pour les machines sous VPN sont naturellement NATées comme celle issues de LAN. Aussi je ne comprends guère qu'il soit nécessaire de faire un Outbound NAT spécifique. (Il peut arriver que l'on fasse un Outbound NAT pour un réseau mais pas pour ressortir vers WAN puisque c'est normal et naturel.)

Je pense que cette situation doit être attentivement décomposée, que le réglage pour un réseau ne perturbe pas celui de l'autre.

Il est incompréhensible que le trafic de LAN vers WAN soit perturbé quand il y a un machine se connectant en VPN.

Par ailleurs, je ne vois aucune référence à un éventuel proxy Squid (éventuellement en transparent).

Je me méfie aussi des règles générales car il est bien meilleur de spécifier chaque besoin. (En plus on peut loguer et on sait ce qu'on peut tester).

Le VPN permet d'accéder au réseau interne, donc il importe de fournir un dns parfait pour désigner les machines.
Mais le trafic vers Internet peut être direct et local, c'est à dire sans passer par VPN.
Car OpenVPN fonctionne là en mode routé et non bridgé.
Je recommande donc d'éviter "redirect gateway".

NB : Si vous avez une auto-détection de proxy via le DNS, vous risquez de fournir celle-ci aux clients VPN. Voyez ce n'est pas encore fini …