[RESOLU] pfsense 2 openvpn navigation internet
-
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.
-
@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.
-
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.
-
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. -
l'onglet OpenVPN ne contient actuellement aucune règle
-
@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?
-
je pense que oui mais justement je ne sais pas trop quelle règle mettre en place
-
Pour effectué un test, la même règle (rules) que le Lan conviendra, ensuite il faudra restreindre par rapport à vos besoin.
-
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é.
-
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 …
-
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 msAvec 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 -
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 !
-
@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 ?
-
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."
-
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.
-
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 ...)
-
@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
-
@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.
-
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 …
-
Dans la configuration actuelle je ne vois pas comment une règle pourrait en perturber une autre sachant qu'il n'y a aucune règle(rules) WAN active et que une seule règle (rules) LAN est active (celle qui permet l'accès WAN)
Aucune référence n'a mentionné Squid car il n'est tout simplement pas activé pour le moment.
La règle globale actuelle ne va bien entendu ne pas rester comme cela car effectivement il est nettement meilleur de tout définir manuellement afin de tout pouvoir maitriser.
Elle a été avant mise en place afin de pouvoir afin dans un 1er temps de poursuivre les test et de mieux comprendre.Si cela peux vous rassurer cette beta 4 n'est pas en production mais en test afin appréhender les nouvelles fonctionnalités prisent en charge.
Au vue des informations données sur l'utilisation de "redirect gateway" je vais regarder cela de plus près.
Concernant l'auto-détection de proxy via le DNS je n'y avait tout simplement pas encore pensé …