- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie Routeur
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 1.2.0
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
FS#1355 - Problème de compatibilité entre routeur Freebox, VPN PPTP et Microsoft ISA server
Bonjour,
Je suis confronté à un problème de compatibilité entre le routeur de la
Freebox, Microsoft ISA server pour établir une connexion VPN.
Il est parfaitement reproductible avec le routeur des freebox 4 (degoupé
ou non) et 5, à condition de reproduire très précisement la configuration
décrite ci dessous.
En résumé : on a d’un côté une machine (sous Windows 2000 ou sous Windows
XP ou encore Windows 2003 server, je n’ai pas eu l’occasion de tester avec
d’autres systèmes) qui execute un serveur VPN PPTP, et qui est derrière la
freebox en mode routeur.
Le phénomène se reproduit à partir du moment où la freebox est en mode routeur,
soit qu’elle soit configurée pour router le protocole TCP port 1723 sur cette
machine, doit que la machine qui execute le serveur PPTP soit déclarée comme DMZ.
De l’autre côté, sur une autre connexion Internet (Free ou non), un client
VPN Windows, qui est sur une machine qui accède à Internet via un serveur
Microsoft ISA 2004 serveur. (le serveur est sous Windows Small Business
server 2003 SP1 ou Windows 2003 server). On peut lancer le client VPN
aussi bien sur une station XP ou Windows 2003 server
dans le reseau local que sur le serveur lui même.
Avec cet configuration, la connexion VPN échoue.
Si le client est sous XP, l’erreur reportée est ‘Error 619” Si le client est sous Windows 2003 server, l’erreur est “Error 628: The
connection was terminated by the remote computer before it could be
completed”
Plus précisement.
A noter que ce test est reproductible, en doublant les choese, avec du côté
freebox routeur + serveur VPN
1) une freebox en free dégroupé, qui renvoi le port TCP1723 vers la machine
qui fait serveur VPN. Cette machine executre Windows 2003 server
2) une freebox en free non dégroupé, qui renvoi le port TCP1723 vers la
machine qui fait serveur VPN, et qui déclare en plus cette machine comme
DMZ. Cette machine executre Windows XP SP2
du côté client, cela a été mis en évidence sur deux configuration avec
Windows SBS + ISA Server, connecté en free dégroupé (avec une freebox en
mode bridge, sans le routeur activé donc).
A noter bien sur :
1) du côté serveur VPN derrière Freebox routeur, on arrive à faire se
connecter des clients qui ne sont pas derrières ISA2004
2) du côté du reseau derrière ISA serveur, on arrive à se connecter à
plusieurs de VPN PPTP qui ne sont pas derrière une freebox en mode routeur
(exemple : pas de soucis vers une freebox non dégroupé en mode bridge et un
routeur Wifi Microsoft MN730 qui renvoi le port TCP 1723 vers la machine qui
fait serveur VPN).
Donc c’est bien l’ensemble serveur VPN PPTP (XP ou Windows 2000/2003) derrière un
routeur freebox et client derrière ISA2004 qui semble problèmatique. Après,
difficile de savoir lequel des deux est fautif sans approfondir.
Ce bug a aussi été reproduit avec Isa2006
Je suis à la disposition de quiquonque veut creuser cette question.
Dernier point : si quelqu’un à un serveur Linux PPTP derrière une routeur en
freebox, je voudrais bien faire un essai pour rentrer dessus avec mon client
derrière ISA.
http://www.microsoft.com/windowsserver2003/default.mspx http://www.microsoft.com/isaserver/
des versions d’évaluation pour tester
http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx http://www.microsoft.com/isaserver/prodinfo/trial-software.mspx
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Il me semble qu’il y a le protocole Gré ou un truc comme ca qu’il faut routé aussi, mais impossible de le faire, l’interface ne propose pas ce service :)
Non, si c’était le protocole GRE qui n’était pas routé, personne n’arrivera à se connecter au serveur PPTP situé derrière la Freebox.
Hors une machine qui n’utilise pas ISA server y arrive.
C’est vraiment une incompatibilité qui neccessite tout les paramètres que j’ai décrit pour être reproduit.
Merci en tout cas de t’être interessé à mon soucis
J’ai un VPN entrant sur un XP pro derrière la freebox.
J’ai naté le port 1723 et à priori le protocol GRE (47) suit automatiquement.
Je me connecte depuis mon travail à partir d’un Windows 2000 derrière un ISA Server 2000 sans problème.
J’avai quelques problèmes de déconnexion avec la v4 mais depuis la v5, le VPN reste complètement stable.
Dans le sens contraire, connexion depuis XP Pro derrière Freebox vers 2000 Server avec ISA 2000 & VPN entrant sans problème depuis toujours.
Voilà je sais pas si ça peut aider.
Euh alors là va falloir que je refasse le test ... la dernière fois cela n’avait pas du tout marcher ...
Voici ma config :
Freebox v5 : (Serveur VPN)
Mode Routeur
IP PC Serveur VPN : 192.168.0.28
Port Routé : 1723 TCP → 1723 TCP (192.168.0.28) Freebox v4 : (Client VPN)
Mode Routeur
Par contre ton protocole GRE c’est pas un port à router ?
Merci.
phoenixfury, peut tu me contacté par mél sur info @ winimage.com ?
peut ete que le problème se pose sur isa 2004 et 2006 mais pas 2000
Impossible de router le protocole GRE/47 manuellement sur une freebox.
De plus ce protocole ne gère pas les ports à l’inverse du TCP/6 ou de UDP/17.
gvollant je te contacterai et j’ai aussi un collègue qui gère l’informatique d’un agence voisine derrière un ISA 2004, je ferai des tests chez lui vers mon réseau derrière la Freebox.
Merci.
Le protocole GRE suit quand même, puisqu’il y a des cas où on arrive a établir la recherche avec succès.
De plus, si on met la DMZ vers la machine qui est serveur VPN, tout les protocoles doivent être routés
Je suis d’accord mais dans mon cas la seule redirection du port 1723 en TCP vers le serveur VPN suffit, pas de DMZ ou autre.
Concernant ISA je viens de vérifier, j’ai deux filtres de paquets IP dans les stratégies d’accès qui autorisent les paquets du protocole PPTP (client & serveur).
Vérifie que tu n’as aucune restriction sur ces deux filtres sur les ordinateurs distants.
Je t’envoi un mail au cas où tu voudrais faire des tests.
je n’ai pas recu ton email.
Il n’y a pas de problème de stratégie, car j’arrive à me connecter à des serveur PPTP du moment qu’il ne sont pas derrière la freebox.
De plus, le problème est le même si je paramètre le réseau dans ISA en tant que VPN auquel ISA se lie lui même.
le webmaster de IsaFirewalls.org n’arrive pas à se connecter non plus, et j’ai mis un thread dans son forum
http://isafirewalls.org/forums/thread/253.aspx
J’ai refait un test avec une Freebox 5 (sous XPSP2) et le bug ne se manifeste plus !
La freebox est en DMZ.
Le bug se manifeste encore avec une freebox 4 non dégroupé et avec une DMZ également.
Il faudrait refaire les tests en tout cas.
Le problème n’étant reproductible qu’avec le mode routeur de la freebox d’un côté ET ISA de l’autre, on ne sais pas à qui imputer le bug.
Cela me donne l’impression qu’ISA, en tant que client PPTP (ou relayant une demande de connexion PPTP venant d’un client) émet une trame légèrement différente de la trame émise par un windows relié directement à Internet (sans ISA), et que cette différence pose problème au routeur de la freebox pour router le PPTP (qui est plus complexe à router qu’un autre protocole et a san doute un traitement spécifique dans le code du routeur).
Pour tester, il n’y a même pas besoin d’un compte valide : j’ai deux adresses de machine derrière des freebox 4. Si vous vous connectez derrières ISA, vous serez rejeté de la même manière (erreur 628), avec (que le login/password soit valide ou non), sinon vous serez accepté, ou le login/password est invalide, rejeté si avec un message d’erreur adapté (disant que le compte est invalide).
je peux donner par mél l’adresse IP pour tester (puisqu’il n’y a pas de compte à creer) à quelqu’un qui veut regarder, mais je ne vais pas la poster en public (ce n’est pas chez moi)
J’arrive toujours à reproduire le problème avec la freebox 4 (dégroupé ou ipadsl) mais plus avec la 5.
Est ce que le code du routeur de la 5 a subit des corrections par rapport à celui de la 4, et si oui ont-elle une chance d’être répercutée dans les prochains firmwares de la 4 ?
Sur une V4 dégroupée rebootée vendredi 19/1 à 10h (donc qui doit avoir récupéré le nouveau firmware v4 distribué à partir de mercredi 17), le bug est toujours reproductible.
Le code du routeur est-il basé sur la même souche pour v5 adsl (ou le bug n’est plus présent) et v4 (dégroupé ou non)
Toute information est bienvenue
J’ai testé sur une autre freebox 4 dégroupé, rebooté le 20/1 (et qui a bien récupéré un nouveau firmware au reboot) et le bug est toujours la
j’ai testé sur une freebox 4 NON dégroupé (îpadsl donc) qui a été mise à jour ce 26 janvier et le bug y est aussi.
Je suis assez surpris que les deux firmwares (degroupé ou non) de freebox 4 ont le problème alors qu’ils sortis après le firmware freebox 5 adsl qui ne l’as pas. Le code du routeur est il différent entre les firmware?
il faudrait _peut être_ que la freebox (v4) fasse un truc comme ca au boot:
# modprobe ip_nat_pptp
# modprobe ip_conntrack_pptp
Une reponse ne manquera pas si j’ai dit une connerie
Bonne journée et bon courage a l’equipe Freebox
Un contact chez Microsoft a analysé les trames. Voici ce qu’il indique:
This Looks like a PPTP caller ID issue . From your description of the issue , the problem seems to be seen whether the client is behind ISA 2004 or TMG,
We can confirm that it is a caller ID issue by looking at a Network Monitor Trace on remote side VPN server as well as ISA , client in the client side.
We have seen problem like this in some 3rd party Vendor equipments
We have see this issue with a lot of router vendors and most of them are based on an embedded version of Linux. I have included the Linux bug below that clearly demonstrates the issue. You can see that they don’t apply the PPTP NAT translation in the reverse scenario for the Set-link-info packets.
http://svn.netfilter.org/cgi-bin/viewcvs.cgi?rev=4241&view=rev
I have seen the issue with the following vendors:
Draytek, D-Link, Linksys, but there are many more running with the same kind of bug. This version of Linux applies the PPTP NAT translation to all traffic. Including routed traffic, so it doesn’t even help to put the router in bridged/routed mode.
We use the PPTP Call ID in Windows Server 2003 NAT / ISA Server to find the correct NAT mapping. When the router changes this we fail to find , the correct mapping and drop the connection. Windows XP does not have this check, so that’s why it works with normal VPN clients.
et après avoir reçu mes traces Network Monitor
In the trace captcli_behind_isa.cap client sends caller id in frame 69 with caller ID 41464 which is the same sent by ISA in the ISA trace cap_srv_isa.cap with frame #387 the response from Freebox server has a different caller ID 28307 in frame 402.
I see another PPTP connection attempt and a similar different caller ID info from the remote side vpn router.
After seeing the response with different caller ID , the PPTP connection is closed. This is similar to what i explained earlier.
Please check with the remote router vendor to correct this
gvollant:
La mise à jour des v4 en dégroupé du début avril a aligné le code des v4 et des v5, donc le bug ne devrait plus exister en v4 dégroupé.
Pour les non dégroupés, il reste encore un peu de travail pour faire cet alignement, mais il est en cours.
J’avais effectivement dit debut 2007 que le bug ne se manifestait plus en Freebox 5, mais depuis plusieurs mois, il est revenu en Freebox 5.
Je vais essayer de refaire des captures en freebox 5
Je confirme que le bug se produit avec une Freebox 5 rebootée ce matin (donc avec le firmware 1.3.4)
Idem Freebox 5 firmware 1.3.5