VPN non sécurisé

[spencefoxtrot]

Hello,

Je n'arrive pas à forcer le chiffrement de la connexion avec le vpn fournit. Sur la révolution (ou la delta), j'y arrivais de mémoire

https://ibb.co/gtL9tQZ https://ibb.co/BBhKgMt

Lorsqu'on choisit "exiger le chiffrement", la connexion ne s'établie pas. Je ne pense pas que ce soit toute la communication qui ne soit pas chiffrée, mais juste la transmission des ID en clair donc.

[Fabliv]

@spencefoxtrot,

La solution VPN fournie et trop basique et simpliste sur la Freebox PRO. Je préfère gérer mes liens VPN personnellement via ma propre passerelle, mais malheureusement, la Freebox PRO ne permet pas d'avoir une adresse full DMZ, elle se contente de faire passer uniquement le trafic TCP,UDP et ICMP. Les protocoles GRE, ESP, AH... par exemple, sont bloqués.

Vivement un mode Bridge ou la possibilité d'utiliser une vraie DMZ.

Voir l'issue #21

Bien à toi. ;)

[Yazur-admin]

@Fabliv Salut, lorsque tu dis que les protocoles GRE, ESP, AH sont bloqués, qu'est ce qu'il se passe réellement? Qu'elles sont les conséquences visibles?

De notre côté, nous arrivons à monter le tunnel IPSEC que ce soit la phase 1 comme la phase 2. Mais nous nous retrouvons avec un débit de 500ko/s entrant sur la Freebox, mais 80mo/s sortant. Est-ce que c'est le comportement attendu d'un blocage ESP (phase 2)?

[spencefoxtrot]

Bah chez moi ça ping pas tout simplement...

Impossible de sortir comme d'entrer avec mon vps et ma vm local en gre l'une vers l'autre.

En free GP, avec la vm local en DMZ, ça passait

edit : et la machine locale avec le gre autorisé en iptables

[Yazur-admin]

@spencefoxtrot On est d'accord que le protocole GRE est utilisé que pour la phase 2 de l'IPSEC? Ton tunnel VPN se créé bien mais ne laisse pas passer de flux? Je ne sais pas ce que tu utilises exactement comme service pour créer ton tunnel VPN...

[spencefoxtrot]

On est d'accord que je n'ai aucune idée de ce que "phase 2" veut dire oui ^^ Je n'utilise pas d'ipsec (pour moi, c'est un protocole de chiffrement, et je n'en ai pas besoin. EDIT : et je ne sais pas le paramétrer à ce jour... ça fait parti de ma to do list, pour apprendre). Je n'ai aucun idée si le tunnel se crée ou non, je sais juste qu'il ne fonctionne pas. Je n'utilise pas de service pour le GRE... j'utilise GRE directement sur linux.

[Yazur-admin]

@spencefoxtrot D'accord merci pour toutes ces informations supplémentaires. Tu as essayé de faire un tcpdump des deux côtés pour vérifier qu'aucun paquets GRE arrivent jusqu'à l'extrémité? Au moins tu seras vite fixé si c'est la box qui bloque ou pas. En tout cas de mon côté j'utilisé ESP à la place de GRE et je peux ping entre mes deux réseaux.

[spencefoxtrot]

@Yazur-admin Je ne sais pas ce qu'est tcpdump, donc non ^^

Cependant, mon tunnel est toujours paramétré...

Comment on l'utilise ?

[Yazur-admin]

@spencefoxtrot

Il faut installer le package tcpdump "apt-get install tcpdump" ou autre commande selon la version de Linux que tu utilises. Ensuite, tu peux faire un "tcpdump proto GRE" ou un "tcpdump -v proto GRE" sur tes deux serveurs. Tu peux ensuite tester ton tunnel GRE et voir si des paquets s'ont envoyés et/ou reçus.

[Fabliv]

Salut @Yazur-admin, pour ma part, nous avons des passerelles qui permettent de créer un lien VPN site-to-site IPSEC entre notre siège et nos succursales. Nous avons en WAN1 Free PRO avec la passerelle en DMZ et en WAN2 un autre ISP en PPoE.

• WAN1 <=> WAN1 les liens ne s'établissent pas
• WAN1 <=> WAN2 les liens ne s'établissent pas
• WAN2 <=> WAN2 les liens s'établissent

Ce qui démontre que la Freebox PRO ne laissent pas passer tous les protocoles utilisés par IPSEC (dont AH et ESP). Je pense ne pas pouvoir être plus clair dans l'explication.

;)

[spencefoxtrot]

@Yazur-admin https://ibb.co/cbvfWwP https://ibb.co/4M4Qssw

Il n'y a rien qui bougeait sur le VPS. J'ai tenté une connexion avec une redirection que j'avais prévue, et j'ai eu le premier screen (plusieurs ligne sont apparues bien sur) Rien de l'autre côté (la VM locale)

De même, de l'autre coté (VM locale), j'ai fais une commande ping, et rien ne bougeait sur le VPS.

J'ai recommencé les tunnel plusieurs fois, je ne suis pas à l'abris d'une erreur de paramétrage dans les routes

[Yazur-admin]

@spencefoxtrot Je ne connais pas la configuration GRE Linux, le plus simple serait de pouvoir tester avec une autre connexion internet, par exemple la 4g backup de la Freebox Pro.

Débrancher l'arrivée optique, la box bascule en backup et là, tu peux récupérer le nouvelle IP publique et tester de refaire tes routes.

Pour lire plus facilement les enregistrements tcpdump tu peux l'envoyer dans un fichier avec le paramètre -w "nom du fichier". Et après, tu peux l'ouvrir avec Wireshark.

[Fabliv]

@spencefoxtrot Je ne connais pas la configuration GRE Linux, le plus simple serait de pouvoir tester avec une autre connexion internet, par exemple la 4g backup de la Freebox Pro.

Débrancher l'arrivée optique, la box bascule en backup et là, tu peux récupérer le nouvelle IP publique et tester de refaire tes routes.

Avec la 4G de backup, tu te retrouves en CGNAT, donc impossible de faire de la redirection de port. L'IP publique obtenu n'étant pas celle de la Box 4G.

[Yazur-admin]

@Fabliv Pourquoi vouloir faire de la redirection de port? La box 4G ne dépend pas du Firewall de la Freebox. Pour ma part j'ai réussi à monter un tunnel IPSEC par la box 4G sans problème.

[spencefoxtrot]

@Yazur-admin en fait non, car la 4g en backup : N'a pas de firewall manageable (donc impossible de faire une dmz vers la VM locale, ou d'y paramètrer GRE) N'a pas la même ipv4 que la box free Donc ça implique des modifications totales.

Idem pour ma propre 4g en backup d'ailleurs.

[Fabliv]

@Yazur-admin, la Box 4G utilisée en backup et gérée par la Freebox, donc dépend du firewall de la Freebox.

Eventuellement, tu connectes directement ton LAN sur la Box 4G pour faire tes tests, mais encore une fois, c'est du CGNAT sauf si la Box 4G chez Free PRO bénéficie d'une IP publique fixe (ce dont je doute).

[Yazur-admin]

@Fabliv @spencefoxtrot Je ne comprends pas vraiment votre problème avec la box 4G. Si vous branchez un équipement sur l'un des ports LAN de la Freebox avec une IP en 192.168.10.1 et passerelle 192.168.10.254. Cet équipement pourra instancier sa connexion VPN par l'intermédiaire de l'IP publique 4G. Ma box 4G à par exemple récupérer une IP comme celle-ci : 37.164.198.X Et j'ai instancié mon tunnel sans problème et j'ai testé les débits qui étaient cohérents dans les deux sens.

Je me suis renseigné concernant le CGNAT et c'est une IP publique partagée par plusieurs équipements qui eux récupèrent des IP privées. Dans un cas de CGNAT effectivement ça semble compliqué d'instancier un tunnel VPN vers une IP publique qui est partagée.

[spencefoxtrot]

Si tu as un client, oui... Mais pas un serveur...

Dans le cas de GRE, c'est deux serveurs, donc ils ont besoin du passage du protocole GRE (ou de la dmz à défaut, ou du bridge). Donc même en allant se brancher sur cette box 4G (qui n'est pas celle de Free), tu pourras rien recevoir si tu n'ouvres pas des ports, ou les proto...

[spencefoxtrot]

Et si tu mets 192.168.10.254, tu es renvoyé vers la freebox... pas vers la GW de la box 4G (sauf s'ils ont configuré la box 4g en 10.254...)

[Fabliv]

@spencefoxtrot, en effet, un client derrière la Freebox initiant la connexion VPN, pas de souci.

@Yazur-admin, un serveur recevant les demandes de connexion VPN derrière la Freebox, ca ne passera pas.

[Yazur-admin]

@Fabliv @spencefoxtrot D'accord, j'ai compris plusieurs choses. Déjà, il faut savoir que nous sommes dans un schéma serveur < -- > serveur. Mon tunnel IPSEC avec la 4G à fonctionné parce que je l'ai initialisé depuis le serveur qui se trouve derrière la Freebox vers notre serveur virtuelle OVH.

Par contre l'inverse n'aurait pas marché, car l'IP publique que j'ai mentionnée au-dessus est partagée.

Donc vous pouvez tester avec le box 4G à condition d'initialiser le tunnel depuis votre machine qui est sur le LAN de la Freebox et qu'en face ça ne soit pas une connexion internet 4G.

[Yazur-admin]

Salut @Yazur-admin, pour ma part, nous avons des passerelles qui permettent de créer un lien VPN site-to-site IPSEC entre notre siège et nos succursales. Nous avons en WAN1 Free PRO avec la passerelle en DMZ et en WAN2 un autre ISP en PPoE.

• WAN1 <=> WAN1 les liens ne s'établissent pas
• WAN1 <=> WAN2 les liens ne s'établissent pas
• WAN2 <=> WAN2 les liens s'établissent

Ce qui démontre que la Freebox PRO ne laissent pas passer tous les protocoles utilisés par IPSEC (dont AH et ESP). Je pense ne pas pouvoir être plus clair dans l'explication.

;)

@Fabliv Pour être sûr de bien comprendre, vous avez un schéma à deux arrivées internet pour chaque localisation? Free + autre ISP au siège. Free + autre ISP dans les succursales.

[Fabliv]

@Yazur-admin, exact. Dans mon cas, avec notre topologie, même si j'initie en site-to-site la connexion par le WAN2 du siège vers le WAN1 de la succursale, la connexion ne s'établie pas.

[Yazur-admin]

@Fabliv Je pense que c'est anormal. Parce que nous arrivons de notre côté à initier le tunnel IPSEC d'un côté comme de l'autre après avoir fait de la redirection de port sur le firewall de la box. Voici un screen des ACL réalisées sur la box :

https://nsa40.casimages.com/img/2021/06/17/210617113201424129.png

[spencefoxtrot]

@Yazur-admin t'es en UDP, c'est normal que ça passe... Son problème est ESP, AH...

[Fabliv]

@Yazur-admin, nos passerelles n'utilisent pas UDP 4500 et 500 pour initier IPSEC.

[Yazur-admin]

@spencefoxtrot Nous n'avons pas la même configuration. IPSEC = 500 et 4500 UDP ESP/AH/GRE c'est des protocoles différents.

Lorsque tu fais de l'IPSEC tu as deux phases "https://www.watchguard.com/help/docs/fireware/12/fr-FR/Content/fr-FR/mvpn/general/ipsec_vpn_negotiations_c.html"

Le tunnel VPN peut-être établi sans pour autant que les données transitent entre deux réseaux. La P1 = OK, la P2 = PAS OK.

En plus de ça, la Freebox bloque les protocoles "ESP, AH et GRE" entrants mais pas sortants. Alors les données pourraient transiter dans un sens, mais pas dans l'autre.

[Fabliv]

En plus de ça, la Freebox bloque les protocoles "ESP, AH et GRE" entrants mais pas sortants. Alors les données pourraient transiter dans un sens, mais pas dans l'autre.

Sauf que nos passerelles fonctionnent obligatoirement en mode serveur, donc connexion serveur<=>serveur et ont besoin de AH et ESP dans les deux sens.

[spencefoxtrot]

Je me demande si justement la FB ne bloquerait pas aussi le sortant sur le proto GRE... car effectivement, en sortant, je devrais voir (si je comprends bien) des donnés arriver sur mon vps avec les tcpdrump... Et toujours logiquement, si j'ouvre une porte pour sortir, alors cette porte reste ouverte jusqu'au retour (donc une commande ping saurait revenir). C'est là que je me dis que GRE est bloqué dans le deux sens (car avant, avec Free GP, avant de penser à ouvrir la DMZ la première fois où on faisait du GRE, on avait un fonctionnement... puis ça tombait... sans qu'on tilte tout de suite.... C'est après avoir ouvert la DMZ qu'on a réglé le soucis).

Hors il ne se passe rien du tout là...

[Fabliv]

@spencefoxtrot, c'est fort probable en effet. :( Et dans ce cas, super restrictif...

[Yazur-admin]

@Fabliv Dans ce cas pourquoi avec notre topologie nous arrivons à envoyer 80mo/s mais uniquement a recevoir 500ko/s? Peu importe qui initie le tunnel IPSEC?

Possible réponse: ESP bloqué qu'en flux entrant alors que GRE et AH bloqués entrant/sortant?

[Fabliv]

@Yazur-admin, quels sont tes ISP (distant et local) ? Quand tu parles d'envoi/réception, c'est avec ton client derrière la Freebox PRO ?

[Yazur-admin]

@Fabliv D'un côté OVH "infra virtuelle" et de l'autre Freebox Pro.

OVH --> Freebox = 500Ko/s Freebox --> OVH = 80mo/s

Pareil si je lance le tunnel à partir d'OVH comme du côté Freebox.

Il faut savoir que nous avons deux ISP sur le lieu de localisation de la Freebox. Nous avons une fibre dédiée et avec celle-ci les débits sont bons d'un côté comme de l'autre avec une configuration IPSEC similaire.

[Fabliv]

Il est fort probable qu'ESP en soit la cause, amha.

D'autres utilisateurs, ici, auraient un avis à donner ?

[Yazur-admin]

@Fabliv J'ai l'impression que nous nous heurtons au final tous sur le même problème malgré nos topologies complètement différentes. Nous avons un ticket ouvert depuis plusieurs jours avec le support Free Pro, nous verrons bien s'ils acceptent de ne plus faire de blocages sur ces protocoles.. Au moins nous permettre de leur envoyer des adresses IP pour lesquelles autoriser l'accès.

[Fabliv]

@Yazur-admin, soit il nous faut un mode bridge soit la possibilité de configurer une adresse full DMZ avec le firewall.

Le mode bridge serait dans les tuyaux d'après le ST que j'ai eu au téléphone dernièrement. Probablement d'ici la fin de l'été. A moins que cela m'ait été dit pour me calmer un peu. ^^

[Yazur-admin]

@Fabliv J'ai également eu une personne au téléphone qui m'a dit la même chose, courant juillet le mode bridge en bêta. Mais tous les services deviendraient indisponibles dont la 4G backup.

[Yazur-admin]

@Fabliv Ah, j'allais oublier, la personne au téléphone m'a dit que passer en IPv6 pourrait résoudre énormément de problème. Alors je vais tenter cet après-midi, je vous tiendrez au courant.

[Fabliv]

@Fabliv J'ai également eu une personne au téléphone qui m'a dit la même chose, courant juillet le mode bridge en bêta. Mais tous les services deviendraient indisponibles dont la 4G backup.

Oui, mais au moins cela donnerait le choix aux clients.

Dans cette configuration, cela me conviendrait puisque je m'occupe moi même de faire mon Failover via mes passerelles. Nous n'avons pas besoin des lignes Tel fixes puisque nous utilisons du Centrex via un prestataire spécialisé (à ce propos, cela nous serait impossible si notre LAN était géré par la Freebox PRO, puisque il n'y a pas d'option pour désactiver SIP ALG).

[Yazur-admin]

@Fabliv Même chose pour nous, nous avons tout désactivé sauf le backup 4G. Le mode bridge serait le bienvenu, mais attendre autant de temps pour quelque chose qui aurait dû être présent dès le départ ça fait mal. Mes directeurs envisagent déjà de partir chez un autre opérateur si Free ne règle pas le problème rapidement.

[Fabliv]

@Yazur-admin, ta passerelle sait gérer le WAN Failover ?

[Yazur-admin]

@Fabliv Nous utilisons Pfsense comme cœur de réseau, il y a une interface WAN par connexion internet. Et j'ai mis en place du Failover c'est très simple avec Pfsense, il faut juste penser à rajouter le groupe de passerelle par défaut sur le LAN sinon ça ne fonctionne pas. https://www.provya.net/?d=2017/11/24/11/31/31-

[Fabliv]

@Yazur-admin, dans ce cas, Freebox PRO en mode bridge, tu pourras utiliser la Box 4G en WAN failover via Pfsense. ;)

[Yazur-admin]

@Fabliv On verra bien lorsque le mode bridge sera là :P en attendant, je vais tenter l'IPv6 voir si ça change quelque chose.

[Fabliv]

Au fait @Yazur-admin, as-tu activé l'Offloading Hardware et TCP sur ton Pfsense (désactivé par défaut), histoire d'obtenir les débits max permis pas la Freebox PRO ?

[spencefoxtrot]

@Fabliv J'ai l'impression que nous nous heurtons au final tous sur le même problème malgré nos topologies complètement différentes. Nous avons un ticket ouvert depuis plusieurs jours avec le support Free Pro, nous verrons bien s'ils acceptent de ne plus faire de blocages sur ces protocoles.. Au moins nous permettre de leur envoyer des adresses IP pour lesquelles autoriser l'accès.

T'es trop enthousiaste là... Dans plusieurs mois, peut-être un début de quelque chose, mais n'espère rien d'eux...

[spencefoxtrot]

Au fait @Yazur-admin, as-tu activé l'Offloading Hardware et TCP sur ton Pfsense (désactivé par défaut), histoire d'obtenir les débits max permis pas la Freebox PRO ?

Je tourne aussi avec un pfsense, en usage particulier. Offloading ? Pourquoi pfsense serait bridé ?

[Fabliv]

@spencefoxtrot, l'Offloading lorsqu'il est géré de manière logicielle a, en effet, tendance à brider les débits. Surtout sur des connexion au delà des 500Mb/s à ce que j'ai pu remarqué.

[spencefoxtrot]

Je l'ai mis sur une VM HyperV... :D

[Yazur-admin]

@spencefoxtrot

Au fait @Yazur-admin, as-tu activé l'Offloading Hardware et TCP sur ton Pfsense (désactivé par défaut), histoire d'obtenir les débits max permis pas la Freebox PRO ?

@Fabliv "Hardware Checksum Offloading" désactivé sur Pfsense virtuelle et activé sur Pfsense physique. Aes-ni activé des deux côtés avec processeurs compatibles.

Physique : https://nsa40.casimages.com/img/2021/06/17/210617030826291952.png Virtuelle : https://nsa40.casimages.com/img/2021/06/17/210617030858542573.png

[spencefoxtrot]

Merci pour la précision