Accès Premium
GNT sans publicité, site mobile, fonctionnalitées exclusives...
Rejoignez-nous !
Forums Matériel Réseaux et Internet IP

Problème avec le protocol GRE, iptables, Linux

Le
Pierre
Bonjour,

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.

Voici la trace avec tcpdump :

14:57:49.771897 eth0 < IPdeMonPC.2067 > IPClient.1723: S
2641168470:2641168470(0) win 64512 <mss 1380,nop,nop,sackOK> (DF)
14:57:50.461897 eth0 < arp reply IPdeMonPC is-at 0:11:11:e3:8:1f
(0:2:55:22:ac:1)
14:57:50.461897 eth0 < IPdeMonPC.2067 > IPClient.1723: P
2641168471:2641168627(156) ack 34386952 win 64860 (DF)
14:57:51.221897 eth0 < IPdeMonPC.2067 > IPClient.1723: P 156:324(168)
ack 157 win 64704 (DF)
14:57:52.001897 eth0 < IPdeMonPC.2067 > IPClient.1723: P 324:348(24) ack
189 win 64672 (DF)
14:57:52.021897 eth0 < gre-proto-0x880B (gre encap)
14:57:53.031897 eth0 < IPdeMonPC.2067 > IPClient.1723: . 348:348(0) ack
213 win 64648 (DF)
14:57:54.011897 eth0 < gre-proto-0x880B (gre encap)
14:57:57.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:01.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:05.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:09.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:13.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:17.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:21.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:25.011897 eth0 < gre-proto-0x880B (gre encap)
14:58:29.011897 eth0 < IPdeMonPC.2067 > IPClient.1723: P 348:364(16) ack
213 win 64648 (DF)
14:58:29.341897 eth0 < IPdeMonPC.2067 > IPClient.1723: . 364:364(0) ack
361 win 64500 (DF)
14:58:30.011897 eth0 < IPdeMonPC.2067 > IPClient.1723: P 364:380(16) ack
361 win 64500 (DF)
14:58:30.261897 eth0 < IPdeMonPC.2067 > IPClient.1723: F 380:380(0) ack
361 win 64500 (DF)
14:58:30.541897 eth0 < IPdeMonPC.2067 > IPClient.1723: R 381:381(0) ack
361 win 0 (DF)
14:58:34.101897 eth0 < arp reply IPdeMonPC is-at 0:11:11:e3:8:1f
(0:2:55:22:ac:1)


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

+ les filtres qui vont bien pour les retours.


Filtre spécifique pour le protocol GRE (47)
iptables -A FORWARD -p 47 -s $LOCALNET -o $EXTERNAL_INTERFACE -j ACCEPT
iptables -A INPUT -p 47 -i $LOCAL_INTERFACE -j ACCEPT
iptables -A OUTPUT -p 47 -o $EXTERNAL_INTERFACE -j ACCEPT

Bloquage sur la ligne : eth0 < gre-proto-0x880B (gre encap)

Merci par avance de votre aide.
Pierre.
Lire les 6 réponses

Questions / Réponses high-tech
Poser une question
Vidéos High-Tech et Jeu Vidéo
Plus de vidéos
Téléchargements
Plus de téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #839083
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.

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 ?

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é.

Répondre en citant
Pierre
Le #839082
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.


Répondre en citant
Pascal Hambourg
Le #839081
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

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 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".



Répondre en citant
Pascal Hambourg
Le #838865
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.

Répondre en citant
Pierre
Le #838863
# -- 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.


Répondre en citant
Publicité
Suivre les réponses
Poster une réponse
Anonyme