# [Iptables] NAT et blocage involontaire [Rouvert]

## Jamesbch

Bonjour à tous,

EDIT 25.02.09: Vous n'avez pas besoin de tout relire, la discussion résumée et reprise reprend plus bas ici

---

ça fait quelques temps que j'essaie de faire un NAT en utilisant mon petit serveur de maison plutôt que d'utiliser le routeur. Malheureusement après plusieurs essais je n'arrive toujours pas à ce que je voudrais. La majeure partie du NAT fonctionne correcteur avec quelques bidouillages mais malgré cela certaines choses sont bloquées je ne sais pourquoi.

Par exemple je peux citer certains sites que je ne peux pas accéder après le NAT perso: hotmail.com, myspace.com. Il y a aussi MSN où je n'arrive pas à me connecter. Par contre la majeure partie des sites comme gentoo.org et la messagerie Jabber sont totalement fonctionnel. Dans les jeux par exemple WoW se connecte jusqu'à "Terminé !" mais ne va pas plus loin, par contre Warcraft III semble totalement fonctionnel.

Je n'arrive pas bien à cerner les points communs entre ces différentes connexions néanmoins je peux voir sur les logs ce qui est refusé.

Voici ma configuration iptables avec les commentaire et mes modifications :

Petites informations avant tout :

- eth1 est la carte du serveur relié au routeur.

- eth2 est la carte du serveur relié au switch du réseau local.

- ppp0 est l'interface virtuelle qui "numérote" auprès du routeur en passant par eth1.

- Le routeur n'est pas relié au réseau local, il est relié uniquement au serveur par eth1.

http://pastebin.com/f4d19f40e

C'est pas du tout ordonné parce que je n'arrête pas de le modifier, j'améliorerais plus tard  :Laughing: 

 :Arrow:  Pour hotmail j'obtient ceci en diff de dmesg (avant connexion et après fermeture du navigateur) : (sachant que 65.54.186.19 est le site de hotmail et 192.168.1.4 le pc qui essaie d'y accéder)

 *Quote:*   

> JServer ~ # diff dmesg1.txt dmesg3.txt
> 
> 1131a1132,1135
> 
> > DROPl:IN=eth2 OUT=ppp0 SRC=192.168.1.4 DST=65.54.186.19 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=2538 DF PROTO=TCP SPT=2808 DPT=80 WINDOW=64730 RES=0x00 ACK FIN URGP=0
> ...

 

 :Arrow:  J'ai aussi essayer pour WoW mais apparemment la seule ligne qui est modifiée, c'est quand WoW est fermé et pas avant quand j'essaie de me connecter. (Le blocage quand le jeu est arrêté semble normal puisque le jeu ferme les connexions et que le serveur doit refuser internet d'entrer dans le LAN). Enfin c'est pas très clair voici ce entre le moment de connexion et après la fermeture du jeu :

 *Quote:*   

> JServer ~ # diff dmesg1.txt dmesg4.txt
> 
> 1141a1142
> 
> > DROPl:IN=ppp0 OUT= MAC= SRC=81.62.80.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=4648 PROTO=2

 

Je ne devrais pas me fier aux logs finalement puisque c'est quand les connexions sont fermées sur le client que le DROPl est signalé. Du coup je ne sais pas où regarder ce qui cloche.

Si vous avez des idées je vous en serez très reconnaissant ! Merci d'avance !

----------

## scherz0

Il est probable que le blocage des paquets ACK/FIN hors contexte soit la cause des problèmes décrits.  La machine qui a ces difficultés de connexion est-elle sous windows 2000 (ou assimilé) ? Si oui, c'est un problème assez classique.

Je suggère d'essayer d'autoriser ces paquets, par exemple en ajoutant en ligne 314 :

$IPT -A FORWARD -p tcp --tcp-flags ALL ACK,FIN  -j ACCEPT

Éventuellement, ajouter les restrictions nécessaires sur l'origine, la destination, les interfaces, etc...

----------

## loopx

J'ai plus ou moins la même topologie que toi, sauf que j'ai un routeur relié à mon serveur et que c'est lui qui s'occupe d'internet (et de refaire un NAT). En toute logique, si tu as fait un NAT (masquerade) sur tout ce qui sort par ETH1 (ou peut être ppp0), cela doit fonctionner mais n'oublie pas que pour un jeux, tu dois non seulement ouvrir les ports sur ton routeurs, mais aussi sur ton serveur ... pour la simple et bonne raison que ton (mon) routeur ne connais pas le reso de mon LAN, il doit donc tout renvoyer à mon serveur qui re-envoie au bon PC.

Je ne vois vraiment pas la raison pour laquel certain site fonctionne et pas d'autre, donc ... vérifie que tu vide bien toutes les chaines de iptables quand tu fais des modifications, et jette peut être un oeil à la table de routage (route -n) ... ca m'étonnerais quand meme qu'une route en plus soit ajoutée pour hotmail   :Laughing:  .

Essaie de ne pas jouer avec le firewall, essaie de faire d'abord fonctionner ton NAT  :Wink: 

----------

## Jamesbch

Bonjour à vous,

Merci de vos réponses tout d'abord.

Comme tu le dis scherz0, en effet, les machines clientes dont la mienne sont sous Windows XP (jeux obligent). Je vais essayer comme tu dis. D'après ce que j'ai vu ACK,FIN c'est un paquet pour fermer une connexion mais pour Windows uniquement ? Enfin j'ai très vite regarder.

Oui loopx, c'est vrai que c'est étrange mais les ports sur le serveur ne sont pas bloqués (en entrée) et donc par toute logique ça passe (enfin je crois). Si je peux accéder à un site quelqu'il soit, ça signifie déjà que les ports sont ouverts sur le serveur du moins ceux en sortie (ce qui est aussi le cas en général chez les routeurs. Pour ouvrir un port sur un Pc interne, il faut ajouer une règle à iptables spécifique NAT et firewall, ce qui ne me préoccupe pas car je l'ai déjà fait avec succès). Pour le moment comme je le dis il est en mode bridge, c'est le serveur qui numérote SUR le routeur pour se connecter et donc c'est le serveur qui s'occupe du PPPoE.

Ce qui concerne les sites je peux deviner à l'intuition que les serveurs WEB utilisé pour les sites sont ceux d'un système Windows peut-être ? ce qui expliquerait pourquoi il faut accepter les ACK. Enfin ce n'est qu'une supposition. Et comme j'ai dis avant si un site est accessible (sur internet bien sûr) c'est que la table route est correcte. De plus je l'ai refaite et controlée pour qu'elle soit juste.

"Essaie de ne pas jouer avec le firewall, essaie de faire d'abord fonctionner ton NAT" ???

Le serveur s'occupe du NAT avec iptables, je suis obligé de m'occuper du firewall et du NAT en même temps puisqu'ils sont complémentaire pour se connecter à internet. Enfin j'ai peut-être mal interpreté ta phrase.

Je vais retenter l'aventure dans quelques jours et essayer ce que scherz0 m'a conseillé. Merci à vous deux et je vous tient au courrant.

Bonne jounrée.

----------

## scherz0

 *Jamesbch wrote:*   

> 
> 
> Comme tu le dis scherz0, en effet, les machines clientes dont la mienne sont sous Windows XP (jeux obligent). Je vais essayer comme tu dis. D'après ce que j'ai vu ACK,FIN c'est un paquet pour fermer une connexion mais pour Windows uniquement ? Enfin j'ai très vite regarder.
> 
> 

 

Non, ça fait partie de TCP, mais je crois que la pile de windows peut éventuellement fermer une connexion déjà fermée.  D'ou le ACK/FIN hors contexte : pour ton firewall, ce paquet ne fait partie d'aucune connexion établie.

 *Quote:*   

> 
> 
> Ce qui concerne les sites je peux deviner à l'intuition que les serveurs WEB utilisé pour les sites sont ceux d'un système Windows peut-être ? ce qui expliquerait pourquoi il faut accepter les ACK. Enfin ce n'est qu'une supposition.
> 
> 

 

Je partage cette intuition  :Wink: 

 *Jamesbch wrote:*   

> 
> 
>  *loopx wrote:*   "Essaie de ne pas jouer avec le firewall, essaie de faire d'abord fonctionner ton NAT" ??? 
> 
> Le serveur s'occupe du NAT avec iptables, je suis obligé de m'occuper du firewall et du NAT en même temps puisqu'ils sont complémentaire pour se connecter à internet. Enfin j'ai peut-être mal interpreté ta phrase.
> ...

 

Est-ce utile de filtrer les paquets sortants ?  Ça complique la mise au point (cf ce problème ACK/FIN).

Par ailleurs, je n'ai pas eu le courage de lire ton script entièrement, mais j'ai l'intituion qu'il génère un ensemble de règles assez complexe, et peut-être redondant.  Pour satisfaire ma curiosité, peux-tu poster le résultat de 

```
iptables -t filter -L -n -v
```

Et en fait, il est généralement plus simple de résoudre ce genre de problème en regardant les règles effectives, plutôt qu'en regardant le script qui a généré ces règles.

----------

## loopx

heu, je veux dire que, pour faire de l'iptables et résoudre les problèmes, mieux vaut ne tirer que sur une ficelle à la fois  :Wink: . Donc, test d'abord le NAT sans jouer avec le firewall, après tu complètera ton script en bloquant ce que tu veux. Car si ton NAT est bon et que ton firewall pourri le tout, ben tu va passer des heures à chercher pour rien une bêtise...

----------

## Poussin

Bonjour,

Tout d'abord, bloquer un paquet ACK/FIN hors contexte est une bonne chose. Si la connexion est déjà terminée, à quoi pourrait bien servir un nouveau paquet de demande de fin de connexion...

Si tu pouvais maintenant nous sortir ta configuration iptables sous la forme "standard" (iptables -L -n -v et iptables -t nat -L -n -v), ce serait, je trouve, beaucoup plus simple à analyser   :Very Happy: 

Ca me parrait tout de même assez étrange le comportement différent en fonction du site. Je suis curieux de voir ce qui se passe ^^

----------

## scherz0

 *Poussin wrote:*   

> 
> 
> Tout d'abord, bloquer un paquet ACK/FIN hors contexte est une bonne chose.
> 
> 

 

Pourquoi ?

 *Quote:*   

> 
> 
> Si la connexion est déjà terminée, à quoi pourrait bien servir un nouveau paquet de demande de fin de connexion...
> 
> 

 

Ça sert à permettre à l'émetteur du paquet portant le ACK/FIN de fermer sa connexion.  Si le paquet est jeté (DROP), l'auteur reste en attente d'une réponse.  Je ne serais pas surpris que ce soit la cause de ses problèmes.

Ne pas oublier que la connexion est considérée terminée par le firewall, pas forcément par l'émetteur de ce paquet...

----------

## Poussin

 *scherz0 wrote:*   

>  *Poussin wrote:*   
> 
> Tout d'abord, bloquer un paquet ACK/FIN hors contexte est une bonne chose.
> 
>  
> ...

 

Pour moi, un paquet est hors contexte, s'il ne se situe pas entre une SYN et un FIN. Autrement dit, un paquet est hors contexte s'il ne fait pas partie d'une connexion établie. Hors, envoyer un demander de fermeture de connexion inexistante, au final, n'a aucun intéret. C'est sur ce type de condition que se base les firewall à état. Tout paquet transitant par un tel firewall et n'étant pas defini dans une connexion établie est rejeté. Bon, ok, il faut nuancer, une nouvelle connexion, par exemple, peut-etre autorisée :p

Sous iptables, c'est la clause --state ESTABLISHED qui teste cela. Personnellement, mon INPUT commence toujours par un --state INVALID -j DROP suivit d'un --state ESTABLISHED,RELATED -j ACCEPT

Enfin, je peux me tromper aussi :p

----------

## Jamesbch

Voilà j'ai continué les tests et j'ai plus d'informations à donner qu'avant. J'ai essayé sous ma Gentoo et le problème est toujours le même. Impossible d'aller sur les sites ni de se connecter à MSN. Il y a un petit changement sous ma Gentoo, j'arrive à charger la page de login de hotmail. J'essaie de me loguer mais ça c'est injoignable (https non accepté???). D'ailleurs quand j'essaie d'accéder à un site qui possède les symptomes, tous les autres sites que j'essaie d'accéder en parallèle sont fortement ralentit, sorte de saturation (je lance myspace par exemple ensuite un autre site, j'attends et dès que je ferme l'onglet de myspace, paf l'autre site se charge instantanément) ... Peut-être que ça peut aider.

Ce qui est du côté de MSN j'ai des nouvelles informations grâce au mode debug de Pidgin :

 *Quote:*   

> (12:05:22) msn: new httpconn (0x9922cf0)
> 
> (12:05:22) msn: C: NS 000: VER 1 MSNP15 CVR0
> 
> (12:05:22) msn: S: NS 000: VER 1 MSNP15
> ...

 

On dirait que ça s'auth jusqu'au moment où ça OUT "Ressource temporairement non disponible". Assez bizarre.  Mais ça veut dire qu'il y a arrive presque.

J'ai rajouté trois règles pour les ACK et je ne sais pas si ça change quelque chose, voici mon iptables -L : (xx.xx.xx.xx est mon ip sur internet)

http://rafb.net/p/IRPm0H16.html

Les 3 règles pour le ACK semblent ne rien changer au problème. Merci de votre patience et votre aide.

----------

## Jamesbch

Aucune idée ?

Est-ce qu'il y aurait des méthodes de débug, histoire de voir quels paquets passent, ne passent pas. Un logiciel qui testent les problèmes de connexions ? Quelque chose qui pourrait m'aider svp ?

----------

## kwenspc

tcpdump ?

----------

## ppg

wireshark ? netcat ?

----------

## Jamesbch

Je connais plus ou moins ces logiciels de sniffage ou manipulation réseau, et j'ai qu'une petite d'expérience avec ceux-ci. Maintenant dans la pratique comment est-ce je peux les utiliser efficacement ?

Si je me focalise sur un des problèmes, le site hotmail marchant un peu me convient pas et essayer MSN ou un jeu donnera trop d'informations à trier je pense, ça va pas. Je pensais par exemple m'en prendre au site myspace. Est-ce que je devrais sniffer sur mon PC les paquets qui parcourent le réseau lorsque tout fonctionne et comparer avec ma propre passerelle ? Est-ce que c'est la bonne méthode à appliquer ?

Aussi pendant que j'y penses quelles options me seraient utiles pour ces logiciels d'après vous ?

Je vous remercie déjà ppg et kwenspc pour vos réponses.

----------

## Jamesbch

Voilà alors j'ai fais quelques analyses et j'ai essayer ce que j'aurais dû faire dès le début. Tester sur la machine passerelle directement. Il s'avère que le serveur arrive à "surfer" (avec lynx ou links) sur myspace.com sans aucune difficulté. Bon alors ça veut dire que c'est le passage de paquets WAN <=> LAN qui a un problème. Mais lesquels ?

D'après ce que je vois avec Wireshark (vu que je l'avais déjà sur mon Windows) c'est:

- Passerelle routeur (traduire par quand tout est normal) tous les paquets sont en verts sauf deux en rouge-bordeaux à la fin. La page est chargée et prête.

- Passerelle mon serveur (traduire par quand j'essaie avec ma Gentoo) il y a du vert qu'au début, après il y a un paquet perdu ([TCP Previous segment lost] Continuation or non-HTTP traffic) en destination de mon PC, après il y a beaucoup de discussions entre mon pc et une ip de mon FAI (paquets en bleu-gris). Le site ne renvoie plus rien, il semble que j'envoie quelques requêtes pour redemander ? mais ça ne termine pas.

Je pourrais copier tous les paquets ici mais déjà c'est un peu génant sachant qu'il y a des ips personnelles et que c'est assez long. Avez-vous des idées à me proposer ?

Je pense qu'il y a un problème de règles iptables tout simplement, le dénouement n'est plus très loin. Je vous demande un petit coup de pouce encore.

PS : J'ai remis sur un pastebin les règles que j'ai dans iptables : (1ère partie les règles et 2ème partie le NAT uniquement ligne 130)

http://www.pastebin.ca/1330002

xx.xx.xx.xx étant l'IP internet attribuée par le FAI ; 192.168.1.2 et 192.168.1.4 étant les IP des PC accédant au NET ; 192.168.1.5 étant l'IP de l'interface liée au routeur vers le NET ;192.168.1.3 étant l'IP de l'interface liée au réseau local. Si y'a besoin d'un schéma n'hesitez pas.

----------

## Jamesbch

J'ai essayer de changer de script et j'ai obtenu un code beaucoup plus petit, plus simple. Le problème reste entier je n'arrive toujours pas à me connecter aux sites cités, ni à me connecter à MSN. Et je rappelle que le serveur qui fait le NAT arrive à se connecter à ces sites (pour MSN j'ai pas pu tester faute de client console sous la main) !

http://pastebin.com/f4e68f346

S'il vout plaît j'ai vraiment besoin de votre aide. Je dois comprendre ce qui ne joue pas avec une telle configuration.

----------

## scherz0

Sans la liste des paquets (re)jetés, difficile de déterminer ce qui se passe, à moins d'avoir sous la main le même client sur le même OS.

À defaut de cette liste, je ne peux que te suggèrer de contrôler deux points :

 - est-ce que ça fonctionne en vidant la chaine OUTPUT et en la mettant en ACCEPT ?  Ça permettrait d'être certain de bien situer le problème.

 - est-ce que ça fonctionne en remplaçant la cible de la 2ème règle de DROPl par ACCEPT ?  Si oui, tu auras dans les logs du noyau la liste des paquets qui auraient été jetés et qu'il faut laisser passer.

Bonne chasse...

----------

## kwenspc

Repart de zéro et à chaque règle ajoutée, vérifie que l'effet et bien celui recherché.

Bon je suis personellement une bille en iptables, j'avoue (je trouve la syntaxe totalemnt contre intuitive, contrairement à pf...), j'ai suivis ce tuto et pris le script fournit: http://www.gentoofr.org/Configuration-simplifiee-iptables.html

----------

## Jamesbch

 *scherz0 wrote:*   

> Sans la liste des paquets (re)jetés, difficile de déterminer ce qui se passe, à moins d'avoir sous la main le même client sur le même OS.
> 
> À defaut de cette liste, je ne peux que te suggèrer de contrôler deux points :
> 
>  - est-ce que ça fonctionne en vidant la chaine OUTPUT et en la mettant en ACCEPT ?  Ça permettrait d'être certain de bien situer le problème.
> ...

 

Pour ce qui est de la liste des paquets rejeté ils sont dans le premier post tout en haut (il est possible que ce ne soit pas les bons paquets, j'ai expliqué pourquoi).

J'ai essayé en flush'ant la chaîne OUTPUT et en mettant la politique ACCEPT par défaut mais aucun changement. De quelle règle parles-tu, la 2ème? Je n'ai plus de DROPl dans mon nouveau script (cf mon dernier post).

 *kwenspc wrote:*   

> Repart de zéro et à chaque règle ajoutée, vérifie que l'effet et bien celui recherché.
> 
> Bon je suis personellement une bille en iptables, j'avoue (je trouve la syntaxe totalemnt contre intuitive, contrairement à pf...), j'ai suivis ce tuto et pris le script fournit: http://www.gentoofr.org/Configuration-simplifiee-iptables.html

 

J'ai essayé de partir à peu près de zéro avec mon script du dernier post. J'ai repris les paramètres bien pratique du script d'avant qui cherche tout seuls les IPs, les masques et les interfaces. Je devrais peut-être essayer de m'en passer pour voir si cela joue un rôle dans mon problème, peut-être ? J'ai repris aussi la partie qui accepte l'interface lo, la partie FORWARD et PREROUTING. J'ai vraiment pris le minimum qui devrait permettre le NAT basique sans protection.

La page que tu donnes est un script assez basique qui n'est pas fait pour un NAT complet malheureusement. On dirait qu'il est accès utilisateur normal et non-serveur.

J'aimerais bien également un avi pour ceux qui utilisent le NAT, ce que vous utilisez comme règle de FORWARD de base pour un NAT basique. Pour ma part:

```
# NAT

$IPT -t nat -A PREROUTING  -j ACCEPT

$IPT -t nat -A POSTROUTING -o $EXTIF -s $INTNET1 -j MASQUERADE

$IPT -t nat -A POSTROUTING -o $EXTIF -s $INTNET2 -j MASQUERADE

$IPT -t nat -A POSTROUTING -j ACCEPT

$IPT -t nat -A OUTPUT -j ACCEPT

$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
```

PS: 

J'ai continué à chercher, j'ai refait la partie des paramètres moi même, j'ai même essayer un DMZ ciblé sur mon PC mais le problème pérsiste ! Voici mon dernier script avec le DMZ :

http://pastebin.com/f7e2e52a1

----------

## Jamesbch

Voilà ça fait un peu plus de un jour que j'ai trouvé la solution et c'est stable. Ca peut paraître bête mais il suffisait de rajouter deux lignes comme celles-ci :

 *Quote:*   

> iptables -A OUTPUT -o eth2 -d 192.168.1.4 -j ACCEPT
> 
> iptables -A FORWARD -i eth2 -s 192.168.1.4 -j ACCEPT

 

192.168.1.4 étant l'ordinateur qui doit se connecter à travers la passerelle. En fait je pense qu'on peut modifier cette règle pour l'appliquer à un sous-réseau entier (192.168.1.1/255.255.255.0). Il me semble que j'avais oublié d'accepter le OUTPUT, rien que ça. Bien sûr le FORWARD doit être présent. En éspérant que ça serve à quelqu'un.

Ceci dit, je retourne configurer le partage de la bande passante avec TC, très intéressant d'ailleurs mais difficile.

Merci à vous et à bientôt.

----------

## Jamesbch

Re-bonjour à tous,

Je rouvre le topic car je recontre à nouveau le problème mais d'une autre manière. Je résume les problèmes rencontrés : Impossibilités de se connecter à certains site (facebook.com ; yahoo.com ; hotmail.com) et certains services (msn ; wow) en ne citant que quelqu'uns. Ceci uniquement quand je fais un NAT avec ma gentoo et que je met mon routeur en mode bridge only. Le reste des sites et autres services (par exemple: Jabber) fonctionnent. Le problème est rencontré cette fois après une journée, soit d'après moi lorsque le reconnexion doit se refaire.

Pour retrouver toutes les capacités de ma connexion je dois, débrancher puis rebrancher le cable électrique de mon "routeur" (fonctionnant en mode bridge, donc modem uniquement). Suite à cela, la connexion PPPoE est refaite et tout fonctionne jusqu'à la prochaine reconnexion.

Je me dis que le routeur est en faute mais pourquoi est-ce que ce serait forcément lui qui aurait un problème sachant qu'en mode normal routeur+modem (pas de NAT sur la gentoo, mais direct depuis le routeur) ils n'y a aucun problème. De nouveau le problème reste étrange, pourquoi est-ce que je peux utiliser partiellement internet dans ces conditions. 

Qui est en faute alors? Le routeur ou la machine, peut-être les deux ?  :Mad: 

Est-ce que vous avez des idées d'en avoir le coeur net, merci d'avance.

----------

## Jamesbch

J'ai vraiment besoin d'aide, des idées suggestions ? Y'a sûrement moyen de tester la Gentoo pour voir si ça peut vient de ça?

----------

## kwenspc

Chais pas là c'est vraiment space ton truc  :Neutral: 

Si tu dois carrément réinitialiser ton routeur c'est que c'est probablement lui le coupable.

----------

## Jamesbch

 *kwenspc wrote:*   

> Chais pas là c'est vraiment space ton truc 
> 
> Si tu dois carrément réinitialiser ton routeur c'est que c'est probablement lui le coupable.

 

C'est possible mais je m'en demandais sachant que le routeur est directement relié par un RJ45 au serveur, si le fait de tirer le cable du routeur, ne ferme pas l'interface liée (ici eth1). En se faisant, réinitialise qqch qui bloquait dans le système Gentoo. Me semble que quand un cable RJ45 est débranché (équivalent à éteint), ça fais qqch de l'autre côté sur l'ordi encore branché. Ah je suis bête ! je peux essayer de tirer juste le cable pour voir. Je vous tiens au courrant (Il faut que le bug se reproduie pour tenter).

Si vous avez des idées, surtout n'hesitez pas j'en ai vraiment besoin.

----------

