OpenVPN, Management Daemon Unreachable

flipflip

Bonjour,

J'ai mis en production pfsense et je m'attaque à la configuration d'OpenVPN. Je possède deux paramétrages d'openvpn que je distingue via le port. Il arrive que je ne puisse pas me connecter à l'un deux car j'ai le message suivant dans le webgui : Management Daemon Unreachable. J'ai beau cliquer sur le bouton "Kill client…" mais rien à faire. Au clic j'obtiens : An error occurred. (-1).

Je précise que je suis avec la dernière version stable de pfsense. J'ai essayé de relancer openvpn via cette commande php :

include('openvpn.inc');
openvpn_resync_all();

flipflip

J'ai l'impression qu'il y a un bug lorsqu'il y a deux vpn openvpn de configuré.

Processus :

je désactive les deux vpn;
un fichier serverX.sock reste dans /var/etc/openvpn;
je re-active le 1er vpn puis le second;
le 1er marche mais pas le second dans "Status / OpenVpn" a l'erreur Management Daemon Unreachable;
je répète l'opération mais j'active le second vpn en premier;
dans "Status / OpenVpn" c'est le 1er qui est en erreur et impossible de ce connecter dessus.

baalserv

Bonjour,

Il n'y a aucun bug majeur avec Ovpn sur pfsense !!!

A titre d'exemple : sur celui de mon domicile j'ai 3 serveurs Ovpn qui tournent parfaitement depuis des lustres (1 pour ma compagne et moi qui ''pointe'' sur le lan, 1 pour notre jeux de rôle pour les autres admin du module qui se connectent sur le serveur de test qui est en Dmz, et le 3ème qui est de type lan to lan ou le pfsense du bureau établie la liaison avec le lan de la maison)
Et je ne parle même pas de ceux qui sont en prod chez des clients^^

Commencez donc par nous donner des informations pertinantes sur votre configuration mais aussi sur vos besoins (le besoin ne veut pas dire ''solution technique'' que vous présumez)

Cordialement

ccnet

Plusieurs config en production avec openvpn multiples sans problème particulier. Il y a autre chose probablement.

flipflip

Bonjour,

Il n'y a aucun bug majeur avec Ovpn sur pfsense !!!

Tant de certitudes ;)

Je n'ai besoin que d'un vpn pour faire du roadwarrior avec plusieurs clients connecté en même temps. Pour le moment si j'en ai deux c'est simplement parce que un est en prod et l'autre me sert pour tester une autre configuration.

L'idée est de permettre à des clients nomades de ce connecter à notre réseau et accéder à différentes ressources (tse, cifs…). Les clients sont soit sur Windows XP soit sur Windows 7 ou encore du linux/unix. J'ai besoin de pouvoir authentifier les utilisateurs par rapport à notre annuaire ldap avec une gestion de certificat pour pouvoir invalider la connexion par exemple dans le cas ou le client c'est fait voler son portable. J'aurais juste à générer un nouveau certificat.

Au niveau des VPN que j'ai actuellement de configuré ils ont en commun les paramètres suivant :

authentification avec l'annuaire ldap;
même adresse réseau 192.168.y.0;
même adresse wan;
même paramètre netbios, dns, wins;

Ce qu'ils n'ont pas en commun :

port 1194 pour celui en prod 1195 pour celui de test;
méthode d'authentification : Remote Access (User Auth) pour le celui en prod, Remote Acces (SSL/TLS + User Auth) pour celui de test

J'ai bien les règles de firewall wan pour laisser passer les port 1194 et 1195. Dans les règles firewall OpenVpn j'ai une règle "bateau" qui laisse tout passer (c'est pour du test).

Au niveau des services activés :

DNS forwarder;
NTP sur le LAN;

J'ai juste un package d'installé : OpenVPN Client Export Utility en version 1.0.7
Voila je pense avoir donné pas mal d'infos, si ils vous en faut d'autres dite le.

jdh

Comme baalserv et ccnet, j'ai plusieurs pfSense avec des services OpenVPN actifs (et multiples sur serveurs).
(Notamment un fw avec des clients nomades et un site-to-site pour un petit site.)

Au niveau des règles fw, il est important de ne pas oublier

la règle accès fw sur le port (onglet WAN / proto+port accepté sur WAN Address),
puis les règles dans l'onglet OpenVPN.

Perso, je reste sur des certificats (géré par System > Cert Manager) et des serveurs OpenVPN en "Remote Access SSL/TLS".
Je me méfie du "Client Export Utility" car à la première utilisation cela n'a pas bien fonctionné : pas très grave, il suffit de copier un .ovpn et de modifier le nom du certificat .pkcs12.

Attention à la nécessité impérative de démarrer OpenVPN GUI sur Windows en mode "administrateur" (sinon les routes ne s'ajoutent pas).
De même, il faut faire très attention au password de certificat (manuel = avant pfSense 2.0 et son cert manager) : je déconseillerai plutôt.
Et cela s'applique à une authentification supplémentaire via LDAP/ActiveDirectory ….

Le terme "Management Daemon Unreachable" me ferait plutôt penser à un service qui ne démarrerait pas.
Il faut donc regarder le syslog du fw ...

flipflip

Entre temps j'ai ouvert un post dans le forum dédié à OpenVPN : http://forum.pfsense.org/index.php/topic,64294.0.html

Je ne pense pas que cela proviennent des règles puisque celui de prod fonctionne correctement.

var/log/openvpn.log after active VPN1 and VPN2

Jul 10 14:13:09 svfir02 openvpn[13082]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr  2 2013
Jul 10 14:13:09 svfir02 openvpn[13082]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Jul 10 14:13:09 svfir02 openvpn[13082]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 10 14:13:09 svfir02 openvpn[13082]: WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate
Jul 10 14:13:09 svfir02 openvpn[13082]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Jul 10 14:13:09 svfir02 openvpn[13082]: TUN/TAP device /dev/tun1 opened
Jul 10 14:13:09 svfir02 openvpn[13082]: /sbin/ifconfig ovpns1 192.168.x.1 192.168.x.2 mtu 1500 netmask 255.255.255.255 up
Jul 10 14:13:09 svfir02 openvpn[13082]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 192.168.x.1 192.168.x.2 init
Jul 10 14:13:09 svfir02 openvpn[15011]: UDPv4 link local (bound): zzz.26.133.zzz:1194
Jul 10 14:13:09 svfir02 openvpn[15011]: UDPv4 link remote: [undef]
Jul 10 14:13:09 svfir02 openvpn[15011]: Initialization Sequence Completed
Jul 10 14:13:13 svfir02 openvpn[38232]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr  2 2013
Jul 10 14:13:13 svfir02 openvpn[38232]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 10 14:13:13 svfir02 openvpn[38232]: Control Channel Authentication: using '/var/etc/openvpn/server2.tls-auth' as a OpenVPN static key file
Jul 10 14:13:13 svfir02 openvpn[38232]: TUN/TAP device /dev/tun2 opened
Jul 10 14:13:13 svfir02 openvpn[38232]: /sbin/ifconfig ovpns2 192.168.x.1 192.168.x.2 mtu 1500 netmask 255.255.255.255 up
Jul 10 14:13:13 svfir02 openvpn[38232]: FreeBSD ifconfig failed: external program exited with error status: 1
Jul 10 14:13:13 svfir02 openvpn[38232]: Exiting

jdh

Jul 10 14:13:13 svfir02 openvpn[38232]: /sbin/ifconfig ovpns2 192.168.x.1 192.168.x.2 mtu 1500 netmask 255.255.255.255 up
Jul 10 14:13:13 svfir02 openvpn[38232]: FreeBSD ifconfig failed: external program exited with error status: 1

Et si la config des "serveurs" OpenVPN était incorrectes avec, par exemple, l'adresse de tunnel vpn identique ?

flipflip

oui ils ont bien la même adresse réseau. Je n'avais pas vue cette erreur dans les logs, je test dans l'après midi.

jdh

Cela me parait plutôt une erreur de compréhension : un "serveur" OpenVPN, qui nécessite forcément un adressage réseau entre lui et les clients, ne saurait avoir le même adressage réseau qu'un autre "serveur".

(Par "serveur", j'entends un daemon qui écoute sur un protocole/port donné, et une interface donnée, bref une "ligne" dans VPN > OpenVpn > onglet Server.)

Donc entre "j'ai l'impression d'un bug" et "il n'y a aucun bug majeur", je pencherai plutôt sur la 2ième comme exacte.

flipflip

C'était bien un problème avec la même adresse ip pour les deux vpn. Ce n'était ni un bug, ni un problème de compréhension mais un problème d’inattention :(

Merci pour l'aide.