OpenVPn qui a décidé de ne plus fonctionner …
-
Bonjour,
j'ai hérité d'un cluster de deux pfSense, avec une config openvpn en place, que j'ai étendu en ajoutant un deuxième serveur (le 1er a un accès complet au Lan, le 2ème est restreint a un groupe de machines). J'ai un niveau de maitrise "moyen" de la bestiole, je me limite à la mise en place de redirections NAT et de règles de filtrage simples.
Depuis lundi dernier, aucune connexion en fonctionne.
Les services tournent , la config n'a pas l'air d'avoir bougé. Les règles de pare-feu sont en place. Si depuis le réseau local je ping l'ip des serveurs openvpn, j'ai une réponse.
En dehors de ça, toutes mes règles de routage fonctionnent.
Je ne sais plus ou chercher, je pensais qu'il fallait peut-être une règle NAT, dans la mesure où de l'extérieur on "attaque" le vpn par une adresse publique qui abouti au pfsense. Dans la partie anglaise du forum (que j'ai trouvé avant celle là), on m'a dit qu'un règle suffisait, et elle est en place.
La veille de la mise en grève de l'openvpn, on a eu un court-circuit dans l'alimentation de la salle machine, du coup pas de relais par le groupe électrogène et coupure électrique de tous les serveurs, je ne sais pas s'il y a un lien.Je suis preneur de toute piste ;)
-
Depuis lundi dernier, aucune connexion en fonctionne.
Les logs ? Un restart d'openvpn pour les alimenter au besoin ? Messages d'erreur et logs lors de la connexion d'un client ? Aucune connexion vous parlez du vpn ?
Ma boule de cristal est en panne et j'ai vidé la cafetière. -
Côté client, j'ai l'erreur "TLS key negotiation failed to occur within 60 seconds, check network connectivity", et pour openvpn rien de plus que le log de redémarrage :
Jan 16 09:49:31 openvpn[37247]: Initialization Sequence Completed Jan 16 09:49:31 openvpn[37247]: UDPv4 link remote: [undef] Jan 16 09:49:31 openvpn[37247]: UDPv4 link local (bound): [AF_INET]xx.xx.xx.102:1194 Jan 16 09:49:31 openvpn[36387]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1557 10.230.16.1 10.230.16.2 init Jan 16 09:49:31 openvpn[36387]: /sbin/ifconfig ovpns1 10.230.16.1 10.230.16.2 mtu 1500 netmask 255.255.255.255 up Jan 16 09:49:31 openvpn[36387]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Jan 16 09:49:31 openvpn[36387]: TUN/TAP device /dev/tun1 opened Jan 16 09:49:31 openvpn[36387]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Jan 16 09:49:31 openvpn[36387]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jan 16 09:49:31 openvpn[36387]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011 Jan 16 09:49:30 openvpn[34770]: SIGTERM[hard,] received, process exiting Jan 16 09:49:30 openvpn[34770]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1557 10.230.16.1 10.230.16.2 init Jan 16 09:49:30 openvpn[34770]: event_wait : Interrupted system call (code=4)comme si mon client n'atteignait jamais le pfSense ???
-
J'ai eu un tuyau, mon souci pourrait provenir d'un changement de master de mon cluster suite au redémarrage à la brute de tout mon rack.
-
Je ne comprend pas bien ce que cela signifie précisément.
En tout cas, vu du client tout se passe comme si en effet il n'atteignait pas le serveur vpn.
Il faut vérifier en premier lieu les points suivants:
Openvpn est bien activé sur wan.
Sur l'interface wan présence d'une règle autorisant UDP/1194 (ou autres ports selon configuration)
Sur l'interface openvpn (c'est pour la suite) les règles autorisant les trafics vers les machines à atteindre.Tentez une connexion client et activez les logs sur tout le trafic wan pour observer l'arrivée éventuelle de ce client vpn. J'ai tendance à penser que ce n'est pas le cas.
-
Je connais bien la config d'origine, et pour cause …
Il s'agit d'un pfsense qui a été passé en cluster (carp) et qui a subi quelques modifs ensuite.Je rappelle le principe du cluster :
on fixe un jeu d'adresses (différents) à chaque hôte du cluster,
puis on définit les "virtual ip" qui seront reçues par le master puis le slave en cas de défaillance.Il est notable que TOUTES les règles NAT ou Rules > WAN doivent alors être revues lors de la mise en cluster
pour changer le "WAN Address" en un alias "ippub"
parce que la "WAN Address" désigne l'adresse de l'interface réelle et non la "virtual ip" reçue par le master du cluster (que j'aliasse en "ippub").Il faut alors un peu de temps pour que les services (tel OpenVpn) écoutent bien sur "ippub".
(CFlorian m'a confirmé que le pb était résolu même s'il avait ajouté des règles de contournement en attendant la bonne solution !)
-
Je confirme la résolution du cas ;).