J'ai un problème avec un accès VPN Microsoft depuis mon poste Windows
sur mon réseau local vers le serveur d'un client au travers d'un
firewall linux RedHat (2.4.3-12) en Masquerade.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
J'ai un problème avec un accès VPN Microsoft depuis mon poste Windows sur mon réseau local vers le serveur d'un client au travers d'un firewall linux RedHat (2.4.3-12) en Masquerade.
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien !
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ? On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
C'est particulier comme format, il n'y a même pas les adresses sources et destination. Quelle version de tcpdump, lancée avec quelles options ?
Filtres itables mise en place pour autorisation :
eth0 est l'interface local du reseau ($LOCAL_INTERFACE).
-- Filtre TCP ----
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop.
+ les filtres qui vont bien pour les retours.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
iptables -A INPUT -p 47 -i $LOCAL_INTERFACE -j ACCEPT iptables -A OUTPUT -p 47 -o $EXTERNAL_INTERFACE -j ACCEPT
Sert à rien, les paquets routés ne traversent pas ces chaînes.
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché. Sans ces modules, on ne peut établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné.
Salut,
J'ai un problème avec un accès VPN Microsoft depuis mon poste Windows
sur mon réseau local vers le serveur d'un client au travers d'un
firewall linux RedHat (2.4.3-12) en Masquerade.
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est
antédiluvien !
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ?
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer
aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux
interfaces du routeur et comparer.
C'est particulier comme format, il n'y a même pas les adresses sources
et destination. Quelle version de tcpdump, lancée avec quelles options ?
Filtres itables mise en place pour autorisation :
eth0 est l'interface local du reseau ($LOCAL_INTERFACE).
-- Filtre TCP ----
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport
--sport $UNPRIVPORTS --dport 1723
-m state --state NEW -j ACCEPT
Il y a un --sport en trop.
+ les filtres qui vont bien pour les retours.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
--- Filtre spécifique pour le protocol GRE (47) ---
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
iptables -A INPUT -p 47 -i $LOCAL_INTERFACE -j ACCEPT
iptables -A OUTPUT -p 47 -o $EXTERNAL_INTERFACE -j ACCEPT
Sert à rien, les paquets routés ne traversent pas ces chaînes.
Note :
Il existe des modules de suivi de connexion et NAT pour le protocole
PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été
intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les
noyaux précédents, il fallait appliquer un patch. Le noyau de ta
distribution a peut-être été patché. Sans ces modules, on ne peut
établir qu'une seule connexion PPTP entre des clients masqués derrière
une même adresse IP et un serveur extérieur donné.
J'ai un problème avec un accès VPN Microsoft depuis mon poste Windows sur mon réseau local vers le serveur d'un client au travers d'un firewall linux RedHat (2.4.3-12) en Masquerade.
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien !
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ? On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
C'est particulier comme format, il n'y a même pas les adresses sources et destination. Quelle version de tcpdump, lancée avec quelles options ?
Filtres itables mise en place pour autorisation :
eth0 est l'interface local du reseau ($LOCAL_INTERFACE).
-- Filtre TCP ----
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop.
+ les filtres qui vont bien pour les retours.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
iptables -A INPUT -p 47 -i $LOCAL_INTERFACE -j ACCEPT iptables -A OUTPUT -p 47 -o $EXTERNAL_INTERFACE -j ACCEPT
Sert à rien, les paquets routés ne traversent pas ces chaînes.
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché. Sans ces modules, on ne peut établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné.
Pierre
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien ! C'est la réponse de uname -a : Linux 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT
2001 i686 unknown
Qu'est-ce qui est capturé, et à quel endroit ? Juste avant le lancement de la connexion depuis le PC et visualisé
depuis une autre pc.
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
14:57:54.011897 eth0 < gre-proto-0x880B (gre encap) C'est particulier comme format, il n'y a même pas les adresses sources
et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump host IPdeMonPC
tcpdump version 3.4 libpcap version 0.4
Filtres itables mise en place pour autorisation :
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop. Oui, erreur de copier/coller dans le post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ? iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p tcp ! --syn -j ACCEPT
En fait, les requettes en tcp marche pour tous les ports.
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ? J'ai fait la modif suivante :
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT
Pas de changement dans la trace
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché. Je ne pense pas.
Sans ces modules, on ne peut
établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné. 1 seul connexion à la fois me suffit.
Merci.
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est
antédiluvien !
C'est la réponse de uname -a : Linux 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT
2001 i686 unknown
Qu'est-ce qui est capturé, et à quel endroit ?
Juste avant le lancement de la connexion depuis le PC et visualisé
depuis une autre pc.
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer
aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux
interfaces du routeur et comparer.
14:57:54.011897 eth0 < gre-proto-0x880B (gre encap)
C'est particulier comme format, il n'y a même pas les adresses sources
et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump host IPdeMonPC
tcpdump version 3.4
libpcap version 0.4
Filtres itables mise en place pour autorisation :
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport
--sport $UNPRIVPORTS --dport 1723
-m state --state NEW -j ACCEPT
Il y a un --sport en trop.
Oui, erreur de copier/coller dans le post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p tcp ! --syn -j ACCEPT
En fait, les requettes en tcp marche pour tous les ports.
--- Filtre spécifique pour le protocol GRE (47) ---
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
J'ai fait la modif suivante :
# -- Paquet de connection ------
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE
-m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte --------------------
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p 47 -m state --state ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte ---
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISED -j ACCEPT
Pas de changement dans la trace
Note :
Il existe des modules de suivi de connexion et NAT pour le protocole
PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été
intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les
noyaux précédents, il fallait appliquer un patch. Le noyau de ta
distribution a peut-être été patché.
Je ne pense pas.
Sans ces modules, on ne peut
établir qu'une seule connexion PPTP entre des clients masqués derrière
une même adresse IP et un serveur extérieur donné.
1 seul connexion à la fois me suffit.
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien ! C'est la réponse de uname -a : Linux 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT
2001 i686 unknown
Qu'est-ce qui est capturé, et à quel endroit ? Juste avant le lancement de la connexion depuis le PC et visualisé
depuis une autre pc.
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
14:57:54.011897 eth0 < gre-proto-0x880B (gre encap) C'est particulier comme format, il n'y a même pas les adresses sources
et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump host IPdeMonPC
tcpdump version 3.4 libpcap version 0.4
Filtres itables mise en place pour autorisation :
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop. Oui, erreur de copier/coller dans le post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ? iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p tcp ! --syn -j ACCEPT
En fait, les requettes en tcp marche pour tous les ports.
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ? J'ai fait la modif suivante :
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT
Pas de changement dans la trace
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché. Je ne pense pas.
Sans ces modules, on ne peut
établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné. 1 seul connexion à la fois me suffit.
Merci.
Pascal Hambourg
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien !
Oui, je sais, c'est pas d'hier, mais je ne peux pas faire de maj pour l'instant.
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ?
Juste avant le lancement de la connexion du VPN, et sur le linux dans une session sur un autre PC.
Je voulais dire "à quel endroit du réseau". Est-ce sur le routeur qui fait le filtrage et le masquerading ? Si oui, l'interface eth0 qui figure dans les lignes, est-ce l'interface interne ou externe ?
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
commande : tcpdump src IPdeMonPC
Forcément, avec une telle commande, on ne voit qu'un seul sens. Il vaudrait mieux capturer tout le trafic, et pas seulement les paquets émis par ton PC. Avec 'host <IPClient>' à la place de 'src <IPdeMonPC>' par exemple. Et en spécifiant l'interface de capture avec l'option '-i <interface>'. Et pourquoi pas un peu de détail avec une option '-v'.
C'est particulier comme format, il n'y a même pas les adresses sources et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump version 3.4
libpcap version 0.4
Pas tout jeune non plus. Mon tcpdump 3.8 m'affiche les adresses quand il capture du trafic GRE.
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop.
Oui , c'est un copier/coller intempestif lors de la rédaction du post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
Oui, c'est bon de ce coté la aussi !. En fait je n'ai pas de problème avec le port 1723.
Je m'en doutais puisqu'on voit le ACK de ton PC qui répond certainement au SYN/ACK du serveur.
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
Oui, ca je ne sait pas !.
Il faut regarder les règles ! Y a-t-il une règle générale du genre :
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Si non, tu peux ajouter une règle plus spécifique pour le GRE :
iptables -A FORWARD -p 47 -m state --state RELATED,ESTABLISHED -j ACCEPT
Si tu n'es pas sûr, tu peux publier le jeu de règles complet s'il n'est pas trop long.
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché.
Je ne pense pas.
Il ne s'agit pas de supposer mais de vérifier la présence ou non de ces modules ! :-D
Sans ces modules, on ne peut établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné.
1 seul a la fois me suffit.
Dans ce cas autoriser les connexions sortantes en TCP/1723 et GRE (ainsi que le trafic retour) devrait suffire.
PS : Pourquoi m'avoir répondu en privé plutôt que dans le forum, avec une adresse probablement invalide (rien.com est enregistré au Brésil) ?
PPS : Une adresse invalide se signale avec le suffixe ".invalid".
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est
antédiluvien !
Oui, je sais, c'est pas d'hier, mais je ne peux pas faire de maj pour
l'instant.
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ?
Juste avant le lancement de la connexion du VPN, et sur le linux dans
une session sur un autre PC.
Je voulais dire "à quel endroit du réseau". Est-ce sur le routeur qui
fait le filtrage et le masquerading ? Si oui, l'interface eth0 qui
figure dans les lignes, est-ce l'interface interne ou externe ?
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer
aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux
interfaces du routeur et comparer.
commande : tcpdump src IPdeMonPC
Forcément, avec une telle commande, on ne voit qu'un seul sens. Il
vaudrait mieux capturer tout le trafic, et pas seulement les paquets
émis par ton PC. Avec 'host <IPClient>' à la place de 'src <IPdeMonPC>'
par exemple. Et en spécifiant l'interface de capture avec l'option '-i
<interface>'. Et pourquoi pas un peu de détail avec une option '-v'.
C'est particulier comme format, il n'y a même pas les adresses sources
et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump version 3.4
libpcap version 0.4
Pas tout jeune non plus. Mon tcpdump 3.8 m'affiche les adresses quand il
capture du trafic GRE.
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport
--sport $UNPRIVPORTS --dport 1723
-m state --state NEW -j ACCEPT
Il y a un --sport en trop.
Oui , c'est un copier/coller intempestif lors de la rédaction du post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
Oui, c'est bon de ce coté la aussi !.
En fait je n'ai pas de problème avec le port 1723.
Je m'en doutais puisqu'on voit le ACK de ton PC qui répond certainement
au SYN/ACK du serveur.
--- Filtre spécifique pour le protocol GRE (47) ---
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
Oui, ca je ne sait pas !.
Il faut regarder les règles ! Y a-t-il une règle générale du genre :
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Si non, tu peux ajouter une règle plus spécifique pour le GRE :
iptables -A FORWARD -p 47 -m state --state RELATED,ESTABLISHED -j ACCEPT
Si tu n'es pas sûr, tu peux publier le jeu de règles complet s'il n'est
pas trop long.
Note :
Il existe des modules de suivi de connexion et NAT pour le protocole
PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été
intégrés au noyau Linux standard que depuis la version 2.6.14. Pour
les noyaux précédents, il fallait appliquer un patch. Le noyau de ta
distribution a peut-être été patché.
Je ne pense pas.
Il ne s'agit pas de supposer mais de vérifier la présence ou non de ces
modules ! :-D
Sans ces modules, on ne peut
établir qu'une seule connexion PPTP entre des clients masqués derrière
une même adresse IP et un serveur extérieur donné.
1 seul a la fois me suffit.
Dans ce cas autoriser les connexions sortantes en TCP/1723 et GRE (ainsi
que le trafic retour) devrait suffire.
PS : Pourquoi m'avoir répondu en privé plutôt que dans le forum, avec
une adresse probablement invalide (rien.com est enregistré au Brésil) ?
PPS : Une adresse invalide se signale avec le suffixe ".invalid".
2.4.3, c'est la version du noyau ? Si c'est le cas, alors ce noyau est antédiluvien !
Oui, je sais, c'est pas d'hier, mais je ne peux pas faire de maj pour l'instant.
Voici la trace avec tcpdump :
Qu'est-ce qui est capturé, et à quel endroit ?
Juste avant le lancement de la connexion du VPN, et sur le linux dans une session sur un autre PC.
Je voulais dire "à quel endroit du réseau". Est-ce sur le routeur qui fait le filtrage et le masquerading ? Si oui, l'interface eth0 qui figure dans les lignes, est-ce l'interface interne ou externe ?
On ne voit que les paquets envoyés par IPdeMonPC, il faudrait capturer aussi le trafic dans l'autre sens. Il faudrait aussi capturer aux deux interfaces du routeur et comparer.
commande : tcpdump src IPdeMonPC
Forcément, avec une telle commande, on ne voit qu'un seul sens. Il vaudrait mieux capturer tout le trafic, et pas seulement les paquets émis par ton PC. Avec 'host <IPClient>' à la place de 'src <IPdeMonPC>' par exemple. Et en spécifiant l'interface de capture avec l'option '-i <interface>'. Et pourquoi pas un peu de détail avec une option '-v'.
C'est particulier comme format, il n'y a même pas les adresses sources et destination. Quelle version de tcpdump, lancée avec quelles options ?
tcpdump version 3.4
libpcap version 0.4
Pas tout jeune non plus. Mon tcpdump 3.8 m'affiche les adresses quand il capture du trafic GRE.
iptables -A FORWARD -o $EXTERNAL_INTERFACE -p tcp --sport --sport $UNPRIVPORTS --dport 1723 -m state --state NEW -j ACCEPT
Il y a un --sport en trop.
Oui , c'est un copier/coller intempestif lors de la rédaction du post.
Et pour les paquets suivants (ESTABLISHED) dans le même sens ?
Oui, c'est bon de ce coté la aussi !. En fait je n'ai pas de problème avec le port 1723.
Je m'en doutais puisqu'on voit le ACK de ton PC qui répond certainement au SYN/ACK du serveur.
--- Filtre spécifique pour le protocol GRE (47) --- iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
Et pour le retour, dans l'autre sens ?
Oui, ca je ne sait pas !.
Il faut regarder les règles ! Y a-t-il une règle générale du genre :
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Si non, tu peux ajouter une règle plus spécifique pour le GRE :
iptables -A FORWARD -p 47 -m state --state RELATED,ESTABLISHED -j ACCEPT
Si tu n'es pas sûr, tu peux publier le jeu de règles complet s'il n'est pas trop long.
Note : Il existe des modules de suivi de connexion et NAT pour le protocole PPTP nommés ip_conntrack_pptp et ip_nat_pptp, mais qui n'ont été intégrés au noyau Linux standard que depuis la version 2.6.14. Pour les noyaux précédents, il fallait appliquer un patch. Le noyau de ta distribution a peut-être été patché.
Je ne pense pas.
Il ne s'agit pas de supposer mais de vérifier la présence ou non de ces modules ! :-D
Sans ces modules, on ne peut établir qu'une seule connexion PPTP entre des clients masqués derrière une même adresse IP et un serveur extérieur donné.
1 seul a la fois me suffit.
Dans ce cas autoriser les connexions sortantes en TCP/1723 et GRE (ainsi que le trafic retour) devrait suffire.
PS : Pourquoi m'avoir répondu en privé plutôt que dans le forum, avec une adresse probablement invalide (rien.com est enregistré au Brésil) ?
PPS : Une adresse invalide se signale avec le suffixe ".invalid".
Pascal Hambourg
J'ai fait la modif suivante :
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi ne pas fusionner ces deux règles en une :
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ?
Pas de changement dans la trace
Dans un premier temps il faut capturer le trafic sur l'interface externe de la passerelle pour vérifier que les paquets GRE sont bien émis et reçus.
J'ai fait la modif suivante :
# -- Paquet de connection ------
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE
-m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte --------------------
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi
ne pas fusionner ces deux règles en une :
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte ---
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISED -j ACCEPT
^^^
C'est une erreur de frappe dans le message ou dans le script ?
Pas de changement dans la trace
Dans un premier temps il faut capturer le trafic sur l'interface externe
de la passerelle pour vérifier que les paquets GRE sont bien émis et reçus.
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi ne pas fusionner ces deux règles en une :
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ?
Pas de changement dans la trace
Dans un premier temps il faut capturer le trafic sur l'interface externe de la passerelle pour vérifier que les paquets GRE sont bien émis et reçus.
Pierre
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi ne pas fusionner ces deux règles en une :
Je ne suis pas trop doué dans les règles iptables !.
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ? C'est une erreur de frappe dans le script, merci.
Modif fait :
# -- Paquet en sortie GRE ------ iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres bêtises mais à ma décharge je ne fait pas souvent du Linux.
A+ Pierre.
# -- Paquet de connection ------
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE
-m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte --------------------
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi
ne pas fusionner ces deux règles en une :
Je ne suis pas trop doué dans les règles iptables !.
# -- Internet -> Local => ok si connecte ---
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISED -j ACCEPT
^^^
C'est une erreur de frappe dans le message ou dans le script ?
C'est une erreur de frappe dans le script, merci.
Modif fait :
# -- Paquet en sortie GRE ------
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte ---
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres
bêtises mais à ma décharge je ne fait pas souvent du Linux.
# -- Paquet de connection ------ iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -m state --state NEW -j ACCEPT
# -- Paquet en sortie connecte -------------------- iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
Ça manque un peu de cohérence. Tantôt -s, tantôt -i... Aussi, pourquoi ne pas fusionner ces deux règles en une :
Je ne suis pas trop doué dans les règles iptables !.
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ? C'est une erreur de frappe dans le script, merci.
Modif fait :
# -- Paquet en sortie GRE ------ iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres bêtises mais à ma décharge je ne fait pas souvent du Linux.
A+ Pierre.
Pascal Hambourg
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ? C'est une erreur de frappe dans le script, merci.
Alors, on ne vérifie pas les messages d'erreur quand on teste un nouveau script ? ;-) Certes ce n'est pas toujours trivial, par exemple quand le script est exécuté au démarrage sans console (ou masqué par un affichage graphique) ou par pppd qui redirige la sortie standard vers /dev/null.
Modif fait :
# -- Paquet en sortie GRE ------ iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Bien. Merci pour le retour. Accessoirement, une règle générale pour accepter tout le trafic établi au lieu d'une règle pour TCP, une règle pour GRE... et on n'en parlerait plus.
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres bêtises mais à ma décharge je ne fait pas souvent du Linux.
Il ne faut pas hésiter à le signaler sinon j'ai tendance à supposer que les administrateurs de machines Linux maîtrisent bien leur OS (sauf moi bien sûr, mais moi je me connais), et par conséquent à en dire trop peu plutôt que trop. C'est sûrement que je n'ai pas trop envie de vexer ou qu'on me réponde après une longue tartine détaillée quelque chose du genre "hé ho, pas besoin de me tenir par la main pas à pas, je sais taper une règle iptables et faire une capture réseau quand même". :-)
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISED -j ACCEPT
^^^
C'est une erreur de frappe dans le message ou dans le script ?
C'est une erreur de frappe dans le script, merci.
Alors, on ne vérifie pas les messages d'erreur quand on teste un nouveau
script ? ;-)
Certes ce n'est pas toujours trivial, par exemple quand le script est
exécuté au démarrage sans console (ou masqué par un affichage graphique)
ou par pppd qui redirige la sortie standard vers /dev/null.
Modif fait :
# -- Paquet en sortie GRE ------
iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE
-s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte ---
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE
-p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Bien. Merci pour le retour. Accessoirement, une règle générale pour
accepter tout le trafic établi au lieu d'une règle pour TCP, une règle
pour GRE... et on n'en parlerait plus.
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres
bêtises mais à ma décharge je ne fait pas souvent du Linux.
Il ne faut pas hésiter à le signaler sinon j'ai tendance à supposer que
les administrateurs de machines Linux maîtrisent bien leur OS (sauf moi
bien sûr, mais moi je me connais), et par conséquent à en dire trop peu
plutôt que trop. C'est sûrement que je n'ai pas trop envie de vexer ou
qu'on me réponde après une longue tartine détaillée quelque chose du
genre "hé ho, pas besoin de me tenir par la main pas à pas, je sais
taper une règle iptables et faire une capture réseau quand même". :-)
iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISED -j ACCEPT ^^^
C'est une erreur de frappe dans le message ou dans le script ? C'est une erreur de frappe dans le script, merci.
Alors, on ne vérifie pas les messages d'erreur quand on teste un nouveau script ? ;-) Certes ce n'est pas toujours trivial, par exemple quand le script est exécuté au démarrage sans console (ou masqué par un affichage graphique) ou par pppd qui redirige la sortie standard vers /dev/null.
Modif fait :
# -- Paquet en sortie GRE ------ iptables -A FORWARD -i $LOCAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LOCALNET -p 47 -m state --state NEW,ESTABLISHED -j ACCEPT
# -- Internet -> Local => ok si connecte --- iptables -A FORWARD -i $EXTERNAL_INTERFACE -o $LOCAL_INTERFACE -p 47 -m state --state ESTABLISHED -j ACCEPT
CA MARCHE !!!!!!!!!
Bien. Merci pour le retour. Accessoirement, une règle générale pour accepter tout le trafic établi au lieu d'une règle pour TCP, une règle pour GRE... et on n'en parlerait plus.
Merci pour ton aide et excuse moi pour mes fautes de frappe et autres bêtises mais à ma décharge je ne fait pas souvent du Linux.
Il ne faut pas hésiter à le signaler sinon j'ai tendance à supposer que les administrateurs de machines Linux maîtrisent bien leur OS (sauf moi bien sûr, mais moi je me connais), et par conséquent à en dire trop peu plutôt que trop. C'est sûrement que je n'ai pas trop envie de vexer ou qu'on me réponde après une longue tartine détaillée quelque chose du genre "hé ho, pas besoin de me tenir par la main pas à pas, je sais taper une règle iptables et faire une capture réseau quand même". :-)