Problème VPN - PFsense-OpenVPN - traffic client

PatK

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

chris4916

@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 ;)

PatK

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 ;)

chris4916

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 ;)

PatK

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 :)

chris4916

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

chris4916

@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 ;)

PatK

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'

chris4916

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 ?

PatK

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'

PatK

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 :-)

chris4916

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 ?

PatK

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