4 votes

Pfsense pair à pair OpenVPN ne se connecte pas

Je cherche à configurer une connexion OpenVPN peer-to-peer entre deux serveurs pfsense exécutant la version 2.0.1-RELEASE, mais le client continue de perdre la connexion, avec un statut de "reconnexion; ping-restart" et rien ne semble être acheminé entre eux. Ces pare-feu gèrent également des VPN PPTP qui fonctionnent correctement.

FW01 ("serveur")
=======================
LAN : 10.1.1.2/24
WAN : xx.xx.126.34/27
Mode Serveur : Peer to Peer (Clé partagée)
Protocole : UDP
Mode Appareil : tun
Interface : WAN
Port 1194
Tunnel : 10.0.8.1/30
Réseau Local : 10.1.1.0/24
Réseau Distant : 192.168.1.0/24
Règle de pare-feu dans l'onglet OpenVPN : UDP \* \* \* \* \* none

FW03 (client)
LAN : 192.168.1.2/24
WAN : xx.xx.9.66/27
Mode Serveur : Peer to Peer (Clé partagée)
Protocole : UDP
Mode Appareil : tun
Interface : WAN
Hôte du Serveur : xx.xx.126.34
Tunnel : -- également essayé 10.1.8.0/24
Réseau Distant : 10.1.1.0/24

Journaux du client :

Journal Système
6 avril 18:00:08 kernel: ... Redémarrage des packages.
6 avril 18:00:13 check\_reload\_status: Démarrage des packages
6 avril 18:00:19 php: : Redémarrage/Démarrage de tous les packages.
6 avril 18:00:56 kernel: ovpnc1: l'état du lien a changé à DOWN
6 avril 18:00:56 check\_reload\_status: Rechargement du filtre
6 avril 18:00:57 check\_reload\_status: Rechargement du filtre
6 avril 18:00:57 kernel: ovpnc1: l'état du lien a changé à UP
6 avril 18:00:57 check\_reload\_status: rc.newwanip démarrage de ovpnc1
6 avril 18:00:57 check\_reload\_status: Synchronisation du pare-feu
6 avril 18:01:02 php: : rc.newwanip : Informationnel démarre ovpnc1.
6 avril 18:01:02 php: : rc.newwanip : on (adresse IP : ) (interface : ) (interface réelle : ovpnc1).
6 avril 18:01:02 php: : rc.newwanip : Échec de la mise à jour de l'IP, redémarrage...
6 avril 18:01:02 php: : send\_event: envoyé l'interface reconfigure a obtenu ERREUR : commande incomplète. tous rechargement reconfigure redémarrage newip linkup sync
    Journal OpenVPN du client
6 avril 18:39:14 openvpn\[12177\]: Délai d'inactivité (--ping-restart), redémarrage
6 avril 18:39:14 openvpn\[12177\]: SIGUSR1\[soft,ping-restart\] reçu, processus redémarré
6 avril 18:39:16 openvpn\[12177\]: Remarque : le réglage actuel de --script-security peut permettre à cette configuration d'appeler des scripts définis par l'utilisateur
6 avril 18:39:16 openvpn\[12177\]: Réutilisation de la clé statique pré-partagée
6 avril 18:39:16 openvpn\[12177\]: Préservation de l'instance TUN/TAP précédente : ovpnc1
6 avril 18:39:16 openvpn\[12177\]: Lien local UDPv4 (lié) : \[AF\_INET\]64.94.9.66
6 avril 18:39:16 openvpn\[12177\]: Lien distant UDPv4 : \[AF\_INET\]64.74.126.34:1194
    Journal OpenVPN du serveur
6 avril 14:40:36 openvpn\[22117\]: Lien distant UDPv4 : \[non défini\]
6 avril 14:40:36 openvpn\[22117\]: Lien local UDPv4 (lié) : \[AF\_INET\]xx.xx.126.34:1194
6 avril 14:40:36 openvpn\[21006\]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1557 10.1.8.1 10.1.8.2 init
6 avril 14:40:36 openvpn\[21006\]: /sbin/ifconfig ovpns1 10.1.8.1 10.1.8.2 mtu 1500 netmask 255.255.255.255 up
6 avril 14:40:36 openvpn\[21006\]: do\_ifconfig, tt->ipv6=0, tt->did\_ifconfig\_ipv6\_setup=0
6 avril 14:40:36 openvpn\[21006\]: Périphérique TUN/TAP /dev/tun1 ouvert
6 avril 14:40:36 openvpn\[21006\]: Authentification du Canal de Contrôle : utilisation de '/var/etc/openvpn/server1.tls-auth' comme fichier de clé statique OpenVPN
6 avril 14:40:36 openvpn\[21006\]: Remarque : le réglage actuel de --script-security peut permettre à cette configuration d'appeler des scripts définis par l'utilisateur
6 avril 14:40:36 openvpn\[21006\]: OpenVPN 2.2.0 amd64-portbld-freebsd8.1 \[SSL\] \[LZO2\] \[eurephia\] \[MH\] \[PF\_INET6\] \[IPv6 payload 20110424-2 (2.2RC2)\] construit le 11 août 2011
6 avril 14:40:36 openvpn\[17171\]: SIGTERM\[hard,\] reçu, processus en cours de fermeture
6 avril 14:40:36 openvpn\[17171\]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1557 10.1.8.1 10.1.8.2 init
6 avril 14:40:36 openvpn\[17171\]: ERREUR : la commande de suppression de route FreeBSD a échoué : le programme externe s'est terminé avec un code d'erreur : 1
6 avril 14:40:36 openvpn\[17171\]: event\_wait : Appel système interrompu (code=4)
6 avril 14:06:32 openvpn\[17171\]: Séquence d'initialisation terminée
6 avril 14:06:32 openvpn\[17171\]: Lien distant UDPv4 : \[non défini\]
6 avril 14:06:32 openvpn\[17171\]: Lien local UDPv4 (lié) : \[AF\_INET\]xx.xx.126.34:1194

5voto

Chris Buechler Points 2926

Très probablement parce que le client ne peut pas communiquer avec le serveur sur l'UDP 1194. Pourquoi, il existe un certain nombre de possibilités à vérifier, deux les plus courantes:

  • aucune règle de pare-feu autorisant le trafic
  • 1:1 NAT ou redirection de port redirigeant ce trafic ailleurs

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X