Problème VPN - PFsense-OpenVPN - traffic client



  • Bonjour,

    Totalement débutant, j’ai repris le poste de technicien pour une petite société (200 personnes).
    Nous utilisons Pfsense comme passerelle/firewall/serveur VPN. Je précise que c’était déjà installé et que, bien sûr, celui qui l’a mis en place n’a laissé aucune doc ….

    Mon problème est le suivant :

    Si une personne se connecte au VPN (cadenas vert, adresse IP privée attribuée sur le LAN), via l’extérieur, elle peut contacter notre serveur de fichier mais pas sur notre serveur Web (pour lequel il existe seules les requêtes venant de notre wan sont acceptés) qui est à l’extérieur (IP publique – hébergé chez OVH). Elle reçoit alors un message lui disant qu’elle n’est pas autorisée à contacter ce site mais tout autre site, par exemple ceux de Free ou Google, sont eux accessibles. Je précise qu’il y a encore deux semaines, nous n’avions aucuns soucis avec le VPN et que je n’ai fait aucunes modifications dans la config de PFsense ou de OpenVPN.
    J’ai (essayé) d’utiliser WireShark afin de voir sur quelle interface partent les requêtes. Concernant les sites auxquels j’ai accès, ils passent par l’interface TAP-Windows-Adapter, donc celle du VPN mais lorsque j’essaie de me rendre sur notre serveur web, les requêtes passent par l’interface physique.
    Réseau du Lan : 192.168.16.0
    Réseau du VPN : 192.168.2.0

    Version de PFsense :
    2.2-RELEASE (amd64)
    built on Thu Jan 22 14:03:54 CST 2015
    FreeBSD 10.1-RELEASE-p4

    Wan :
    OVH – 4 paires Xdsl – 1 IP
    Lan :
    2 VLAN (1 data – 1 phonie) - DHCP par PFsense
    Remarque à ce sujet :
    Concernant le DHCP, la plage d’adresse paramétrée va de 192.168.16.100 à 192.168.16.200 mais lorsque je suis connecté via le VPN, en serveur DHCP, j’ai 192.168.2.5 et l’IP de mon client est en 192.168.2.6 …. Est-ce normal ?
    Le 2 s’explique car, dans la configuration du serveur VPN, dans la rubrique Tunnel Settings, encadré IPv4 Tunnel Network, j’ai 192.168.2.0/24. Dans l’encadré IPv4 Local Network, j’ai 192.168.16.0/24
    Lorsque je fais un ping sur 192.168.2.5, je n’ai pas de réponse => délai d’attente de la demande dépassé.

    NAT :
    Dans les règles existantes, 6 au total, aucune ne concernent les VPN.

    Firewall :
    Onglet qui concerne le VPN :
    Une seule règle.
    La case ID est vide. Les cases IPv4 dans Protocole et pour Source, Port, Destination, Gateway = *, la case Queue = none et la case Schedule est vide également.

    Package :
    Pas de package ajouté.

    J’ai fait des recherches internet du le problème et la solution trouvée qui me semblait correspondre au problème (c’est-à-dire forcer le tout le trafic à passer par l’interface VPN) était celle-ci :
    Implementation
    Add the following directive to the server configuration file:
    push "redirect-gateway def1"
    If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:
    push "redirect-gateway local def1"
    Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

    This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.
    When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:
    push "dhcp-option DNS 10.8.0.1"

    Bien sûr avec les IP correspondantes mais sans succès. Le client ne se connecte même plus. Je ne suis pas certain mais je crois que ces commandes reviennent à cocher, dans la configuration du VPN, Redirect Gateway, Force all client generated trafic through the tunnel, non ? J’ai essayé coché ou non coché, sans changement.
    A toutes fins utiles, la réponse d’un IPCONFIG /ALL sur le poste client et le log de connexion, toujours sur le poste client :

    Carte Ethernet Ethernet 2 :

    Suffixe DNS propre à la connexion. . . :
      Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9
      Adresse physique . . . . . . . . . . . : 00-FF-46-EA-81-66
      DHCP activé. . . . . . . . . . . . . . : Oui
      Configuration automatique activée. . . : Oui
      Adresse IPv6 de liaison locale. . . . .: fe80::11dc:ab0c:8175:8a9a%5(préféré)
      Adresse IPv4. . . . . . . . . . . . . .: 192.168.2.6(préféré)
      Masque de sous-réseau. . . . . . . . . : 255.255.255.252
      Bail obtenu. . . . . . . . . . . . . . : vendredi 18 mars 2016 09:51:05
      Bail expirant. . . . . . . . . . . . . : samedi 18 mars 2017 09:51:05
      Passerelle par défaut. . . . . . . . . :
      Serveur DHCP . . . . . . . . . . . . . : 192.168.2.5
      IAID DHCPv6 . . . . . . . . . . . : 33619782
      DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1D-63-60-7F-28-B2-BD-4C-DF-A1
      Serveurs DNS. . .  . . . . . . . . . . : 192.168.16.254
      NetBIOS sur Tcpip. . . . . . . . . . . : Activé

    Carte réseau sans fil Wi-Fi :

    Suffixe DNS propre à la connexion. . . :
      Description. . . . . . . . . . . . . . : Intel(R) Dual Band Wireless-N 7260
      Adresse physique . . . . . . . . . . . : 28-B2-BD-4C-DF-A1
      DHCP activé. . . . . . . . . . . . . . : Oui
      Configuration automatique activée. . . : Oui
      Adresse IPv6 de liaison locale. . . . .: fe80::f57d:ee4c:a3a1:e0a5%9(préféré)
      Adresse IPv4. . . . . . . . . . . . . .: 192.168.43.141(préféré)
      Masque de sous-réseau. . . . . . . . . : 255.255.255.0
      Bail obtenu. . . . . . . . . . . . . . : vendredi 18 mars 2016 09:49:10
      Bail expirant. . . . . . . . . . . . . : vendredi 18 mars 2016 11:45:36
      Passerelle par défaut. . . . . . . . . : 192.168.43.1
      Serveur DHCP . . . . . . . . . . . . . : 192.168.43.1
      IAID DHCPv6 . . . . . . . . . . . : 69776061
      DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1D-63-60-7F-28-B2-BD-4C-DF-A1
      Serveurs DNS. . .  . . . . . . . . . . : 192.168.43.1
      NetBIOS sur Tcpip. . . . . . . . . . . : Activé

    Fri Mar 18 13:16:13 2016 OpenVPN 2.3.6 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec  1 2014
    Fri Mar 18 13:16:13 2016 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
    Enter Management Password:
    Fri Mar 18 13:16:20 2016 Control Channel Authentication: using 'vic-udp-1194-pkormann-tls.key' as a OpenVPN static key file
    Fri Mar 18 13:16:20 2016 UDPv4 link local (bound): [undef]
    Fri Mar 18 13:16:20 2016 UDPv4 link remote: [AF_INET]109.190.87.19:1194
    Fri Mar 18 13:16:20 2016 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
    Fri Mar 18 13:16:20 2016 [alter-frame.com] Peer Connection Initiated with [AF_INET]109.190.87.19:1194
    Fri Mar 18 13:16:23 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Fri Mar 18 13:16:23 2016 open_tun, tt->ipv6=0
    Fri Mar 18 13:16:23 2016 TAP-WIN32 device [Ethernet 2] opened: \.\Global{46EA8166-3E55-4790-8EA5-131FA943BA3E}.tap
    Fri Mar 18 13:16:23 2016 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.2.6/255.255.255.252 on interface {46EA8166-3E55-4790-8EA5-131FA943BA3E} [DHCP-serv: 192.168.2.5, lease-time: 31536000]
    Fri Mar 18 13:16:23 2016 Successful ARP Flush on interface [5] {46EA8166-3E55-4790-8EA5-131FA943BA3E}
    Fri Mar 18 13:16:29 2016 Initialization Sequence Completed
    Fri Mar 18 13:16:29 2016 Start net commands…
    Fri Mar 18 13:16:29 2016 C:\WINDOWS\system32\net.exe stop dnscache
    Fri Mar 18 13:16:34 2016 C:\WINDOWS\system32\net.exe start dnscache
    Fri Mar 18 13:16:34 2016 ERROR: Windows ipconfig command failed: returned error code 2
    Fri Mar 18 13:16:34 2016 C:\WINDOWS\system32\ipconfig.exe /flushdns
    Fri Mar 18 13:16:34 2016 C:\WINDOWS\system32\ipconfig.exe /registerdns
    Fri Mar 18 13:16:37 2016 End net commands...

    Vous remarquerez qu’il n’y as pas de passerelle par défaut sur l’interface TAP (VPN), est-ce normal ?
    Par avance un grand merci à ceux qui pourront de donner une piste de recherche complémentaire.

    En espérant ne pas avoir été trop brouillon et trop long …

    Patrice



  • @PatK:

    En espérant ne pas avoir été trop brouillon et trop long …

    Je t'avoue que j'ai arrêté de lire lorsque j'ai vu que tu t'étais mis à faire du wireshark  :-[

    Si l'accès à ton serveur Web hébergé chez OVH n'est accessible qu'aux machines de ton LAN, il faut que ta connexion sorte par le WAN de ton réseau (puisque c'est sur cette IP que se fait très probablement le controle)
    Un bon moyen d'y arriver, si tu ne forces pas, au niveau de OpenVPN, toutes les communications par le tunnel, c'est de configurer sur ton browser un proxy qui est sur le LAN  ;)



  • Merci  de ta réponse Chris,
    Et désolé si la partie WireShark t'as mis en colère (ou bien c'était juste que c'était trop long ?)  :)
    Donc, pour ta solution, il faudrait que je monte un serveur proxy, j'ai bien compris ?

    Si c'est trop long, c'est que j'ai lu les recommandations aavnt de poster et que, du coup, j'ai voulu donner un mas de détails  ;)



  • Non non non, je ne suis pas en colère  ;D ni même fâché  :P

    et je ne vais certainement pas te reprocher d'avoir suivi les directives.
    juste que ça fait un gros pavé bien long  :-X

    Je ne te dis pas qu'il faut installer un proxy mais que si le contrôle sur ton serveur web se base sur l'adresse IP source et que celle-ci doit correspondre au LAN (en fait au WAN), un bon moyen de faire ça est d'utiliser un proxy sur ton LAN, y compris pour tes clients VPN.

    Sans proxy, voilà ce qui se passe (à mon tour d'écrire un pavé  ;D)

    • ton navigateur va résoudre l'adresse IP de l'URL que tu veux joindre.
    • c'est une machine chez OVH, dont sur internet et pas sur le LAN que tu accèdes via le VPN.
    • dont très probablement tu y accèdes en direct sauf si tu as pris soin dans la conf VPN de dire que toutes les connexions d'un client connecté via VPN passent par le tunnel.

    Avec un proxy sur le LAN (et déclaré dans ton navigateur bien sûr, potentiellement avec le DNS), ton navigateur ne cherche pas à résoudre l'IP mais soumet la requête au proxy qui se charge de la résolution de nom et fait la requête, depuis le LAN.

    Quand j'ai un moment je lirai la suite de ton message initial  ;)



  • Merci encore Chris,

    Je ne suis pas certain de savoir faire pour le proxy (je sais changer les paramètres du proxy dans le navigateur) mais je vais essayer.

    Pour essayer de simplifier:

    Poste client se connecte bien au LAN mais la requête pour le serveur Web, qui doit se faire via notre WAN obligatoirement se fait sur l'interface physique du poste client (en l’occurrence un téléphone pour mes tests) au lieu de passer par l'interface TAP du VPN.

    Je ne sais pas si je suis bien clair …  :)

    En tout cas, un grand merci pour tes réponses :)



  • Pour obliger TOUTES les communications du client à passer par le tunnel, il y a une option dans la configuration du serveur  ;)

    Donc 2 solutions :

    • tu as besoin, par exemple pour des raisons de sécurité, que tout passe par le tunnel => tu choisis cette option dans la conf du serveur OpenVPN
    • tu veux t'assurer uniquement que l'accès au serveur OVH vient du LAN => un proxy HTTP, ça le fait


  • @PatK:

    J’ai fait des recherches internet du le problème et la solution trouvée qui me semblait correspondre au problème (c’est-à-dire forcer le tout le trafic à passer par l’interface VPN) était celle-ci :
    Implementation
    Add the following directive to the server configuration file:
    push "redirect-gateway def1"
    If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:
    push "redirect-gateway local def1"
    Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

    En relisant le détail de ton message initial, c'est effectivement l'idée d'une des solutions.
    Par contre, en terme d'implémentation, c'est beaucoup plus simple : il suffit de cocher, dans la configuration du serveur OpenVPN de pfSense, la case qui dit :

    Redirect gateway    Force all client generated traffic through the tunnel.

    Un des cotés pratiques de pfSense,c'est le fait que ce soit une interface graphique  ;)



  • Bonjour Chris,

    L'option "Redirect gateway" est coché, d'où mon désarroi …. :-)

    Je suis tellement newbi en la matière que je n'utilise que l'interface graphique  ;-)

    Bonne journée !

    Pat'



  • Tu peux tout faire avec l'interface graphique, ce n'est pas un problème  (et de mon point de vue, ce n'est pas l'utilisation de la CLI vs. GUI qui fait de toi un gourou :p)

    Avec cette option activée, tout ton flux devrai donc passer par le tunnel.

    Tu peux faire un "route print" une fois le tunnel établi ?



  • Chris,

    Voici le résultat du 'route print':

    ===========================================================================
    Liste d'Interfaces
    11…28 b2 bd 4c df a2 ......Microsoft Wi-Fi Direct Virtual Adapter
      5...00 ff 46 ea 81 66 ......TAP-Windows Adapter V9
      9...28 b2 bd 4c df a1 ......Intel(R) Dual Band Wireless-N 7260
    13...28 b2 bd 4c df a5 ......Bluetooth Device (Personal Area Network)
      1...........................Software Loopback Interface 1
      4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
      2...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
      7...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2

    IPv4 Table de routage

    Itinéraires actifs :
    Destination réseau    Masque réseau  Adr. passerelle  Adr. interface Métrique
              0.0.0.0          0.0.0.0    192.168.43.1  192.168.43.141    25
            127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
            127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
      127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
          192.168.2.1  255.255.255.255      192.168.2.5      192.168.2.6    20
          192.168.2.4  255.255.255.252        On-link      192.168.2.6    276
          192.168.2.6  255.255.255.255        On-link      192.168.2.6    276
          192.168.2.7  255.255.255.255        On-link      192.168.2.6    276
        192.168.16.0    255.255.255.0      192.168.2.5      192.168.2.6    20
        192.168.43.0    255.255.255.0        On-link    192.168.43.141    281
      192.168.43.141  255.255.255.255        On-link    192.168.43.141    281
      192.168.43.255  255.255.255.255        On-link    192.168.43.141    281
            224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
            224.0.0.0        240.0.0.0        On-link    192.168.43.141    281
            224.0.0.0        240.0.0.0        On-link      192.168.2.6    276
      255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
      255.255.255.255  255.255.255.255        On-link    192.168.43.141    281
      255.255.255.255  255.255.255.255        On-link      192.168.2.6    276

    Itinéraires persistants :
      Aucun

    IPv6 Table de routage

    Itinéraires actifs :
    If Metric Network Destination      Gateway
      2    306 ::/0                    On-link
      1    306 ::1/128                  On-link
      2    306 2001::/32                On-link
      2    306 2001:0:9d38:90d7:28e5:22a1:3f57:d472/128
                                        On-link
      9    281 fe80::/64                On-link
      5    276 fe80::/64                On-link
      2    306 fe80::/64                On-link
      5    276 fe80::11dc:ab0c:8175:8a9a/128
                                        On-link
      2    306 fe80::28e5:22a1:3f57:d472/128
                                        On-link
      9    281 fe80::f57d:ee4c:a3a1:e0a5/128
                                        On-link
      1    306 ff00::/8                On-link
      9    281 ff00::/8                On-link
      2    306 ff00::/8                On-link
      5    276 ff00::/8                On-link

    Itinéraires persistants :
      Aucun

    Le réseau de l'entreprise est le 192.168.16.0
    Le réseau du sur lequel le VPN travaille est le 192.168.2.0 (c'est en tout cas dans ce réseau que j'obtiens une IP lorsque je me connecte)
    Le réseau de mon téléphone est le 192.168.43.0

    Question: ne devrais-je pas voir l'interface WAN de l'entreprise aussi ?

    J'espère que cela te parlera plus qu'à moi :-)

    Pat'



  • Chris,

    Le 'route print' envoyé précédemment était celui alors que l'option  "Redirect gateway" n'était pas cochée.

    Avec l'option cochée, voici le 'route print'

    ===========================================================================
    Liste d'Interfaces
    11…28 b2 bd 4c df a2 ......Microsoft Wi-Fi Direct Virtual Adapter
      5...00 ff 46 ea 81 66 ......TAP-Windows Adapter V9
      9...28 b2 bd 4c df a1 ......Intel(R) Dual Band Wireless-N 7260
    13...28 b2 bd 4c df a5 ......Bluetooth Device (Personal Area Network)
      1...........................Software Loopback Interface 1
      4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
      2...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
      7...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2

    IPv4 Table de routage

    Itinéraires actifs :
    Destination réseau    Masque réseau  Adr. passerelle  Adr. interface Métrique
              0.0.0.0          0.0.0.0    192.168.43.1  192.168.43.141    25
              0.0.0.0        128.0.0.0      192.168.2.5      192.168.2.6    20
        109.190.87.19  255.255.255.255    192.168.43.1  192.168.43.141    25
            127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
            127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
      127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
            128.0.0.0        128.0.0.0      192.168.2.5      192.168.2.6    20
          192.168.2.1  255.255.255.255      192.168.2.5      192.168.2.6    20
          192.168.2.4  255.255.255.252        On-link      192.168.2.6    276
          192.168.2.6  255.255.255.255        On-link      192.168.2.6    276
          192.168.2.7  255.255.255.255        On-link      192.168.2.6    276
        192.168.16.0    255.255.255.0      192.168.2.5      192.168.2.6    20
        192.168.43.0    255.255.255.0        On-link    192.168.43.141    281
      192.168.43.141  255.255.255.255        On-link    192.168.43.141    281
      192.168.43.255  255.255.255.255        On-link    192.168.43.141    281
            224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
            224.0.0.0        240.0.0.0        On-link    192.168.43.141    281
            224.0.0.0        240.0.0.0        On-link      192.168.2.6    276
      255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
      255.255.255.255  255.255.255.255        On-link    192.168.43.141    281
      255.255.255.255  255.255.255.255        On-link      192.168.2.6    276

    Itinéraires persistants :
      Aucun

    IPv6 Table de routage

    Itinéraires actifs :
    If Metric Network Destination      Gateway
      2    306 ::/0                    On-link
      1    306 ::1/128                  On-link
      2    306 2001::/32                On-link
      2    306 2001:0:9d38:6ab8:109d:2960:3f57:fdf9/128
                                        On-link
      9    281 fe80::/64                On-link
      5    276 fe80::/64                On-link
      2    306 fe80::/64                On-link
      2    306 fe80::109d:2960:3f57:fdf9/128
                                        On-link
      5    276 fe80::11dc:ab0c:8175:8a9a/128
                                        On-link
      9    281 fe80::f57d:ee4c:a3a1:e0a5/128
                                        On-link
      1    306 ff00::/8                On-link
      9    281 ff00::/8                On-link
      2    306 ff00::/8                On-link
      5    276 ff00::/8                On-link

    Itinéraires persistants :
      Aucun

    Désolé pour l'erreur  :-)



  • Avec cette route tu devrais normalement passer effectivement par le tunnel (même si je me demande pourquoi le masque est à 128.0.0.0  ;))

    Que se passe t-il lorsque tu accèdes à ton serveur web ?
    Comment se fait le controle au niveau de ce serveur en ce qui concerne l'adresse source ? Tu as un log ?



  • L'accès se fait directement sur notre adresse IP WAN et je n'ai malheureusement pas de log.

    Lorsque je tente d'y acceder, une fois connecté en VPN, je reçois le message comme quoi je ne suis pas autorisé à joindre ce site.

    Et enfin, je ne pige pas pour le masque puisque dans :

    IPv4 Tunnel Network, j'ai 192.168.2.0/24

    et dans

    IPv4 Local Network/s, j'ai 192.168.16.0/24


Log in to reply