iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
et moi je ne connais
malheureusement pas la commande a écrire sur iptable pour lui dire tu
ouvre de telle à telle ports j'ai essayé un ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
et moi je ne connais
malheureusement pas la commande a écrire sur iptable pour lui dire tu
ouvre de telle à telle ports j'ai essayé un ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
et moi je ne connais
malheureusement pas la commande a écrire sur iptable pour lui dire tu
ouvre de telle à telle ports j'ai essayé un ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un peu
comme le FTP en mode actif. Parcours les archives récentes de la liste,
le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.
le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un peu
comme le FTP en mode actif. Parcours les archives récentes de la liste,
le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un peu
comme le FTP en mode actif. Parcours les archives récentes de la liste,
le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Il y a moyen d'utiliser module-assistant sinon ?
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Il y a moyen d'utiliser module-assistant sinon ?
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Il y a moyen d'utiliser module-assistant sinon ?
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
RoboTux a écrit :
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Il y a moyen d'utiliser module-assistant sinon ?
Aucune idée, je ne connais pas. Je me contente de patcher les sources
"en dur", de configurer les options et de compiler.
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
Ajouter NEW dans cette règle reviendrait à accepter à peu près n'importe
quoi en entrée, sauf les paquets INVALID. Je ne pense pas que ce soit le
but recherché.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Par contre je ne sais pas comment ça se passe pour afficher avec la
Freebox de la vidéo stockée sur le client.
RoboTux a écrit :
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Il y a moyen d'utiliser module-assistant sinon ?
Aucune idée, je ne connais pas. Je me contente de patcher les sources
"en dur", de configurer les options et de compiler.
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
Ajouter NEW dans cette règle reviendrait à accepter à peu près n'importe
quoi en entrée, sauf les paquets INVALID. Je ne pense pas que ce soit le
but recherché.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Par contre je ne sais pas comment ça se passe pour afficher avec la
Freebox de la vidéo stockée sur le client.
RoboTux a écrit :
Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
C'est bien dommage. Peut-être dans les futurs noyau si d'autres comme
free s'y mette, ça pourrait devenir intéressant de le fournir en
standard.
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Il y a moyen d'utiliser module-assistant sinon ?
Aucune idée, je ne connais pas. Je me contente de patcher les sources
"en dur", de configurer les options et de compiler.
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
Il faut pas rajouter NEW en sortie dans la règle ? C'est bien le
freeplayer qui initie la connexion vers la freeboite ?
Ajouter NEW dans cette règle reviendrait à accepter à peu près n'importe
quoi en entrée, sauf les paquets INVALID. Je ne pense pas que ce soit le
but recherché.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Par contre je ne sais pas comment ça se passe pour afficher avec la
Freebox de la vidéo stockée sur le client.
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Oui je me doute que les freenautes ne représentent qu'une petite partie.
Je pensais plus si cela se généralise (les autres FAI de France et
d'ailleurs). Par contre j'ignorais que le module n'était pas encore
stable. C'est effectivement une raison bien suffisante de ne pas le
mettre en standard dans le noyau.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Oui oui c'est bien en sortie que je parlais. Il faut bien qu'il y ait
NEW d'un côté (le côté qui initie la connection).
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Oui je me doute que les freenautes ne représentent qu'une petite partie.
Je pensais plus si cela se généralise (les autres FAI de France et
d'ailleurs). Par contre j'ignorais que le module n'était pas encore
stable. C'est effectivement une raison bien suffisante de ne pas le
mettre en standard dans le noyau.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Oui oui c'est bien en sortie que je parlais. Il faut bien qu'il y ait
NEW d'un côté (le côté qui initie la connection).
Je doute que l'équipe de développement du noyau se préoccupe des
freenautes. Le patch sera inclus dans le noyau standard quand il sera
jugé stable et digne de l'être, point. Ce fut le cas d'un certain nombre
qui sont désormais intégrés depuis le 2.6.14.
Oui je me doute que les freenautes ne représentent qu'une petite partie.
Je pensais plus si cela se généralise (les autres FAI de France et
d'ailleurs). Par contre j'ignorais que le module n'était pas encore
stable. C'est effectivement une raison bien suffisante de ne pas le
mettre en standard dans le noyau.
D'après ce que je sais, le player établit une connexion TCP sortante de
contrôle vers la Freebox qui envoie le flux vidéo en UDP sur le port
négocié. Le premier paquet de ce flux UDP sera vu dans l'état RELATED
par le module de suivi de connexion RTSP. C'est comme en FTP actif. Le
NEW doit éventuellement être en OUTPUT pour accepter la connexion TCP
sortante (qui utilise un port fixe, je ne sais plus lequel).
Oui oui c'est bien en sortie que je parlais. Il faut bien qu'il y ait
NEW d'un côté (le côté qui initie la connection).
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un
peu comme le FTP en mode actif. Parcours les archives récentes de la
liste, le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.
le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un
peu comme le FTP en mode actif. Parcours les archives récentes de la
liste, le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.
et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
Salut,
DamZ91 a écrit :
J'ai un probleme avec freeplayer et iptables aussi bien pour regarder
un films de mon disque a la fbx que pour regarder les chaines sur mon
pc...
Décidément, c'est le sujet à la mode en ce moment.le probleme est que la freebox passe tous le temps par un ports
differen pour m'envoyé les trames udp
C'est normal, c'est le protocole RTSP qui veut ça. Il fonctionne un
peu comme le FTP en mode actif. Parcours les archives récentes de la
liste, le sujet y a été traité à plusieurs reprises.
La solution "propre" mais qui demande un peu de travail consiste à
charger le module de suivi de connexion de Netfilter pour RTSP,
ip_conntrack_rtsp, et à accepter au moins les paquets UDP dont l'état
est RELATED ou ESTABLISHED. Comme ce module n'est pas inclus dans les
noyaux standards, il faudra probablement appliquer le patch
rtsp-conntrack du patch-o-matic-ng de Netfilter aux sources du noyau,
compiler le noyau et l'installer. Ensuite :
modprobe ip_conntrack_rtsp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Cette règle iptables devrait de toute façon déjà être présente en tête
de tout jeu de règles qui se respecte. La même pour OUTPUT s'il y a
aussi des restrictions en sortie.et moi je ne connais malheureusement pas la commande a écrire sur
iptable pour lui dire tu ouvre de telle à telle ports j'ai essayé un
ceci mais sans succes:
iptables -A INPUT -p tcp --dport 32700>32800 -j ACCEPT
La syntaxe correcte est la suivante :
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Le flux vidéo utilise UDP.
"ConneXion".
Oui, mais dans une règle spécifique limitée au port TCP concerné, pas
dans la règle générique qui gère les connexions établies. C'est un peu
pareil qu'en entrée, ça ne sert pas à grand chose d'avoir une règle qui
autorise tout sauf INVALID en sortie. Autant mettre la politique par
défaut à ACCEPT.
"ConneXion".
Oui, mais dans une règle spécifique limitée au port TCP concerné, pas
dans la règle générique qui gère les connexions établies. C'est un peu
pareil qu'en entrée, ça ne sert pas à grand chose d'avoir une règle qui
autorise tout sauf INVALID en sortie. Autant mettre la politique par
défaut à ACCEPT.
"ConneXion".
Oui, mais dans une règle spécifique limitée au port TCP concerné, pas
dans la règle générique qui gère les connexions établies. C'est un peu
pareil qu'en entrée, ça ne sert pas à grand chose d'avoir une règle qui
autorise tout sauf INVALID en sortie. Autant mettre la politique par
défaut à ACCEPT.
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
Raphaël
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
Raphaël
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
Raphaël
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
iptables -A INPUT -p udp --dport 32700:32800 -j ACCEPT
Ou alors façon un peu plus paranoïaque sans passer par la recompil du
noyeau, rajouter : -d "addresse IP de mafreebox.freebox.fr"?
