Problème Nat avec OPENVPN
-
Bonjour,
Tout dabord je vais expliquer mon infrastructure.
J'ai ma connexion internet depuis un routeur CISCO de mon FAI et qui a une adresse fixe, j'ai installer pfsense et j'ai brancher le port WAN avec l'adresse 192.168.1.X et l'autre LAN avec l'adresse 192.168.200.X
J'ai voulu configurer un serveur OPENVPN, mais je vois qu'aprés la configuration, openvpn essaye d'utiliser l'adresse 192.168.1.X et non pas l'adresse PUBLIC du routeur.
Donc il n'y a pas une solution au niveau du NAT pour que ça fonctionne ?
NB: avant j'ai utilisé PPTP et ça fonctionné.
Merci -
Vous n'êtes pas débutant, donc vous devriez avoir lu A LIRE EN PREMIER, et donc présenter une question sous ce format !
D'après ce que vous présentez (mal),
- quel matériel dispose de l'adresse ip publique ?
- par conséquence, avez vous agit sur ledit matériel pour que le flux arrive au pfSense ?
Il me parait hautement improbable que cela ait pu fonctionner pour PPTP (qui est un protocole de VPN à bannir totalement).
Parce que, de façon évidente, il faut faire quelque chose (comme en 2) sur la machine (en 1) quel que soit le protocole de VPN choisi ! -
J'ai voulu configurer un serveur OPENVPN, mais je vois qu'aprés la configuration, openvpn essaye d'utiliser l'adresse 192.168.1.X et non pas l'adresse PUBLIC du routeur.
Donc il n'y a pas une solution au niveau du NAT pour que ça fonctionne ?Je ne comprends pas ce que signifie "openvpn essaye d'utiliser l'adresse 192.168.1.X"
Le serveur OpenVPN n'essaie d'utiliser aucune adresse. Il écoute sur les interfaces que tu lui as configuré, LAN, WAN, Localhost etc… et tes clients OpenVPN viennent se connecter sur cette adresse.
Du coup, un client externe va arriver sur l'interface publique du routeur Cisco qui doit rediriger ce flux vers l'interface 192.168.1.x de pfSenseBien sûr, si tu utilises le package openvpn-client-export, celui-ci ne connait que l'IP sur laquelle le serveur écoute. Il faut donc configurer manuellement l'IP publique (ou le fqdn) si tu veux générer une conf pour tes clients OpenVPN 8)
-
Pour ce qui concerne le mat"riel ip public.
c'est un routeur cisco.
Et pour openVPN dans la partie client, il essaye de se connecter à l'adresse locale du pfsense.
Je répété que pfsense n'est pas connecté directement à internet. l'internet passe dabord par un routeur CISCO -
(On a pas encore la présentation que je recommande …)
On a avancé :
D'après ce que vous présentez (mal),
- quel matériel dispose de l'adresse ip publique ? CISCO
- par conséquence, avez vous agit sur ledit matériel pour que le flux arrive au pfSense ?
Maintenant, il faut répondre à la deuxième question ...
D'ailleurs vous l'écrivez vous-même 'Je répété que pfsense n'est pas connecté directement à internet'
-
non j'ai pas agis sur l'edit materiel, tout ce que je peux faire au niveau du materiel c'est que je peux ouvrir les ports.
Le fournisseur m'interdit de faire une modification à leur matériel -
Donc, comme je le disais, ton serveur OpenVPN est correctement configuré pour écouter sur l'interface WAN de pfSense.
Le package d'assistance à la création des bundle client prend par défaut l'IP de la conf du serveur pfSense. Mais tu DOIS le modifier pour remplacer ça par ton IP publique ou un fqdn si à cette IP correspond une entrée DNS.Et il faut sur le routeur cisco rediriger le flux entrant sur le port que tu as configuré pour que ce flux arrive sur l'interface WAN de pfSense. C'est tout ;)
-
Le fournisseur m'interdit de faire une modification à leur matériel
Si le fournisseur ne permet pas de faire un renvoi de trafic, il FAUT en changer …
J'ai indiqué les 2 premières étapes, une 3ième a été indiqué :
- CISCO
- transfert de flux à faire dans le CISCO
- paramétrer le client
Tout cela est basique ...
-
J'ai changé ma connexion, maintenant je peux faire la modification au niveau de mon modem.
ce que j'ai fait dans le fichier de configuration openVPN c'est que j'ai changer l'adresse locale par celle publique comme l'indique ici :dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote """""ADRESSE PUBLIQUE"""" 1194 udp
lport 0
verify-x509-name "splendid-annex.local" name
auth-user-pass
pkcs12 pfSense-udp-1194-VPN.p12
tls-auth pfSense-udp-1194-testVPN-tls.key 1
remote-cert-tls serveret dans la pièce jointe ma configuration modem.
Mais voici la résultat du connexion :
Wed Nov 15 15:59:28 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Wed Nov 15 15:59:28 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Nov 15 15:59:28 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Wed Nov 15 15:59:31 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]"""ADRESSE PULIQUE""":1194
Wed Nov 15 15:59:31 2017 UDP link local (bound): [AF_INET][undef]:0
Wed Nov 15 15:59:31 2017 UDP link remote: [AF_INET]""""ADRESSE PUBLIQUE""":1194
Wed Nov 15 16:00:32 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Nov 15 16:00:32 2017 TLS Error: TLS handshake failed
Wed Nov 15 16:00:32 2017 SIGUSR1[soft,tls-error] received, process restarting
-
Il y a 3 étapes :
- identifier le boitier qui est entre Internet et WAN : fait : CISCO
- renvoyer le trafic dans ce boitier : fait : à corriger UDP seulement
- configurer le client : à affiner (évidemment l'ip publique, mais vérifier les 'sous' protocoles …)
-
J'ai pas bien compris la 3éme étape
-
La 3ième étape concerne la correspondance entre config client et config serveur : adresse ip publique côté client, ….
Chaque ligne de la config client doit correspondre à ce qui est prévu d'après la config côté serveur :
exemple :
coté Serveur : si Use TLS coché, le contenu de TLS Key doit être dans le fichier indiqué à la ligne 'tls-auth fichier 1' côté client
et ainsi de suite ...Puisque vous n'avez fourni que TRES peu d'informations ...
Ici il aurait fallu une copie d'écran de VPN > OpenVPN ... pour vérifier si votre conf client est correcte (mais je n'ai pas le temps ...).(J'ai une ligne 'proto udp' dans mes fichiers de conf et pas 'udp' sur la ligne 'remote' ...)
-
Pour La partie Serveur











 -
Partie Client export:



 -
juste demandez moi ce que vous voulez et je vais faire un imprime écran
-
Sur la première copie d'écran que tu montre, "client connection behavior" / "hostname resolution" contient "interface IP address"
C'est de champ qu'il faut modifier pour y mettre ton IP publique afin que ton client pointe sur la bonne adresse.Je ne sais pas comment l'expliquer mieux que ça ::)
Ensuite, vérifie donc que la requête de ton client arrive bien au serveur OpenVPN, coté pfSense
-
Toujours la meme chose:
Sat Nov 18 09:31:02 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Nov 18 09:31:02 2017 TLS Error: TLS handshake failed
Sat Nov 18 09:31:02 2017 SIGUSR1[soft,tls-error] received, process restartingVraiment ça m’embête. je l'ai fais sur un CENTOS mais avec pfsense….
-
Usuellement TLS-ERROR vient du fait que la clé du fichier n'est pas celle de la config server.
Avez-vous vérifié ? Voire refait votre fichier ?
Voire ajusté la nego ? (le plus simple c'est pas de négo = 1 seul protocole)Si vous attendez que ça vous tombe tout cuit …
(Perso j'ai eu une expérience malheureuse avec Client Export, donc je fait à la main : copie, création d'un fichier, ...)
-
Vous pouvez m'expliquer svp un peut plus.
Merci
Et est ce que c'est normale que j'ai pas Shared Key Server??
 -
Ce n'est ni anormal, ni normal. C'est une question de choix de configuration. Comme vous gérez des certificats propres à chaque utilisateur, c'est cohérent. Mais cela montre que vous ne comprenez pas bien le fonctionnement de la partie VPN SSL
Dans vos paramétrages, SHA1 est à proscrire car défaillant aujourd'hui.
Il me semble que vos paramètres sont incorrects. Relisez donc ce que vois dit jdh …