OPENVPN CLIENT IP STATIC
-
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.
-
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
-
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.
-
(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> -
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
-
Après avoir revu tout ça c'est maintenant beaucoup plus clair
Merci CCnet et jdh pour vos explications.
Bonne Journée
@+
Benjamin
-
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.
-
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
-
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. -
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
-
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 ?
-
Oui OPENVPN avec identification avec nom d'utilisateur et mot de passe.
-
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. -
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
-
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.
-
Oui effectivement
par contre il faut que je regarde ce type de service avec pfsense… (... nouvelles questions a venir ... ;P )
-
Allez encore une petite question (Merci CCNET pour votre aide)
Une solution freeradius en package (Motp) est elle une bonne idée ?
Merci
-
Pas de réponse dans l'absolu. Tout est une question d'adéquation entre les besoins et les moyens (financiers, techniques, organisationnels).