Freebox V5 ADSL

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

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