[Résolu]Aucun trafic OpenVPN (tun)

[Dimix971]

Bonjour,

Contexte : Pro, Étudiant, Nouveau, pfsense installé sur HYPER-V
Besoin : Accéder au réseau de l'entreprise

Schéma : Toutes les interfaces possèdent leur propre carte réseau virtuelle
WAN: 192.168.15.x/22
LAN: 192.168.10.x/24
SYNC: 10.0.10.254/24 FAILOVER

Configuration OpenVPN : Mon serveur OpenVPN est en accès à distance (Authentification utilisateur via RADIUS) sur mon interface WAN sur le port 5134 avec une adresse de tunnel 10.1.5.0/24.
Les réseaux accessibles à travers ce VPN ont été renseigner dans la section Réseaux(x) local/locaux IPv4. Serveur DNS et NTP sont également renseignés.
En ce qui concerne les règles, tout à été automatiquement générer par l'assistant (que je compte adapté par la suite).
NB : je possède sur ce même pfsense un deuxième serveur VPN (tap) qui fonctionne correctement mais qui n'est pas compatible avec les appareils sous iOS

Problème : Après la connexion d'une tablette ou téléphone (iOS), je n'ai pas accès au réseau de l'entreprise que ce soit serveur ou en réalisant des ping.

Trouvez ci-joint une capture des routes générer par le serveur que je trouve anormal dans le sens ou la gateway fournie pour accéder au réseau 10.1.5.0/24 ne correspond pas à l'adresse du tunnel mais à l'adresse d'un client connecter.

Piste imaginée : Problème de gateway mais je ne sais pas comment la modifier sur un VPN

Je reste à votre disposition si vous avez besoin de plus de précision
Cordialement

[ccnet]

Quelle règle sur l'interface Ovpn ?

[Dimix971]

Voici les règles générées par l'assistant sans compter la première.

[ccnet]

C'est donc ok de ce côté.

[Dimix971]

Je me suis connecter au VPN via un PC portable connecter à un réseau 4G pour réaliser des tests.

Du coup lorsque je fais un traceret vers l'IP d'un serveur présent sur le LAN, j'obtiens le résultat suivant (voir capture). Du coup le trafic n'est pas envoyé vers le LAN du pfsense.
Étant dans un environnement de test, je n'ai pas modifié les règles du LAN (voir capture).


[jdh]

Un client OpenVPN a un log : qu'y a-t-il dans ce log ?
Nécessairement le client doit ajouter une route : cette règle est-elle ajoutée ? (route print)

Ensuite, il faut regarder les règles de l'onglet 'OpenVPN'.
Et il faut écrire correctement les règles : si on a configuré OpenVPN avec un réseau ip pour les clients, on DOIT lire ce réseau dans les règles !!
(Parce 2 règles * * * c'est pas sérieux …)

[Dimix971]

@jdh:

Un client OpenVPN a un log : qu'y a-t-il dans ce log ?

Voici le log du client OpenVPN exécuter en tant qu'administrateur

@jdh:

Nécessairement le client doit ajouter une route : cette règle est-elle ajoutée ? (route print)

Ci-joint le route print. La route pour atteindre le réseau cible a bien été ajouter "192.168.10.0" avec comme passerelle le tunnel VPN "10.1.5.1"

@jdh:

Ensuite, il faut regarder les règles de l'onglet 'OpenVPN'.
Et il faut écrire correctement les règles : si on a configuré OpenVPN avec un réseau ip pour les clients, on DOIT lire ce réseau dans les règles !!
(Parce 2 règles * * * c'est pas sérieux …)

Bien évidemment les règles comme dit dans le premier post, vont être adaptées par la suite. Je vais donc faire ce que vous me recommandez et je vous ferais un retour dans la semaine car j'ai une urgence de dernière minute à régler. Et encore merci pour votre retour.


[jdh]

Les clients VPN que j'utilise sont en 2.3 et non 2.4.
Et les config serveurs utilisent des certificats, le TLS renforcé (reco OpenVPN) et l'utilisation d'UDP (reco OpenVpn pour cause de perf)
Donc j'ai dans mes logs des lignes :
UDPv4 link local: et remote:  lien en UDP
TLS:  TLS renforcé
VERIFY OK:  vérif des certificats
ROUTE_GATEWAY:  je ne comprends pas celle là puisque c'est la gateway locale client
TAP-Windows Driver :  début de config de l'interface TAP (tun)
TEST ROUTES:
c:\windows\system32\route.exe add  : ici on ajoute la route 'pushée'
ROUTE: … succeded    : c'est bon

Votre log me semble donc incomplet mais correct (pour la partie fournie).
La table de routage est correcte (pour la partie fournie : des routes permanentes restent parfois, je les supprime régulièrement 'route DELETE').
Toutefois votre adressage LAN client est inhabituel : /29 est rare !
Avez vous testé en câble croisé sur le WAN ?
Dans Firewall > Rules > onglet WAN, bien évidemment il doit y avoir la règle d'accept pour proto/port choisi sur @ip WAN.

A priori côté client ce serait bon.
Les règles gagnent à être écrites correctement dès le départ : pourquoi * alors que l'on connait et les @ip fournis au client et l'@ip du LAN accédé ?

Le log côté serveur doit aussi être examiné ainsi que le statut : Status > System Logs et Status > OpenVpn.

Attention à bien vérifier que les machines dans le LAN ont bien comme gateway le pfSense ...
ce serait bête qu'un ping (icmp request) soit répondu (icmp reply) dans une autre direction ...
NB : pinger l'ip LAN de pfSense ne donne aucune information ...

[Dimix971]

Bonjour,

Je suis désolé pour cette réponse très tardive.
Du coup j'ai rajouté des règles cohérentes vérifier les logs côté serveur et client sans trouver de problème.

@jdh:

La table de routage est correcte (pour la partie fournie : des routes permanentes restent parfois, je les supprime régulièrement 'route DELETE').

Je me suis donc orienté vers les routes permanentes comme vous me l'aviez mentionné. Et le problème venait bel est bien de la.
Après avoir supprimé les routes manuellement je me suis rendu compte qu'une tâche planifiée (mise en place par l'ancien alternant) exécutais des routes add toutes les 10 minutes vers un routeur et non vers le pfSense. Du coup les réponses partaient dans une autre direction (le routeur en question n'a et n'aura pas de lien avec le firewall).

Une erreur de débutant que j'aurai dû constater bien avant de venir vous solliciter.

Merci pour votre aide
Cordialement

[jdh]

Erreur de débutant ? Oui et non.

Avant de poser une question, on doit, c'est normal et TRES souhaitable, vérifier sa config à fond.
Pour OpenVPN, il y a un 'push route' qui provient du serveur.
D'où la nécessité de lancer le client en mode administrateur, et de réaliser la vérification par 'route print'.
Là, apparaissent les routes permanentes, normalement absentes.

Ce fil a de l'intérêt, car la démarche a été rappelée.