Bonjour,
Un routeur VPN qui serait le seul client VPN entre le LAN et le routeur physique. ça, je peux le faire.
J’ai configurer un pfSense entre le LAN et le routeur, je peux lui ajouter le client OpenVPN.
Par contre comment les clients externes peuvent avoir accès aux dossiers et à une connexion TSE ?
C’est bien ce que tu me proposes de faire.
Dans ce cas je dois utiliser « tun » ou « tap » ?
Aujourd’hui j’utilise « tun »
Merci
pas de lien contractuel/hierarchique entre les deux?
C’est bien le problème de la mode du télétravail pour les nuls. pas de réflexion de fond.
Donc ta seule solution sinon c’est en effet de faire une machine interne et ton VPN. Mais ne fait pas un client OpenVPN, fait plutot un tunnel, ça sera plus éfficace.
Car c’est ta machine interne qui va se connecter vers le VPS pour qu’ensuite les machine du VPS viennent vers ta machine interne.
Un tunnel est donc plus approprié, car cela permet des communications dans les deux sens avec la même performance (au detail des machines près et des routeurs intermédiaires).
Merci pour ta réponse,
Comment dois-je m’y prendre pour créer un tunnel ?
Essaye cela:
https://wiki.csnu.org/index.php/IPsec_sous_debian_avec_strongswan
https://www.tecmint.com/setup-ipsec-vpn-with-strongswan-on-debian-ubuntu/
le deuxieme est pour ubuntu mais devrait etre adaptable. Le premier peut suffire.
Sur le VPS tu as deux choses: OpenVPN pour tes clients qui viennent s’y connecter. Puis le tunnel IPSec entre ta machine interne et la machine distante. en espérant que le routeur de la region ne bloque pas les tunnel (en tant que consultant , je préconise souvent aux entreprises d’interdire toutes formes de tunnels d’un poste interne qui n’ai pas été validé par la sécurité).
Ok, je regarde tout ça et je vous tiens au courant.
Merci
Oui, sauf que l’utilisation de TCP pour un VPN est déconseillée.
tap n’est utile que si on a besoin d’une couche ethernet, par exemple pour que les broadcasts passent (pour NetBios). Dans ce cas il faut faire un pont entre l’interface tap et l’interface LAN du firewall.
Quelle est la différence ? Un VPN, c’est une forme de tunnel. En quoi cela serait-il plus efficace ?
Qu’appelles-tu « les machines du VPS » ?
Je ne comprends pas ton raisonnement. Tout cela est possible avec OpenVPN.
Tu lui proposes de remplacer OpenVPN par IPSec qui est une usine à gaz sans nom ?
Quand un utilisateurs externe arrive en VPN sur le VPS il est directement dans le réseau du VPS et donc du site distant.
Si c’est du VPN entre les site, c’est du VPN de VPN. Le tunnel étend le réseau, le VPN t’amène au réseau. Cela implique évidement que le VPS soit correctement sécurisé.
| PARAMETER | SITE TO SITE VPN | REMOTE ACCESS VPN |
|---|---|---|
| Philosophy | Uses a security method called IPsec to build an encrypted tunnel from one Customer network (generally HQ or DC) to the customer’s remote site between whole or part of a LAN on both sides. | Remote access VPN connect individual users to private networks (usually HQ or DC). |
| VPN Client on end devices | Not required to be setup on each Client | Every user may (Client VPN) or may not (Clientless) require to have own VPN client. |
| Tunnel Creation | Each users is not required to initiate to setup VPN tunnel | Each remote access user needs to initiate to form VPN tunnel |
| Target User | Office LAN Users of branch office need to connect to servers in HQ | Roaming users who want to access Corporate office resources/servers securely. employees who travel frequently |
| Encryption / Decryption | The VPN gateway is responsible for encapsulating and encrypting outbound traffic, sending it through a VPN tunnel over the internet to a peer VPN gateway at the target site | the VPN client software encapsulates and encrypts that traffic before sending it over the internet to the VPN gateway at the edge of the target network |
| Technologies Supported | IPSEC | IPSEC and SSL |
| Multiple User / VLAN traffic flow | Allows multiple users/VLANs traffic to flow through each VPN tunnel. | Does not allow multiple user traffic to pass through each VPN Tunnel |
les machines clientes du VPS, désolé il manquait un mot.
usine à gaz pas vraiment. La configuration est plus complexe, mais on ne peut pas parler d’usine à gaz.
Je ne vois toujours pas ce que tu veux dire. Il y a un VPN ou tunnel permanent entre le VPS et un client interne du site, et des VPN ou tunnels à la demande entre chaque client extérieur et le VPS. Le VPS et le client interne gèrent le routage entre les clients externes et le LAN interne. On peut utiliser aussi bien OpenVPN qu’IPSec ou n’importe quel autre protocole.
Tu te répètes, tu paraphrases, mais tu n’apporte aucune explication ni justification supplémentaire. Ce ne sont que des exemples d’utilisation d’un VPN, indépendants du protocole lui-même.
Pour moi, OpenVPN fait un VPN client-server. Avec IPSEC je fais un tunnel ou il n’y a pas vraiment de necessité de notion de client -server.
Ici je considère que c’est comme avoir deux sites distants l’un de l’autre. Le VPS d’un coté , l’entreprise de l’autre. le tunnel permanent en IPSEC relie deux sites. peut etre simplement lié à une habitude. Maispour moi OpenVPN c’est pour relier un utilisateurs en VPN. DAns le cas ici, je ne considère pas le VPS comme un client mais comme un site.
Ce n’est qu’une façon parmi d’autres d’utiliser ces protocoles. A mon boulot IPSec est utilisé en client-serveur temporaire pour le télétravail, et OpenVPN peut fonctionner en mode pair-à-pair permanent sans notion de client et de serveur.
Pour moi, la notion de site n’est pas vraiment pertinente du point de vue du VPN ; le VPN n’est qu’un tuyau, et ce qui se passe en amont et en aval ne le concerne pas. Le VPN crée un tunnel entre deux machines comme il y aurait un câble ethernet, et en fonction du rôle qu’on lui a affecté chacune des deux machines envoie dans le tunnel du trafic dont la source peut être elle-même ou une autre machine (de son réseau ou plus éloignée, peu importe) et dont la destination peut être la machine à l’autre bout du tunnel ou une autre machine (de son réseau ou plus éloignée, peu importe).
J’ai contacté la région et ils ont accepté d’ouvrir le port 1194 en UDP.
C’est déjà ça !
Bonjour,
J’ai regardé le tunnel IPSec, ça m’a l’air très compliqué. 
Je me suis dit qu’utiliser la fonction client OpenVPN de pfSense sera plus simple vu que mon OpenVPN fonctionne et que j’ai déjà créé les clefs utilisateurs. 
Hé non ! Je n’y arrive pas. 
Lorsque j’importe le certificat CA et de la clé j’ai ce message d’erreur :
The following input errors were detected:
The submitted private key does not match the submitted certificate data.
Vu que la clef est optionnelle, je vais continuer sans la renseigner et configurer le client.
J’ai deux moyens de me connecter à OpenVPN, soit pas un identifiant et mot de passe ou par un .ovpn
Les deux fonctions avec l’application OpenVPN Connect.
Mais sur pfSense je n’y arrive pas !
Je continu à chercher …
Il faut que tu utilise la clef qui a servit à générer le CSR du certificat.
Merci Zargos,
Si j’ai bien compris, logiquement, cette clef doit se trouver dans le fichier client .ovpn ?
Lorsque j’ai créé mes clefs clients, j’ai ajouté les fichiers:
<ca>
contenu du fichier "ca.crt"
</ca>
<cert>
contenu du fichier "client.crt"
</cert>
<key>
contenu du fichier "client.key"
</key>
<tls-crypt>
contenu du fichier "ta.key>
</tls-crypt>Bonjour à tous,
J’ai enfin réussi à configurer un client OpenVPN sur pfSense en UDP.
Tous mes postes internes connectés à cette passerelle ont bien un accès internet passant par le VPN.
Les postes externes peuvent se connecter en RDP.
J’ai tout de même quelque chose qui m’ennuie, quand je consulte le journal système/OpenVPN j’ai :
| Dec 17 08:52:35 | openvpn | 27744 | MANAGEMENT: CMD ‹ state 1 › |
|---|---|---|---|
| Dec 17 08:52:35 | openvpn | 27744 | MANAGEMENT: CMD ‹ status 2 › |
| Dec 17 08:52:35 | openvpn | 27744 | MANAGEMENT: Client disconnected |
| Dec 17 08:52:51 | openvpn | 27744 | MANAGEMENT: Client connected from /var/etc/openvpn/client2.sock |
| Dec 17 08:52:51 | openvpn | 27744 | MANAGEMENT: CMD ‹ state 1 › |
| Dec 17 08:52:51 | openvpn | 27744 | MANAGEMENT: CMD ‹ status 2 › |
| Dec 17 08:52:51 | openvpn | 27744 | MANAGEMENT: Client disconnected |
| Dec 17 08:53:08 | openvpn | 27744 | MANAGEMENT: Client connected from /var/etc/openvpn/client2.sock |
| Dec 17 08:53:08 | openvpn | 27744 | MANAGEMENT: CMD ‹ state 1 › |
| Dec 17 08:53:08 | openvpn | 27744 | MANAGEMENT: CMD ‹ status 2 › |
| Dec 17 08:53:08 | openvpn | 27744 | MANAGEMENT: Client disconnected |
| Dec 17 08:53:24 | openvpn | 27744 | MANAGEMENT: Client connected from /var/etc/openvpn/client2.sock |
| Dec 17 08:53:24 | openvpn | 27744 | MANAGEMENT: CMD ‹ state 1 › |
| Dec 17 08:53:24 | openvpn | 27744 | MANAGEMENT: CMD ‹ status 2 › |
| Dec 17 08:53:24 | openvpn | 27744 | MANAGEMENT: Client disconnected |
etc…
Merci
Le lien VPN et l’interface de management / gestion du lien VPN sont deux choses différentes.
Les messages ne causent de l’interface de management Cela n’indique donc pas une hypothétique déconnexion du lien VPN, tout va bien.
Tu peux être content d’avoir réussi à faire marcher OpenVPN. Bravo !
–
AnonymousCoward
Merci beaucoup ! 