Bonjour, je me pose la question suivante : imaginons le cas classique d'un
petit LAN derrière un firewall, lui même derrière un routeur.
Bien sur, les postes du LAN ont des adresses privées, seul le firewall a
une IP publique.
Quant au firewall, il a deux interfaces, une vers le réseau privée (eth1),
une vers le routeur (eth0).
Donc :
- tout les utilisateurs doivent pouvoir sortir (http, pop3, smtp, real
video, streaming en tout genre, etc etc etc)
- rien de l'extérieur de doit rentrer.
Ce que je ne comprends pas, c'est que si je ferme tous les ports sur eth0
plus rien de va fonctionner. Quand un utilisateur se connecte sur
www.yahoo.fr, une connexion est établie entre le serveur http et un port
variable sur la machine cliente. Si le firewall bloque tous les ports, ça
va donc coincer.
Alors ou est l'astuce ? On bloque les ports < 1024 et tout ce qui est au
dessus reste autorisé ? Parce que indépendemment de la NAT, il faut bien
que des ports soient authorisés pour les connexions local -> internet.
Bah bah bah... Suis largué, j'ai cherché des liens sur le sujet mais bon.
Si vous avez un début de brin d'explication
Merci
dans le cas du surf c'est toi qui initie la transaction rso et non le
Bonjour, je me pose la question suivante : imaginons le cas classique d'un
petit LAN derrière un firewall, lui même derrière un routeur.
Bien sur, les postes du LAN ont des adresses privées, seul le firewall a
une IP publique.
Quant au firewall, il a deux interfaces, une vers le réseau privée (eth1),
une vers le routeur (eth0).
Donc :
- tout les utilisateurs doivent pouvoir sortir (http, pop3, smtp, real
video, streaming en tout genre, etc etc etc)
- rien de l'extérieur de doit rentrer.
Ce que je ne comprends pas, c'est que si je ferme tous les ports sur eth0
plus rien de va fonctionner. Quand un utilisateur se connecte sur
www.yahoo.fr, une connexion est établie entre le serveur http et un port
variable sur la machine cliente. Si le firewall bloque tous les ports, ça
va donc coincer.
Alors ou est l'astuce ? On bloque les ports < 1024 et tout ce qui est au
dessus reste autorisé ? Parce que indépendemment de la NAT, il faut bien
que des ports soient authorisés pour les connexions local -> internet.
Bah bah bah... Suis largué, j'ai cherché des liens sur le sujet mais bon.
Si vous avez un début de brin d'explication
Merci
dans le cas du surf c'est toi qui initie la transaction rso et non le
Bonjour, je me pose la question suivante : imaginons le cas classique d'un
petit LAN derrière un firewall, lui même derrière un routeur.
Bien sur, les postes du LAN ont des adresses privées, seul le firewall a
une IP publique.
Quant au firewall, il a deux interfaces, une vers le réseau privée (eth1),
une vers le routeur (eth0).
Donc :
- tout les utilisateurs doivent pouvoir sortir (http, pop3, smtp, real
video, streaming en tout genre, etc etc etc)
- rien de l'extérieur de doit rentrer.
Ce que je ne comprends pas, c'est que si je ferme tous les ports sur eth0
plus rien de va fonctionner. Quand un utilisateur se connecte sur
www.yahoo.fr, une connexion est établie entre le serveur http et un port
variable sur la machine cliente. Si le firewall bloque tous les ports, ça
va donc coincer.
Alors ou est l'astuce ? On bloque les ports < 1024 et tout ce qui est au
dessus reste autorisé ? Parce que indépendemment de la NAT, il faut bien
que des ports soient authorisés pour les connexions local -> internet.
Bah bah bah... Suis largué, j'ai cherché des liens sur le sujet mais bon.
Si vous avez un début de brin d'explication
Merci
dans le cas du surf c'est toi qui initie la transaction rso et non le
dans le cas du surf c'est toi qui initie la transaction rso et non le
wwww qui vient vers toi
On ne laisse pas de ports ouverts, il faut avoir en tête que tout ce
qui n'est pas autorisé est formellement interdit !
sur http://www.commentcamarche.net/ recherche firewall
sans oublier google !!
dans le cas du surf c'est toi qui initie la transaction rso et non le
wwww qui vient vers toi
On ne laisse pas de ports ouverts, il faut avoir en tête que tout ce
qui n'est pas autorisé est formellement interdit !
sur http://www.commentcamarche.net/ recherche firewall
sans oublier google !!
dans le cas du surf c'est toi qui initie la transaction rso et non le
wwww qui vient vers toi
On ne laisse pas de ports ouverts, il faut avoir en tête que tout ce
qui n'est pas autorisé est formellement interdit !
sur http://www.commentcamarche.net/ recherche firewall
sans oublier google !!
JP - :
Ce que je comprends c'est qu'une connection est établie entre le port 3939
de ma passerelle et le serveur web. Si ce port 3939 est fermé que va-t-il
se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion entrante
mais sortante ??
Dois-je relire mon MacMillan ? :-)
JP - JP@nospam.com :
Ce que je comprends c'est qu'une connection est établie entre le port 3939
de ma passerelle et le serveur web. Si ce port 3939 est fermé que va-t-il
se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion entrante
mais sortante ??
Dois-je relire mon MacMillan ? :-)
JP - :
Ce que je comprends c'est qu'une connection est établie entre le port 3939
de ma passerelle et le serveur web. Si ce port 3939 est fermé que va-t-il
se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion entrante
mais sortante ??
Dois-je relire mon MacMillan ? :-)
On 23 Jan 2004 14:05:51 GMT, Zouplaz wrote:JP - :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
On 23 Jan 2004 14:05:51 GMT, Zouplaz <pouet@pouet.com> wrote:
JP - JP@nospam.com :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
On 23 Jan 2004 14:05:51 GMT, Zouplaz wrote:JP - :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
Harry Cover - :On 23 Jan 2004 14:05:51 GMT, Zouplaz wrote:JP - :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Aie aie aie ma teuté. Bon allez, je laisse ça jusqu'à lundi. Une bonne
bière me fera du bien :-)
Harry Cover - mike@nomade.Fr :
On 23 Jan 2004 14:05:51 GMT, Zouplaz <pouet@pouet.com> wrote:
JP - JP@nospam.com :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Aie aie aie ma teuté. Bon allez, je laisse ça jusqu'à lundi. Une bonne
bière me fera du bien :-)
Harry Cover - :On 23 Jan 2004 14:05:51 GMT, Zouplaz wrote:JP - :
Ce que je comprends c'est qu'une connection est établie entre le port
3939 de ma passerelle et le serveur web. Si ce port 3939 est fermé que
va-t-il se passer ?
Ca va fonctionner quand même ? Parce que c'est pas une connexion
entrante mais sortante ??
Le port n'est pas fermé, vu que la passerelle l'utilise pour parler au
serveur web. Donc il est ouvert. CQFD. Ce n'est pas dangereux, car la
passerelle n'acceptera que des datagrammes provenant de google.
Pour comprendre tout ca, le mieux c'est d'aller lire la doc (comme
d'habituuuuudêuuuuu....), en l'occurence celle d'iptables.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Sinon, essayes d'être plus "verbose". tu travailles avec quelle
distrib ? quel noyo ?
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Aie aie aie ma teuté. Bon allez, je laisse ça jusqu'à lundi. Une bonne
bière me fera du bien :-)
Et bien bon courage car si tu envisages d'installer des règles
iptables sans les maîtriser... je pense que tu auras quelques
surprises. Il n'y a pas d'outil magique, sauf google et encore
Et bien bon courage car si tu envisages d'installer des règles
iptables sans les maîtriser... je pense que tu auras quelques
surprises. Il n'y a pas d'outil magique, sauf google et encore
Et bien bon courage car si tu envisages d'installer des règles
iptables sans les maîtriser... je pense que tu auras quelques
surprises. Il n'y a pas d'outil magique, sauf google et encore
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur une
bécane publique je m'en sers pour tester ma conf du firewall de l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT et
le firewall je comprends plus. A moins que je me prenne le choux pour rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
Zouplaz wrote:
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre
les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec
un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur
une
bécane publique je m'en sers pour tester ma conf du firewall de
l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT
et
le firewall je comprends plus. A moins que je me prenne le choux pour
rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont
pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP
privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment
elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
La NAT gère biensur une table lorsque le paquet de connexion est
sorti (Client--->Serveur). Donc, lors d'un paquet entrant
(Serveur--->Client) sur le port local du Firewall, il sait remaper
l'adresse lan du client et le bon port. A priori, ce port est biensur
fermé par le Firewall... Il faut donc mettre une regle pour laisser
entrer systématiquement les paquets "ESTABLISHED". (connexion établie)
Fwbuilder vous a certainement généré une règle iptables du
genre:
ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED
Jm
Zouplaz wrote:
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre
les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec
un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur
une
bécane publique je m'en sers pour tester ma conf du firewall de
l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT
et
le firewall je comprends plus. A moins que je me prenne le choux pour
rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont
pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP
privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment
elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
La NAT gère biensur une table lorsque le paquet de connexion est
sorti (Client--->Serveur). Donc, lors d'un paquet entrant
(Serveur--->Client) sur le port local du Firewall, il sait remaper
l'adresse lan du client et le bon port. A priori, ce port est biensur
fermé par le Firewall... Il faut donc mettre une regle pour laisser
entrer systématiquement les paquets "ESTABLISHED". (connexion établie)
Fwbuilder vous a certainement généré une règle iptables du
genre:
ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED
Jm
Zouplaz wrote:
Bin en fait, je tente de me passer d'iptables (du moins de pas mettre
les
mains dedans). Je me sers de firewall builder, sur une RedHat 7.3 avec
un
kernel 2.4.22.
Disons que je pige le principe, d'ailleurs comme j'ai un shell ssh sur
une
bécane publique je m'en sers pour tester ma conf du firewall de
l'extérieur
avec nmap. Et c'est vrai que le dernier essai a donné :
20/tcp closed ftp-data
21/tcp open ftp
53/tcp open domain
80/tcp open http
Ce qui correspond bien à ma conf dans fwbuilder.
Ce qui est pas encore clair c'est la différence entre un port serveur en
écoute (80 dans l'exemple ci-dessus) et un port utilisé par une bécane
cliente (genre port 7653) en réponse à une connexion sur un serveur.
Je veux dire : sans NAT ni firewall au milieu je comprends, avec la NAT
et
le firewall je comprends plus. A moins que je me prenne le choux pour
rien,
la NAT consiste à trafiquer les paquets IP pas TCP, donc les ports sont
pas
pris en compte. Du coup l'expéditeur (la bécane cliente avec son IP
privée)
retrouve un paquet qui a été simplement re-écrit). (Oui mais comment
elle
fait la NAT pour savoir qui appartient à qui ? hm ?)
La NAT gère biensur une table lorsque le paquet de connexion est
sorti (Client--->Serveur). Donc, lors d'un paquet entrant
(Serveur--->Client) sur le port local du Firewall, il sait remaper
l'adresse lan du client et le bon port. A priori, ce port est biensur
fermé par le Firewall... Il faut donc mettre une regle pour laisser
entrer systématiquement les paquets "ESTABLISHED". (connexion établie)
Fwbuilder vous a certainement généré une règle iptables du
genre:
ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED
Jm
