Problème OpenVPN ping depuis réseau local vers tunnel VPN



  • Bonjour à tous et à toute.

    D'un niveau plutôt intermédiaire sur Pfsense, Je viens vers vous afin de m'aider sur une problématique qui m'échappe totalement…

    Situation
    Mon entreprise à besoin d'un VPN, afin de permettre aux utilisateurs en déplacement de pouvoir accéder au serveur local.

    Matériel
    Pfsense version 2.3.1 -RELEASE-p5 (amd64) sous Hyper-v
    Routeur SRX 100H (Liaison FAI)

    Schéma réseau (minimalisé pour la situation):

    Fichier configuration du serveur.conf OpenVPN
    dev ovpns1
    verb 1
    dev-type tun
    plus tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto tcp-server
    cipher AES-256-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local 192.168.0.27
    tls-server
    server 10.255.255.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    username-as-common-name
    auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'VPN-ServerCert' 1"
    lport 5150
    management /var/etc/openvpn/server1.sock unix
    push "route 192.168.0.0 255.255.0.0"
    push "dhcp-option DOMAIN domaine.local"
    push "dhcp-option DNS 192.168.0.16"
    push "dhcp-option DNS 192.168.0.9"
    push "dhcp-option DNS 8.8.8.8"
    client-to-client
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    persist-remote-ip
    float
    topology subnet

    Fichier configuration client.ovpn
    dev tun
    persist-tun
    persist-key
    cipher AES-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote IP PUBLIQUE 5150 tcp-client
    lport 0
    verify-x509-name "VPN-ServerCert" name
    auth-user-pass auth.txt
    pkcs12 PFsense-OPENVPN-TCP-5150-user-vpn.p12
    tls-auth PFsense-OPENVPN-TCP-5150-user-vpn-tls.key 1
    ns-cert-type server

    En résumé.
    IP local: 192.168.0.0/24
    IP tunnel VPN: 10.255.255.0/24
    PFsense n'a PAS de liaison WAN!!!!
    OpenVPN est sous le port 5150

    Règles PFsense
    lan: autoriser le trafic pour le port 5150 en TCP(wizard OpenVPN) + tout autoriser
    OpenVPN: tout autoriser (wizard OpenVPN)

    Route de Pfsense

    Pour les Gateway:
    link#4 correspond à lo0 (127.0.0.1)
    link#6 correspond à hn1. le LAN de pfsense (192.168.0.27)
    link#7 correspond à la liaison virtuel de OpenVPN ovpn1 (10.255.255.1)

    Problème
    Les postes clients à l’extérieur du réseau local arrive à ce connecter au VPN sans aucun problème, à naviguer dans le réseau et à ping.
    A l'inverse, les poste à l’intérieur du réseau local n'arrive pas à communiquer avec les postes en VPN.

    Pour résumer nous avons:
    poste 10.255.255.0/24 ==ping ok + navigation==> poste 192.168.0.0/24
    poste 192.168.0.0/24  ==no ping et impossible de contacter==> poste 10.255.255.0/24

    Ceci est problématique car nous avons quelque serveur hébergé en externe qui ne peuvent pas fonctionner correctement car les serveurs situé dans le réseau local n'arrive pas à communiquer avec eux….

    Pour info.
    La gateway des postes en réseau local est le routeur FAI (192.168.0.1), mais celui ci possède bien une règle qui redirige les requêtes vers 10.255.255.0/24 vers le serveur Pfsense(192.168.0.27)
    10.255.255.0/24 *[Static/5] 2w2d 00:31:14

    to 192.168.0.27

    Voilà,
    En espérant avoir était le plus clair possible.
    N'hésitez pas à demander si vous avec besoin d'information supplémentaire.

    D'avance, merci.



  • Les postes clients à l’extérieur du réseau local arrive à ce connecter au VPN sans aucun problème, à naviguer dans le réseau et à ping.
    A l'inverse, les poste à l’intérieur du réseau local n'arrive pas à communiquer avec les postes en VPN.

    C'est tout à fait normal.

    mais celui ci possède bien une règle

    Une route ! Quid du retour ?

    Dans votre configuratoin :

    auth SHA1

    A proscrire. cet algorithme est considéré comme compromis.

    PFsense n'a PAS de liaison WAN!!!!

    Là je ne comprend plus. Comment les nomades accèdent au vpn ?



  • Salut et merci de ton retour.

    mais celui ci possède bien une règle
    Une route ! Quid du retour ?

    Oui pardon, je l'ai mis un peux plus bas dans ma description, j'aurai du l'écrire de suite après.
    (à noter que je n'ai pas accès à ce routeur. Il appartient à un FAI(modification à faire via ticket))
    La règle en question:
    10.255.255.0/24 *[Static/5] 2w2d 00:31:14

    to 192.168.0.27

    auth SHA1
    A proscrire. cet algorithme est considéré comme compromis.

    Je t'avouerai que cet ligne est la par défaut, je n'y ai juste pas touché.

    PFsense n'a PAS de liaison WAN!!!!
    Là je ne comprend plus. Comment les nomades accèdent au vpn ?

    Grâce à la règle sur le routeur FAI qui redirige les requêtes utilisant le port 5150(port utiliser pour OpenVPN) vers le serveur PFsense.

    Les postes clients à l’extérieur du réseau local arrive à ce connecter au VPN sans aucun problème, à naviguer dans le réseau et à ping.
    A l'inverse, les poste à l’intérieur du réseau local n'arrive pas à communiquer avec les postes en VPN.
    C'est tout à fait normal.

    Mhhhh, n'est il normalement pas possible de ping et d'accéder à des postes clients externe au réseau qui ont accès au réseau local via le tunnel VPN?

    Merci.



  • @ccnet:

    PFsense n'a PAS de liaison WAN!!!!

    Là je ne comprend plus. Comment les nomades accèdent au vpn ?

    pfSense n'est pas utilisé pour sa fonction "firewall" mais juste parce qu'il y a une interface graphique pour le serveur VPN  ;)



  • Ceci est problématique car nous avons quelque serveur sous OVH qui ne peuvent pas fonctionner correctement car les serveurs situé dans le réseau local n'arrive pas à communiquer avec eux….

    Je ne comprend pas non plus de quoi il s'agit …Les clients du lan auraient besoin de joindre les nomades ? Pour quoi faire ?
    Êtes vous certain de vos masques dans le réseau VPN ? Le tunnel vpn n'est généralement pas en /24. Chaque pc est dans un /30 jusqu'à très récemment.

    (à noter que je n'ai pas accès à ce routeur. Il appartient à Jaguar Network(modification à faire via ticket))

    Il faudrait en connaitre la configuration de routage.

    10.255.255.0/24 *[Static/5] 2w2d 00:31:14 > to 192.168.0.27

    Je ne comprend ce que cela signifie. Pour moi ce n'est pas comme cela que l'on écrit une route.
    Par ailleurs, sur le principe, ce n'est pas depuis le routeur que l'on peut espérer joindre une machine au bout du vpn. Sinon ce n'est plus un vpn !



  • @chris4916:

    @ccnet:

    PFsense n'a PAS de liaison WAN!!!!

    Là je ne comprend plus. Comment les nomades accèdent au vpn ?

    pfSense n'est pas utilisé pour sa fonction "firewall" mais juste parce qu'il y a une interface graphique pour le serveur VPN  ;)

    Dans l’éventualité où je n’aurais pas compris…
    Ces approximations sont assez agaçantes. Bien sur que Pfsense est connecté via le routeur ! D'où mon commentaire au second degré.



  • Je ne comprend pas non plus de quoi il s'agit …Les clients du lan auraient besoin de joindre les nomades ? Pour quoi faire ?
    Êtes vous certain de vos masques dans le réseau VPN ? Le tunnel vpn n'est généralement pas en /24. Chaque pc est dans un /30 jusqu'à très récemment.


    Inutile d'expliquer pourquoi les serveurs LAN ont besoin d'accéder de temps en temps au serveurs externe (hors réseau donc), il y a bien une raison, mais inutile pour le sujet.

    à noter que je n'ai pas accès à ce routeur. Il appartient à un FAI(modification à faire via ticket))
    Il faudrait en connaitre la configuration de routage.

    Je connais bien la configuration du routeur. Mais les lignes suivantes contiennent mon IP publique et d'autre route inutile au VPN.
    Inutile donc d'encombrer le post la dessus.

    10.255.255.0/24 *[Static/5] 2w2d 00:31:14 > to 192.168.0.27
    Je ne comprend ce que cela signifie. Pour moi ce n'est pas comme cela que l'on écrit une route.

    C'est la ligne du routage du routeur FAI qui est afficher lors du "show route", je suis bien d'accord que la ligne est ….. moche, mais c'est bien ce qui est afficher.
    En gros tout le réseau 10.255.255.0/24 est redirigé vers la liaison LAN de PFsense.

    Par ailleurs, sur le principe, ce n'est pas depuis le routeur que l'on peut espérer joindre une machine au bout du vpn. Sinon ce n'est plus un vpn !

    Le routeur est la passerelle par défaut de mon réseau local.
    si je veux ping une adresse situé dans le VPN il faut bien que je redirige  la requête vers PFsense.  non ?

    Merci

    PS: J'ai rajouter dans le sujet les route de Pfsense.

    Pour les Gateway:
    link#4 correspond à lo0 (127.0.0.1)
    link#6 correspond à hn1. le LAN de pfsense (192.168.0.27)
    link#7 correspond à la liaison virtuel de OpenVPN ovpn1 (10.255.255.1)



  • Ceci est problématique car nous avons quelque serveur sous OVH qui ne peuvent pas fonctionner correctement car les serveurs situé dans le réseau local n'arrive pas à communiquer avec eux….

    Quel rapport entre d'une part les serveurs du lan qui accèdent aux serveurs chez OVH et d'autre part les clients vpn ?
    Sur le schéma les postes clients sont des clients ou des serveurs ?
    Par ailleurs les clients vpn ne sont pas en écoute sur le port TCP 5150. Vous ne pourrez pas joindre un client VPN sur ce port.

    Essayez de regarder ce qui se passe sur les interfaces de Pfsense, en particulier lan pour commencer…



  • Par ailleurs les clients vpn ne sont pas en écoute sur le port TCP 5150. Vous ne pourrez pas joindre un client VPN sur ce port.


    Rien ne t'empêche et changer le port d'écoute du VPN. (pour preuve il fonctionne)

    Quel rapport entre d'une part les serveurs du lan qui accèdent aux serveurs externe et d'autre part les clients vpn ?
    Sur le schéma les postes clients sont des clients ou des serveurs ?

    Ne te focalise pas sur les clients VPN et les serveurs externe qui utilise le VPN aussi. C'est exactement la même chose et la même problématique.

    Je te ferai un packet capture du LAN quand j'essaie de ping une adresse VPN lundi, la je n'ai plus accès au serveur (we oblige).

    Merci à toi.



  • @ccnet:

    Par ailleurs, sur le principe, ce n'est pas depuis le routeur que l'on peut espérer joindre une machine au bout du vpn. Sinon ce n'est plus un vpn !

    Ce que veut dire KaïlasTheUseless, c'est que comme la gateway par défaut des client du LAN, c'est le routeur, il espérait, en mettant une route sur ce routeur, rediriger les requêtes vers le serveur VPN.

    C'est une approche qui fonctionne lorsque le routeur VPN n'est pas sur la gateway par défaut et qu'on ne veut pas publier une route sur chaque client sur le LAN (ce qui est une autre approche).



  • Ce fil est mal parti du fait qu'une solution est posée avant d'avoir vraiment réfléchi aux alternatives possibles suite au besoin.

    Le besoin :

    • accéder depuis l'extérieur, via un tunnel VPN, au réseau interne

    Le contexte :

    • le routeur, entre LAN et Internet, n'est pas managé et n'est pas changeable !

    Ce contexte rend quasi-caduque pfSense car la config, le fonctionnement de pfSense est d'avoir 2 interfaces (WAN et LAN).
    Tout va dans ce sens …

    Il est notable qu'un serveur OpenVpn (sous Linux) est capable de faire le job correctement ...
    sous réserves EXPRESSE de réaliser la règle iptables nécessaire 'iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE' !
    cf l'importante doc https://community.openvpn.net/openvpn/wiki/BridgingAndRouting section 'Using routing and OpenVPN not running on the default gateway'

    M'est avis que le plus simple est de fonctionner à partir d'un serveur Linux (Debian) en respectant cette doc, et en gérant les certificats.

    (Perso, sur un de mes sites, dont je ne gère pas/peu le firewall, j'agis de cette façon, avec une VM Debian, et cela fonctionne très bien.)



  • Salut Jdh,

    J'avais pensé au serveur OpenVPN via un simple serveur sous Ubuntu.
    J'en parlerai à mon responsable qui voulait tester PFsense.

    Si j'ai bien compris, on peux pas utiliser PFsense comme un routeur interne? (avec juste le LAN?) Dommage.



  • @KaïlasTheUseless:

    J'en parlerai à mon responsable qui voulait tester PFsense.

    En allant au bout de cette démarche : avec ce montage, tu ne testes justement pas pfSense puisque seul le composant OpenVPN est vraiment utilisé.
    Techniquement, j'exagère un peu en écrivant ça car la couche packet filter est également impliquée mais concrètement, avec ce design, les possibilités de test sont réduites à presque rien.

    @KaïlasTheUseless:

    Si j'ai bien compris, on peux pas utiliser PFsense comme un routeur interne? (avec juste le LAN?) Dommage.

    Un "routeur" à une seule interface ?  ;) il ne va pas router grand chose  :P

    A la limite, pour vraiment tester pfSense (ça s'écrit pfSense et pas PFsense  ;) ), sans changer la conf du routeur à laquelle tu n'as pas accès, il faudrait intercaler le FW entre le routeur et le LAN.

    Avec une seule interface, techniquement ça doit fonctionner mais il y a des soucis, comme discuté plus haut dans le fil, peut-être avec le plan d'adressage (je n'ai pas regardé le détail) et la route retour. Lorsque tu accèdes à un service sur le LAN depuis un client OpenVPN, le client accède directement au service qui voit les paquets arriver depuis l'IP de pfSense et le service répond dans cette direction.
    Lorsque tu veux accéder à un client OpenVPN depuis le LAN, la default gateway est le routeur qui redirige vers pfSense mais lorsque les paquets reviennent du client, comme celui-ci est sur le même LAN que pfSense, pfSense renvoie directement au client qui dit "c'est quoi ces paquets retour qui viennent d'une machine à qui je ne m'adresse pas ?"

    Fait donc un essai avec un client sur lequel tu as manuellement forcé une router vers pfSense pour le subnet correspondant à tes clients  OpenVPN  ;)

    Mais c'est juste pour le coté didacticiel car, encore une fois, utiliser pfSense comme serveur OpenVPN uniquement, ce n'est pas forcément un choix très judicieux, même si je comprends bien l'avantage d'avoir une interface graphique qui cumule le serveur OpenVPN et la gestion des certificats et des comptes.



  • Le lien que je cite, avec la section précise, correspond exactement à la situation.

    Le point clé est que le serveur OpenVpn n'est pas le routeur du réseau local.
    D'où l'astuce de la règle iptables de masquerade : le flux venant des clients vpn est vu, pour les machines du lan; comme venant du serveur Openvpn.

    Je ne pense pas simple de faire la règle équivalente sur pfSense.

    Concernant la gestion de certificats, Openvpn fournit des scripts 'EasyRSA' pour la création : de nombreux tutos existent.

    Moralité : pour tester pfSense, il faut le tester dans une config normale et non biaisée !
    Ici c'est une mauvaise situation de test, comme ceux qui veulent le tester comme simple proxy …

    NB : dans mon cas, j'ai repris la gestion d'un site qui a un firewall (fortinet) avec plusieurs clients vpn.
    Je gère plusieurs sites avec pfSense, et il est aisé de créer un certificat serveur par serveur pfSense pour que les certificats users soit valables pour chacun des sites (et non un certificat user par site !).
    Du fait, la VM ajouté sur le site, utilise un certificat serveur, d'où pas de besoin de certificats locaux.


Log in to reply