OPENVPN CLIENT IP STATIC

ben.lgrs

Bonjour a tous

Je débute avec PFSence, j'ai fait pas mal de recherche sur le net avec pas mal de solution differentes. Mais je suis passé a coté de la solution donc je viens vers vous pour m'aider a solutionner mon problème.

J'ai monté un pfsense et créé un open VPN serveur (tun)
le VPN marche trés bien.
Je rencontre seulement un problème pour définir un ip Static a un de mes clients (Windows)
Coté Windows le programme est bien exécuté en tant qu'administrateur.

J'ai créé une "Config spécifique" pour le client en question (ifconfig-push) mais j'ai systématiquement une erreur coté client et la connexion ne ce fait pas (ou au mieux je n'ai pas l'ip fix souhaité)

Mon but est d'interconnecté des clients VPN entre eux sans besoin d’accéder au LAN du PFSense

Mon VPN est en TUN
IPv4 Tunnel Network 172.30.1.0/24
IPv4 Local Network/s 10.3.3.0/24
Dynamic IP : coché
Address Pool : coché

J'ai testé pour la config spécifique du Client :
ifconfig-push 172.30.1.200/24;
ifconfig-push 172.30.1.200 255.255.255.0;
ifconfig-push 172.30.1.200 172.30.1.1;
ifconfig-push 172.30.1.200 172.30.1.9; (L'ip 9 car c'est la passerelle qui se configure sur la connexion de base)

Je passe à coté de la solution …

Merci pour vos conseils et votre aide

Cordialement

Benjamin

ccnet

Vous ne dites rien de la génération des certificats. Il est essentiel pour que cette configuration (ip assignée à l'utilisateur) fonctionne que le CN soit cohérent entre le certificat utilisateur et le document de configuration OPenvpn. Est ce le cas ?

ben.lgrs

Merci pour votre reponse

Oui les certificat fonctionne correctement lors de la connexion je vois bien le système qui essaye de prendre l'adresse ip souhaité mais j'ai directement une erreur et la connexion échoue.

J'ai de nouveau symptome car quand je fait un route print sur mes client je vois bien la route pour mon reseau VPN mais il n'y a plus de passerelle de configuré. J'ai surement Merdé et désactivé une option mais je vois pas laquelle.

Merci de vos conseil

Cordialement

Benjamin

ccnet

Je repose la question : le CN est il identique dans le certificat de l'utilisateur et dans la configuration spécifique ?

la connexion échoue.

Une copie des logs serait utile.

ben.lgrs

Merci

Le CN est bien identique

J'ai fini par trouver mais je ne m'explique pas tout. Si éventuellement quelqu’un peux m'expliquer le pourquoi du comment de la chose, histoire de bien comprendre la problématique et de ne plus me tromper. (Merci d'avance)

Je détail ma config :

OPENVPN
Serveur TUN
IPv4 Tunnel Network : 172.30.1.0/24
IPv4 Local Network/s : 10.3.3.0/24
Inter-client communication : Coché
Dynamic IP : Coché
Address Pool : Coché

Spécifique Client Override
CN : identique au CN= de l'utilisateur qui aura l'ip static
Tunnel Network : 172.30.1.0/24
IPv4 Local Network/s : 10.3.3.0/24
IPv4 Remote Network/s : 192.168.0.0/24
Advanced : ifconfig-push 172.30.1.201 172.30.1.202;

Donc la tout marche avec l'ip Static 201 mais si je met 200 ça ne marche pas (ifconfig-push 172.30.1.200 172.30.1.1;)
voici l'erreur : There is a problem in your selection of –ifconfig endpoints [local=172.30.1.200, remote=172.30.1.1]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of –dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' option for more info.

Merci pour toutes vos aides et vos conseils

Cordialement

Benjamin

PS : Éventuellement y a t il un de vous qui a installé un Client OPENVPN en service pour que la connexion monte en même temp que Windows sans avoir besoin d'ouvrir la session. Merci d'avance

ccnet

Donc la tout marche avec l'ip Static 201 mais si je met 200 ça ne marche pas (ifconfig-push 172.30.1.200 172.30.1.1;)

https://openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html
Il faut bien comprendre que :
OpenVPN assigns a /30 subnet for each client that connets. The first available /30 subnet (after the one the server is using) is:

192.168.1.4/30
192.168.1.4 – Network address
192.168.1.5 -- Virtual IP address in the OpenVPN Server
192.168.1.6 -- Assigned to the client
192.168.1.7 -- Broadcast address.

Le message d'erreur ne dit pas autre chose ! Votre "problème" est donc normal.

jdh

(Je n'ai pas la patience de ccnet !)

Dans le post initial, il y a un gros problème :

Mon but est d'interconnecté des clients VPN entre eux sans besoin d’accéder au LAN du PFSense

De façon évidente,

vous n'avez pas compris l'adresse ip fournie (en fait le masque), d'où l'explication du post précédent de ccnet
vous n'en avez pas déduit la difficulté de ce que vous voulez faire
vous essayer de contourner avec des masques de sous-réseau inadapté.

L'ordre logique eut été :

on me fournit une adresse ip, OK
on me fournit un masque : comme il est bizarre !
pourquoi un masque /30 et pourquoi cela empêche ce que je voudrais faire …

En fait votre besoin est très surprenant (je ne l'ai jamais rencontré ... et je n'en vois guère l'intérêt).

Vous indiquez "Try 'openvpn --show-valid-subnets'" : le résultat est clair :

C:\Program Files\OpenVPN\bin>openvpn --show-valid-subnets
On Windows, point-to-point IP support (i.e. --dev tun)
is emulated by the TAP-Windows driver.  The major limitation
imposed by this approach is that the --ifconfig local and
remote endpoints must be part of the same 255.255.255.252
subnet.  The following list shows examples of endpoint
pairs which satisfy this requirement.  Only the final
component of the IP address pairs is at issue.

As an example, the following option would be correct:
    --ifconfig 10.7.0.5 10.7.0.6 (on host A)
    --ifconfig 10.7.0.6 10.7.0.5 (on host B)
because [5,6] is part of the below list.

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

C:\Program Files\OpenVPN\bin>

ben.lgrs

Merci pour vos réponses et je vais me replonger dans toutes ces informations.

Je suis Vraiment DÉSOLÉ de choquer et de faire perde patience à certain.

Je suis en apprentissage sur PFSense et Linux et je suis essentiellement dans l'univers Crosoft (Oups Désolé). Donc moi petit Scarabé et je me tourne vers une communauté d'expert aux conseils éclairés et bien veillants.

Cet interconnexion entre VPN est pour palier a une Urgence d'un de mes Clients dont son VPN est HS et pour diverse raison je ne peux pas le remplacer aussi facilement (Ce n'est pas moi qui gère tout ce matériel).

Mon PFsense est hébergé sur un PCC chez OVH.

j'ai installé en service le Client OpenVPN sur le serveur TSE en lui attribuant une IP Static
J'ai installé le Client OPENVPN sur les postes itinérants

Ainsi les Utilisateurs peuvent se connecter à leur serveur TSE et travailler.

Encore merci pour vos explications et si ce fil peux rendre service.

Cordialement

Benjamin

ben.lgrs

Après avoir revu tout ça c'est maintenant beaucoup plus clair

Merci CCnet et jdh pour vos explications.

Bonne Journée

@+

Benjamin

ccnet

Tant mieux.

PS : Éventuellement y a t il un de vous qui a installé un Client OPENVPN en service pour que la connexion monte en même temp que Windows sans avoir besoin d'ouvrir la session. Merci d'avance

D'un point de vue sécurité je vous le déconseille très fortement.

ben.lgrs

Il est clair qu'une connexion automatique en service n'est pas l'idéal mais dans l'urgence d'une situation provisoire il faut faire des choix.

Encore merci

@+

Benjamin

ccnet

Il faut faire les bons choix. Pas les mauvais.
Il n'y a aucune raison pour, dans une situation d'urgence, donc déjà dégradée, ajouter des facteurs de risques très importants. Après avoir perdu une partie du SI, on ne prend pas le risque d'en compromettre la totalité. Une situation dégradée implique des contraintes. Tous les gens qui se sont déjà intéressé aux problèmes de disponibilité (dans un PCA ou un PRA) savent cela. Je ne vois pas la pertinence du choix en question. L'utilisateur peut saisir un mot de passe pour lancer une connexion vpn. Ne pas authentifier l'utilisateur lors d'une connexion au SI via un réseau non maitrisé est une très mauvaise idée. Vous feriez courir à votre client un niveau de risque déraisonnable. En cas de problème, votre raisonnement ne tiendrait pas 2 minutes dans une expertise judiciaire et votre responsabilité serait engagée.
Je ne connais pas le secteur d'activité de votre client. Il est possible, selon le cas, que les contraintes réglementaires liées à son activité le mette en situation difficile alors même qu'aucun sinistre ne se produirait. Prenez l’exemple de la loi Informatique et Libertés : la sécurisation des dcp est une obligation.

ben.lgrs

Merci CCNET pour ces informations.

Il est vrai que de mettre une "Auto-authentification" fait courir un risque au client. de ce coté la il y a rien a redire.
Mais dans un cas de figure pareil quel serait éventuellement votre choix.
Mon client a besoin pour ses commerciaux d'un accès VPN pour se connecter a leur serveur TSE hébergeant leur gescom.
Actuellement ils sont lier a un prestataire pour leur routeur et le VPN est totalement bancale et instable et le prestataire ne fait pas son JOB et je n'ai pas d’accès à ce routeur.
Donc le Client a un besoin Urgent de travailler d’où ce choix discutable mais fonctionnel.
A terme il est prévu de virer le routeur actuel pour mettre un Pfsense. mais, malheureusement, pas avant plusieurs semaine.

Merci par avance

Cordialement

Benjamin

ccnet

La description plus précise du contexte est une bonne chose et l'on situe mieux le problème.

Mais dans un cas de figure pareil quel serait éventuellement votre choix.

Vous avez mis en place Openvpn et les utilisateurs s'authentifient grâce au certificat, protégé par un mot de passe ? C'est bien la situation actuelle ?

ben.lgrs

Oui OPENVPN avec identification avec nom d'utilisateur et mot de passe.

ccnet

Chaque utilisateur possède bien son propre certificat avec date d'expiration maitrisée et par ailleurs gestion d'une CRL côté serveur OpenVPN ?
Il faut bien comprendre que ce ne sont ni le nom, ni le mot de passe qui permettent l'authentification mais le certificat. Le nom et le mot de passe ne permettent que l'accès au certificat.
La configuration VPN doit être telle qu'il n'existe pas de double attachement de la machine connectée en vpn.
Auquel cas il n'y a rien de plus à faire, sauf a avoir besoin d'une authentification forte.

ben.lgrs

J'ai effectivement mis une authentification forte avec un mot de passe aléatoire complexe et chaque utilisateur ne peux se connecté qu'une seul fois.

Merci pour vos conseil et vos renseignements

Je m'éduque petit à petit ;P

@+

Benjamin

ccnet

J'ai effectivement mis une authentification forte avec un mot de passe aléatoire complexe et chaque utilisateur ne peux se connecté qu'une seul fois.

Ce n'est pas cela que l'on appelle une authentification forte. Ce type de solution nécessite une authentification à double facteur. L'exemple type est celui des tokens Secure ID. Ou encore une clé usb qui embarque une émulation carte à puce.

ben.lgrs

Oui effectivement

par contre il faut que je regarde ce type de service avec pfsense… (... nouvelles questions a venir ... ;P )

ben.lgrs

Allez encore une petite question (Merci CCNET pour votre aide)

Une solution freeradius en package (Motp) est elle une bonne idée ?

Merci