Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème avec le protocol GRE, iptables, Linux

6 réponses
Avatar
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.

6 réponses

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

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

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


Avatar
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'.

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



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

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


Avatar
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". :-)