Problemes avec firewall + NAT avec iptables

par **ojacques** » 22 Sep 2004 01:08

Bonjour a tous,

ca fait quelque temps que je tourne autour de mon probleme, sans en trouver la solution.
Tout est decrit ici (avec un trace ethereal prise sur ma debian faisant office de firewall/routeur):
http://famillejacques.free.fr/fbx/

Le modem ADSL dont je cherche a partager la connexion est une freebox (v1).

Je reprend quelques elements de la page ici, pour faciliter la recherche dans le forum.

Configuration:
Client Windows XP - avec une interface ethernet, adresse statique 192.168.0.1 - default gateway: 192.168.0.2
Debian woody + iptables - avec deux interfaces ethernet:
eth0: dhcp (relie a la freebox)
eth1: 192.168.0.2 (relie a un switch - lui meme relie au client Win XP 192.168.0.1)
Freebox V1 (ADSL01)

Symptomes:
Du routeur Linux, aucun problemes
Du client windows, internet fonctionne mais est tres lent voir meme ne marche pas sur certains (gros) sites ou en telechargement (http get sur test-debit.free.fr)
Pour essayer de tracer tout ca, j'ai utilise ethereal en regardant a la fois les interfaces eth0 et eth1 du routeur. Le resultat est sur http://famillejacques.free.fr/fbx (fait avec http://callflow.sourceforge.net).

On peut y voir les choses suivantes:
La trame 15 est une retransmission de la trame 11 (envoyee 3s apres). Apparement le ACK de la trame 13, forwarde par iptables n'est jamais arrive.
D'autre trucs pas super se passent... Et je n'arrive pas vraiment a diagnostiquer ce qui se passe.
Voici les regles IPTABLES que j'utilise (honteusement recopie de l'excellent guide d'Alexis de Lattre (http://www.via.ecp.fr/~alexis/formation-linux/)

Code: Tout sélectionner: # iptables -v -L Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 8 560 ACCEPT all -- lo any anywhere anywhere 1 60 ACCEPT icmp -- any any anywhere anywhere 0 0 ACCEPT igmp -- any any anywhere anywhere 93 11008 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp-data 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp 1 52 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:1234 289 39115 REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable Chain FORWARD (policy ACCEPT 309 packets, 83914 bytes) pkts bytes target prot opt in out source destination 18 936 TCPMSS tcp -- any eth0 anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU Chain OUTPUT (policy ACCEPT 358 packets, 36218 bytes) pkts bytes target prot opt in out source destination

Code: Tout sélectionner: # iptables -v -L -t nat Chain PREROUTING (policy ACCEPT 241 packets, 29572 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 13 packets, 2054 bytes) pkts bytes target prot opt in out source destination 42 3567 MASQUERADE all -- any eth0 anywhere anywhere Chain OUTPUT (policy ACCEPT 27 packets, 4080 bytes) pkts bytes target prot opt in out source destination

Code: Tout sélectionner: # ifconfig eth0 Link encap:Ethernet HWaddr 00:80:C8:C0:F9:F1 inet addr:XX.XX.XX.XX Bcast:XX.XX.XX.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:373 errors:0 dropped:0 overruns:0 frame:20 TX packets:436 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:101922 (99.5 KiB) TX bytes:46393 (45.3 KiB) Interrupt:12 Base address:0xd000 eth1 Link encap:Ethernet HWaddr 00:50:BF:99:03:36 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:602 errors:0 dropped:0 overruns:0 frame:0 TX packets:651 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:64767 (63.2 KiB) TX bytes:134088 (130.9 KiB) Interrupt:5 Base address:0xd400

/etc/network/interfaces

Code: Tout sélectionner: # /etc/network/interfaces # Fichier de configuration dexemple des interfaces réseau # pour faire un serveur NAT # Formation Debian GNU/Linux par Alexis de Lattre # http://www.via.ecp.fr/~alexis/formation-linux/ # Plus dinformations dans "man interfaces" # Linterface "loopback" auto lo iface lo inet loopback # Activation de la fonction de forwarding IP au niveau du noyau up echo "1" > /proc/sys/net/ipv4/ip_forward # Linterface "eth0" connectée à Internet (configuration par DHCP) auto eth0 iface eth0 inet dhcp # Linterface "eth1" connectée au réseau local (IP privée fixe) auto eth1 iface eth1 inet static address 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255

Au depart, je pensais a un probleme de MTU (bien connu avec un modem ADSL partage sur un reseau local ethernet), mais le "TCPMSS clamp to PMTU" devrait me proteger de ca. J'ai quand meme essaye de baisser le MTU du client win XP (jusque 1200!), mais sans aucun effet (les trames sont bien plus petites, mais j'ai toujours les meme problemes).

Merci pour vos idees eclairees

par **Methos_Hi** » 22 Sep 2004 17:44

Avant tout, lorsque ton XP est directement relié à la freebox, est-ce que çà marche bien ?

par **ojacques** » 22 Sep 2004 20:59

Oui, cela fonctionne très bien dans le cas où le XP est relié en direct à la fbx.
C'est ce que j'utilise en attendant que le routeur fonctionne.

par **jdh** » 23 Sep 2004 00:41

Je suis fana de la Debian qui est une excellente distrib.
J'ai aussi été très admiratif du travail d'Alexis de Lattre : pédagogique.

Concernant le firewall, depuis 2-3 ans, j'apprécie beaucoup Shorewall.
C'est un système très simple, bien documenté, qui permet de bien contrôler ce qui se passe.

Je pense que ton pb peut venir des règles iptables Mais tu ne donnes pas exactement le script que
tu as développé (ou copié).

Je t'encourage à essayer Shorewall qui t'assurera un script iptables propre, efficace et facile à monter.

Il est possible que cela vienne de problème dns. Le pb est-il manifeste à plusieurs moments de
la journée (question des timings).
Concernant Free, je constate que les baux DHCP fournis par Free sont bizarres : sur une ligne
non dégroupé, il y a renouvellement toutes les ... 60 secondes. Ce doit pas être top. Car DHClient
active un certain nombre de choses à chaque changement.

par **jdh** » 23 Sep 2004 01:42

En Woody, le mieux est de prendre un paquet Shorewall sur www.backport.org.
Shorewall sera au niveau 2.0.3 ce qui est mieux que le 1.2 de la Woody de base (vraiment trop vieux).
En Sarge, il est à une bonne version sur les mirroirs Debian.
Utilises les commandes iproute qui sont assez sympa : ip add au lieu d'ifconfig, ip route au lieu de route print.

Apres install du paquet, il faut copier le modèle "two-interfaces.tgz" pris sur www.shorewall.net
(à la bonne version !).

Ensuite tu edites les fichiers

interfaces, masq, policy, rules

et bien sur shorewall.conf : parametre IP_FORWARDING=On (et non Keep).

C'est le système de firewall des Mandrake MNF, 9 et 10.
Ce qui est le mieux c'est de voir la qualité du code par "iptables -vn -L".
C'est super instructif et super lisible. Quoique "rules" est encore plus simple !

Dans les scripts que tu décris, je ne vois pas par exemple, le traffic 80 autorisé alors que tu décris
ce type de traffic. Par ailleurs, tu n'indiques pas les temps. La sortie directe du tcpdump serait plus faciles à lire (pour la gestion du temps).

A analyser :

- cela se produit-il quelque soit l'heure ?
- cela se produit-il quelques soit le site ? (comparer site chez free et site au find fond du japon)
- quel config matériel (proc, mémoire, disque, swap, type de carte) ?

NB: Ta carte eth0=Internet semble être une DLink ? Ta carte eth1 est quoi ? (vendor code = mototech ??)

par **ojacques** » 23 Sep 2004 20:35

jdh a écrit:Je pense que ton pb peut venir des règles iptables Mais tu ne donnes pas exactement le script que tu as développé (ou copié).

Il est copié du site d'Alexis. Le voici:

Code: Tout sélectionner: #!/bin/sh iptables -F iptables -P INPUT DROP iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp -j ACCEPT iptables -A INPUT -p igmp -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -j REJECT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o eth0 --clamp-mss-to-pmtu iptables -A FORWARD -j log

jdh a écrit:Je t'encourage à essayer Shorewall qui t'assurera un script iptables propre, efficace et facile à monter.

Je vais essayer ca, mais j'ai essayer "sans" firewall, avec ces regles:

Code: Tout sélectionner: #!/bin/sh iptables -F iptables -t nat -F iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t filter -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A FORWARD -i eth1 -o eth0 -j ACCEPT

Pas mieux

Il est possible que cela vienne de problème dns. Le pb est-il manifeste à plusieurs moments de
la journée (question des timings).

Hmmm... Ca a l'air d'etre tout le temps.

Concernant Free, je constate que les baux DHCP fournis par Free sont bizarres : sur une ligne
non dégroupé, il y a renouvellement toutes les ... 60 secondes. Ce doit pas être top. Car DHClient
active un certain nombre de choses à chaque changement.

Ha ? Pourtant j'ai ca quand je lance dhclient:

Code: Tout sélectionner: bound to XX.XX.XX.XX -- renewal in 302400 seconds.

Dans les scripts que tu décris, je ne vois pas par exemple, le traffic 80 autorisé alors que tu décris ce type de traffic.

Je croyais que d'authoriser tout en sortie permettait de s'en sortir. Non ?

A analyser :

- cela se produit-il quelque soit l'heure ?

Oui

- cela se produit-il quelques soit le site ? (comparer site chez free et site au find fond du japon)

Oui, mais il faut un site "pechu" qui genere des "grosses" trames TCP. Enfin, ça, je n'en suis pas sur.

- quel config matériel (proc, mémoire, disque, swap, type de carte) ?

Athlon XP1800+, 128Mo Ram, 500Mo swap, 3,5Mo utilisé.

NB: Ta carte eth0=Internet semble être une DLink ? Ta carte eth1 est quoi ? (vendor code = mototech ??)

Code: Tout sélectionner: 00:0f.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) Subsystem: Unknown device 182d:0020 Flags: bus master, medium devsel, latency 64, IRQ 5 I/O ports at d400 [size=256] Memory at cfffd800 (32-bit, non-prefetchable) [size=1K] Expansion ROM at cffc0000 [disabled] [size=128K] Capabilities: [c0] Power Management version 2 00:11.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS) Flags: medium devsel, IRQ 12 I/O ports at d000 [size=32]

Code: Tout sélectionner: dmesg | grep eth eth0: RealTek RTL-8029 found at 0xd000, IRQ 12, 00:80:C8:C0:F9:F1. => INTERNET eth1: ADMtek Comet rev 17 at 0xd400, 00:50:BF:99:03:36, IRQ 5. => LOCAL

Merci beaucoup pour ton aide !

par **jdh** » 23 Sep 2004 23:07

Bien beaucoup d'infos !

* Config large : Athlon 1800, 128M, Swap 500M (il est assez normal que le swap soit tres peu utilisé)
* Le code Vendor des adressses MAC (3 premiers octets) donnait DLink ou Linksys.
J'aurai du trouver pour Realtek 8029 : j'en ai !

* Bail Dhcp de 3,5 jours c'est plus sympa que 60 secondes : ca signifie que le temps nécessaire
au changement d'adresses (à mi bail) va pas perturber le système

* C'est un mauvais principe de permettre tout en sortie. On le fait par facilité. Je l'ai fait moi aussi.
Puis un jour on se dit, si je trouve un pgm bizarre, il aura pas de difficulté à aller sur Internet.
Ton script, effectivement , autorise par FORWARD tout en sortie.

Dans le dump que tu donnes, il y a quelques bizarreries :

- les trames 5 et 7 (seq=1), ou 13 et 14 (seq=288) font apparaitre un win=xxxx aberrant
(une fenetre =windows ne peut être supérieures à 64k)
- il y a entrelacement de séquences distinctes avec des valeurs aberrantes
- qu'il y a -t-il sur le PC qui peut générer cela ?

Chez moi, je constate à partir d'un XP family, plusieurs séquences lors d'une navigation.
IE charge d'une part index.html mais aussi les *.jpg, d'où plusieurs séquences = plusieurs ports sources.
une séquence (mon ip.2473 -> www.80) est suivi d'une autre (mon ip.2476 -> www.80).
J'utilise tcpdump et non etherreal. Je ne vois la données seq dans les traces tcpdump (de base).
mais je vois le changement de ports source auquel correspond bien le hand-shake SYN SYN ACK.

Donc ne pouvant reproduire ton pb, je ne peux t'aider plus.

Je t'encourage à passer à Sarge + noyau 2.6.7. Cela semble assez pratique pour avoir des paquets
les plus à jour. J'ai noté des pb de performance (latence) avec bind9. Or bind9 agit en cache dns pour
mon réseau local.

Bon courage ...

par **ojacques** » 23 Sep 2004 23:28

Merci pour toutes tes réponses ! Ca devient vraiment intéressant

Je suis donc passé à Shorewall (2.0.8 ), et ça ne marche pas mieux. Par contre, je suis content d'utiliser shorewall, c'est plus sympa.
En lisant les fichiers de conf de Shorewall, je suis tombé la-dessus:

Code: Tout sélectionner: # # MSS CLAMPING # # Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU" # option. This option is most commonly required when your internet # interface is some variant of PPP (PPTP or PPPoE). Your kernel must # have CONFIG_IP_NF_TARGET_TCPMSS set. # # [From the kernel help: # # This option adds a `TCPMSS' target, which allows you to alter the # MSS value of TCP SYN packets, to control the maximum size for that # connection (usually limiting it to your outgoing interface's MTU # minus 40). # # This is used to overcome criminally braindead ISPs or servers which # block ICMP Fragmentation Needed packets. The symptoms of this # problem are that everything works fine from your Linux # firewall/router, but machines behind it can never exchange large # packets: # 1) Web browsers connect, then hang with no data received. # 2) Small mail works fine, but large emails hang. # 3) ssh works fine, but scp hangs after initial handshaking. # ] # # If left blank, or set to "No" or "no", the option is not enabled. # CLAMPMSS=No

Effectivement, les symptômes décrits correspondent exactement à ça. J'ai activé le MSS clamping, mais sans effet. Re-

Je penche vraiment vers un problème de MTU. Je ne met pas en cause les cartes reseaux, eth0 fonctionnant très bien (du fw->net, aucun soucis de navigation) et eth1 aussi (testé loc->fw avec un gros FTP, pas de soucis non plus).

D'après mes recherches, si le MSS clamping n'est pas utilisable, il faut positionner la MTU sur tous les postes clients. Ce qui est acceptable pour moi. J'ai changé la MTU du poste XP a 1400, mais sans effet.
Après pas mal d'essais, j'ai trouvé une combinaison qui "fonctionne". Enfin, c'est vraiment pas terrible, je suis à 20ko/s en download (contre 650 d'habitude), mais ça semble mieux:

Code: Tout sélectionner: +----------------------------+ Freebox ---| eth0 (1499)----eth1 (1500) +------ Win XP (1500) +----------------------------+

Je n'arrive pas à comprendre ce comportement. Peut-être qu'une bonne nuit de sommeil

D'autant plus que je crois avoir lu que la freebox est en PPPoA, donc la MTU a 1500 devrait etre OK.

Je crois que je vais passer en Sarge... Tu connais un moyen simple de migrer de Woody a Sarge ?

Merci encore.

par **ojacques** » 23 Sep 2004 23:33

Rectification:

Freebox non dégroupée: PPPoA
Freebox dégroupée (mon cas): VCMUX (MPoA)

par **Franck78** » 23 Sep 2004 23:45

Les valeur de fenêtres "aberrantes" ne peuvent pas l'être. 16 bits c'est 16 bits dans un datagram IP...
C'est un bug de etherreal, c'est tout.
D'ailleurs il n'y a qu'a enlever 3x65536 à 256960 pour retomber sur "win=60352"

Bye

par **ojacques** » 24 Sep 2004 07:23

ojacques a écrit:Tu connais un moyen simple de migrer de Woody a Sarge ?

C'est une question bête avec une Debian :oops:

par **ojacques** » 29 Sep 2004 00:12

J'ai finalement "résolu" le pb en passant via l'interface USB de la freebox au lieu de l'ethernet.
Je crois que je vais rester avec cette config : tout marche, et je gagne une carte réseau.

En conclusion:
- Ou ma carte ethernet est mauvaise C'est ce que je soupçonne le plus...
- Ou le cable ethernet routeur/FBX est mauvais
- Ou l'interface ethernet de ma FBX est mauvaise

Et merci à JDH, j'ai beaucoup appris dans ce thread...

par **tomtom** » 29 Sep 2004 10:15

Au risque de me répéter, il y a de nombreux problèmes de negociation entre certaines cartes et la freebox.
Donc, si tu peux par xemple forcer les settings de ta carte (10 full me semble un bon compromis), tu t'epargneras bien des problèmes !

t.

Problemes avec firewall + NAT avec iptables

Problemes avec firewall + NAT avec iptables

Qui est en ligne ?