Pare-feu Vpn (résolu)

laservert

Bonjour,

Je suis dans l'incapacité de faire du VPN en présence du pare-feu de Internet Security 2008.

Une règle accepte bien le protocole 47. Mais les trames TCP arrivant sur le port 1723 sont bloquées par le pare-feu.

Que faire?

(Sans pare-feu mon VPN fonctionne)

Merci pour les idées.

Inconnu

Bonjour,

Avez-vous essayé de créer manuellement la règle nécessaire?

Cdlt

laservert

Bonjour,

Avez-vous essayé de créer manuellement la règle nécessaire?

Cdlt

Oui, j'ai créé une règle acceptant TCP entrant provenant de toutes les sources de tous les ports à destination de mon port 1723.

...

Inconnu

Avez-vous un message indiquant que le firewall bloque ce port ou est-ce votre déduction ?

Cdlt

laservert

Avez-vous un message indiquant que le firewall bloque ce port ou est-ce votre déduction ?

Cdlt

Ce n'est pas ma déduction mais le constat dans le fichier de log:

[bDFNDISF][FILTER] Denied TCP packet. (dir = INBOUND, src addr = 192.168.2.1, src port = 49332, dst addr = 192.168.2.125, dst port = 1723)

BAV

Inconnu

Postez le fichier .xml de configuration de votre profi présent ici : C:\Program Files\BitDefender\BitDefender 2008\Firewall\Profiles

Cdlt

laservert

Postez le fichier .xml de configuration de votre profi présent ici : C:\Program Files\BitDefender\BitDefender 2008\Firewall\Profiles

Cdlt

voici mon fichier .xml

/applications/core/interface/file/attachment.php?id=738" data-fileid="738" rel="">D_faut_non_confiance_0_.xml

Inconnu

Bonjour,

Le fichier de configuration montre des règles aveec le port 1723 en source et non en destinataire.

Pouvez-vous vérifier vos règles ?

merci

laservert

Bonjour,

Le fichier de configuration montre des règles aveec le port 1723 en source et non en destinataire.

Pouvez-vous vérifier vos règles ?

merci

Bonsoir,

il y a bien une règle sur le port 1723 en source sans doute inutile, mais la règle en destinataire existe bien.

Voir la première ligne du fichier xml:

element3 name="list_in">

<val id="222" type="1" action="1" src_ip="0.0.0.0" src_port_from="0" src_port_to="0" src_mask="0.0.0.0" src_flags="0" dst_ip="192.168.2.125" dst_port_from="1723" dst_port_to="0" dst_mask="255.255.255.255" dst_flags="0" proto="6" connect="1" listen="1" traffic="1" active="1" md5="" >

Cette règle n'a aucun effet. Est-elle inadaptée?

BAV

laservert

Bonjour,

En complément, je viens de m'assurer de la mise en place de la dernière mise à jour et j'ai executé le fichier weekly.exe du 5 octobre disponible sur le site http://download.bitdefender.com.

Lors de la tentative de connexion du réseau VPN le message de deni persiste dans le fichier de logs:

Denied TCP packet. (dir = INBOUND, src addr = 192.168.2.1, src port = 49214, dst addr = 192.168.2.125, dst port = 1723)

192.168.2.125 est bien l'adresse IP fixe de ma carte réseau (WiFi) et je suis en Windows XP .

192.168.2.1 est l'adresse du routeur...

BAV

yann

Bonjour,

Je pense que votre règle n'est pas bonne.

Essayez celle-ci :

element3 name="list_in">

<val id="222" type="1" action="1" src_ip="0.0.0.0" src_port_from="0" src_port_to="0" src_mask="0.0.0.0" src_flags="0" dst_ip="192.168.2.125" dst_port_from="0" dst_port_to="1723" dst_mask="255.255.255.255" dst_flags="0" proto="6" connect="1" listen="1" traffic="1" active="1" md5="" >

Cordialement

laservert

Bonjour,

Je pense que votre règle n'est pas bonne.

Essayez celle-ci :

element3 name="list_in">

<val id="222" type="1" action="1" src_ip="0.0.0.0" src_port_from="0" src_port_to="0" src_mask="0.0.0.0" src_flags="0" dst_ip="192.168.2.125" dst_port_from="0" dst_port_to="1723" dst_mask="255.255.255.255" dst_flags="0" proto="6" connect="1" listen="1" traffic="1" active="1" md5="" >

Cordialement

Bonjour,

La solution que vous proposez me semble assez logique mais, dans le paramétrage, la valeur du port(s) de destination est mise automatiquement dans la variable dest_port_from par Bitdefender (s'agirait-il d'un bug?).

Par quel éditeur puis-je intervenir sur le fichier profile.xml pour faire la modification et faire le test, car je ne réussis pas une telle manipulation?

Cordialement.

yann

Bonjour,

La solution que vous proposez me semble assez logique mais, dans le paramétrage, la valeur du port(s) de destination est mise automatiquement dans la variable dest_port_from par Bitdefender (s'agirait-il d'un bug?).

Exact je confirme ! Pas génial en effet.

Par quel éditeur puis-je intervenir sur le fichier profile.xml pour faire la modification et faire le test, car je ne réussis pas une telle manipulation?

Cordialement.

Un simple éditeur de texte suffit, mais évitez le notepad (bloc-notes) utilisez plutôt le wordpad ou mieux, un éditeur de texte à coloration syntaxique.

laservert

Exact je confirme ! Pas génial en effet.

Un simple éditeur de texte suffit, mais évitez le notepad (bloc-notes) utilisez plutôt le wordpad ou mieux, un éditeur de texte à coloration syntaxique.

Je suis effectivement en mesure de faire une copie du profile.xml et de le modifier dans le bloc-notes mais impossible de le recaser dans l'arborescence Bitdefender qui semble une zone protégée en écriture même lorsque l'application est inactive...

Peut-être y-a-t-il un processus à stopper??

Cdlt

madcap

qui semble une zone protégée en écriture même lorsque l'application est inactive...

à modifier en mode sans echec peut etre ?

Inconnu

Bonjour

Je vous déconseille très très fortement les modifications manuelles des fichiers de configuration.

Je ne comprend pas : "la valeur du port(s) de destination est mise automatiquement dans la variable dest_port_from par Bitdefender "

Si vous créez une règle manuellement, en suivant le lien en bas à droite avancé, pour le port vous sélectionnez spécifique et dans la case vous indiquez 1723 ....

D'un autre coté, les développeurs m'ont indiqué qu'ils ont testé à nouveau et pas de problème. Je vais donc voir s'ils ont fait qque chose de particulier ....

Cdlt

laservert

Bonjour

Je vous déconseille très très fortement les modifications manuelles des fichiers de configuration.

Je ne comprend pas : "la valeur du port(s) de destination est mise automatiquement dans la variable dest_port_from par Bitdefender "

Si vous créez une règle manuellement, en suivant le lien en bas à droite avancé, pour le port vous sélectionnez spécifique et dans la case vous indiquez 1723 ....

D'un autre coté, les développeurs m'ont indiqué qu'ils ont testé à nouveau et pas de problème. Je vais donc voir s'ils ont fait qque chose de particulier ....

Cdlt

Merci,

je reste dans l'attente de votre vérification. Mais je vous confirme que c'est bien la variable dest_port_from qui est renseignée par la manipulation que vous conseillez.

Cdlt

Inconnu

Bonjour

Les développeurs m'indiquent que, lors de leur test, rien de spécial n'a été fait : pas d'ajout manuel de règles dans le firewall.

Avez-vous fait votre test sur un réseau local ou essayez d'établir un véritable VPN entre 2 PCs sur des réseaux différents ?

Cdlt

laservert

Bonjour

Les développeurs m'indiquent que, lors de leur test, rien de spécial n'a été fait : pas d'ajout manuel de règles dans le firewall.

Avez-vous fait votre test sur un réseau local ou essayez d'établir un véritable VPN entre 2 PCs sur des réseaux différents ?

Cdlt

Bonjour,

Le test est fait en local mais avec passage par l'adresse IP publique de l'internet.

Cdlt

laservert

Bonjour,

j'ai examiné avec intérêt vos suggestions. J'ai modifié manuellement le profile.xml après démarrage en mode diagnostic ( je suis en XP).

Il s'avère que les variables dest_port_from et dest_port_to représentent la plage des ports de destination. Si un unique port est choisi seule la variable des_port_from est renseignée.

J'ai fais des essais sur des plages étendues 0 à 1723 ou 1720 à 1724, j'observe toujours un deni des trames TCP.

Cela valait la peine d'être essayé, dommage c'était une fausse bonne idée. Merci, malgré tout, de vous préoccuper de mon problème.

Cdlt

yann

Bonjour,

Merci pour le retour d'information, navré que cela ne soit pas la solution.

Vous dites que vous faites le test sur l'adresse publique internet : est-ce que ça fonctionne avec l'adresse privée 192.168.2.125 ?

Cdlt

laservert

Bonjour,

sur l'adresse privée 192.168.2.125 le phénomène est identique, j'ai un deni d'accès sur le port 1723 en présence du pare-feu. Tout semble bien se passer en son absence.

Cdlt

Inconnu

Bonjour

J'ai relancé les développeurs sur ce problème avec un caractère urgent. Au moinsun autre utilisateur a le même soucis.

Serait-il possible de prendre la main sur votre PC ?

Cdlt

laservert

Bonjour

J'ai relancé les développeurs sur ce problème avec un caractère urgent. Au moinsun autre utilisateur a le même soucis.

Serait-il possible de prendre la main sur votre PC ?

Cdlt

Je n'y suis pas opposé. Quelle procédure envisagez-vous?

J'ai cherché à vous faire parvenir un message, mais la messagerie semble ne pas fonctionner ...

laservert

Bonjour,

Suite au doute émis par Florent, j'ai tenté de me connecter en VPN à partir d'un client externe en Windows Vista. Je suis confronté au même phénomène, de deni d'accès sur le port 1723 de mon serveur VPN sous Windows XP, que lorsque je me connecte en réseau local.

Extrait du fichier journal:

2007/10/25 19:10:16.490 [bDFNDISF][FILTER] Denied TCP packet. (dir = INBOUND, src addr = 90.21.187.221, src port = 49177, dst addr = 192.168.2.125, dst port = 1723)

Existe-il un internaute client de Bitdefender faisant fonctionner son pare-feu sur un serveur VPN en Windows XP capable d'établir sans problème une connexion VPN ?

Merci d'avance pour l'info.

laservert

Bonjour,

je viens de tester dans de meilleures conditions les réactions d'un serveur VPN sous contrôle du pare-feu de Bitdefender.

Conditions de l'essai:

- client distant en Windows XP derrière une Livebox en réseau privé d'adresse 192.168.1.0 .

- serveur XP en réseau privé d'adresse 192.168.3.0 connecté à un routeur Wifi RW400M Olitec installé sur un modem-câble. Une redirection du port 1723 est établie sur le routeur.

Je confirme le deni d'accès des trames TCP arrivant sur le port 1723 du serveur. Le VPN ne peut être établi qu'en stoppant le pare-feu de Bitdefender. Ces conditions de travail sans pare-feu sont peu satisfaisantes et méritent d'être corrigées au plus vite.

Cdlt

laservert

Bonjour,

Je souhaite seulement faire le point à ce jour pour relancer ce sujet soulevé le 5 octobre 2007.

Le 27 novembre, j'ai eu l'information que les développeurs avaient bien identifié ce problème de blocage du port 1723 lors de l'établissement d'un VPN, que cela concernait essentiellement Windows XP et que la correction était en cours.

Espérons que 2008 nous apportera la solution ...

Cdlt

Inconnu

Bonjour

Correction prévu lors de la mise à jour build 11.0.16 prévue d'ici la fin du mois.

Cdlt

laservert

Bonjour

Correction prévu lors de la mise à jour build 11.0.16 prévue d'ici la fin du mois.

Cdlt

Bonjour,

J'ai testé. Merci. Ce sujet peut être clôturé.

Cdlt