iptables et translation d'adresses/ports par routeur adsl

Annie D.

14/02/2004 à 11:27

Gillot wrote:

Je craque ...

On n'a pas su vous dépanner dans fcolc ?

@$IPEXT
|
|
$IPFIXE
(ROUTEUR ADSL)
$IPROUTEUR
|
|
$IPFWEXT
eth1
(MACHINE LINUX)
(FIREWALL FILTRANT)
(IPTABLES)
eth0
$IPFWINT
|
|
(SWITCH)
|
|
$IPLOC
(LAN LOCAL)

Le script des règles IPTABLES est le même, ormis l'interface ppp0 qui
devient eth1 et $IPDYN qui deviens $IPFIXE.

AMA, l'erreur est là : il faut remplacer $IPDYN, qui était l'adresse de
ppp0, par $IPFWEXT qui est l'adresse de eth1. Le routeur ADSL fait aussi
de la NAT, donc tout ce qu'il redirige vers le firewall contient
l'adresse destination de celui-ci, soit $IPFWEXT et pas $IPFIXE. Par
conséquent, si la règle DNAT dans PREROUTING contient -d $IPFIXE, elle
ne "matchera" jamais et les paquets arriveront sur le process local du
firewall lui-même au lieu d'être NATés et redirigés vers $IPLOC.

Gillot

16/02/2004 à 00:07

Gillot wrote:

Je craque ...

On n'a pas su vous dépanner dans fcolc ?

Non, rien à faire ... il y a quelque chose qui cloche, mais je ne sais pas
quoi...

@$IPEXT
|
|
$IPFIXE
(ROUTEUR ADSL)
$IPROUTEUR
|
|
$IPFWEXT
eth1
(MACHINE LINUX)
(FIREWALL FILTRANT)
(IPTABLES)
eth0
$IPFWINT
|
|
(SWITCH)
|
|
$IPLOC
(LAN LOCAL)

Le script des règles IPTABLES est le même, ormis l'interface ppp0 qui
devient eth1 et $IPDYN qui deviens $IPFIXE.

AMA, l'erreur est là : il faut remplacer $IPDYN, qui était l'adresse de
ppp0, par $IPFWEXT qui est l'adresse de eth1. Le routeur ADSL fait aussi
de la NAT, donc tout ce qu'il redirige vers le firewall contient
l'adresse destination de celui-ci, soit $IPFWEXT et pas $IPFIXE. Par
conséquent, si la règle DNAT dans PREROUTING contient -d $IPFIXE, elle
ne "matchera" jamais et les paquets arriveront sur le process local du
firewall lui-même au lieu d'être NATés et redirigés vers $IPLOC.

Malheureusement, j'ai déjà essayé cette possibilité, sans succés.
En fait, j'essaye de joindre un as400, et lorsque je fais un telnet sur le
réseau local, je veux simplement que ce qui arrive sur le port telnet (23)
soit redirigé vers l'IP de l'as400 ($IPLOC), et ben depuis que j'ai ce
routeur, y a pas moyen.
Lorsque je telnet $IPFIXE, je tombe sur le telnet sur serveur linux qui
fait firewall... alors que ça devrait être routé sur $IPLOC (comme ça
faisait avant, quand l'accés était sur le modem...)

Si quelqu'un a une idée, je suis preneur ...

Je pensais pas avoir autant de difficultés à gérer ce cas, au début ...

Merci d'avance pour ceux qui m'aideront

A+ GIllot ;o)

T0t0

16/02/2004 à 11:20

"Gillot" wrote in message
news:

Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

exemple : si j'appelle du poste distant (1.2.3.4) sur mon ipfixe
(ex: 5.6.7.8) :
# telnet 5.6.7.8:2323

Je tombe bien sur mon serveur linux qui ecoute en telnet sur le port 23 et
qui est juste derrière le routeur pour jouer le rôle de firewall filtrant.
Un tcpdump lancé sur ce dernier me rapporte bien qu'il recoit mon ip
1.2.3.4 comme ip distante.

Pourquoi la même config qu'avant ne fonctionne pas ? Pour l'instant, je
cherche à faire marcher le truc, j'optimiserai aprés, mais la, j'ai besoin
que ça fonctionne.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC
Suite à ca, les infos sont routées et devraient normalement aller
dans le hook FORWARD, puis POSTROUTING.

Donc telle quelle, la règle me semble bonne.
Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

Il est possible que le paquet soit matché par une autre règle avant
et donc que celle-ci soit inefficace, mais je n'y crois pas trop...

Bon courage !

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"Gillot" <pascalgilles@free.fr> wrote in message
news:pan.2004.02.14.01.17.34.992806@free.fr

Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

exemple : si j'appelle du poste distant (1.2.3.4) sur mon ipfixe
(ex: 5.6.7.8) :
# telnet 5.6.7.8:2323

Je tombe bien sur mon serveur linux qui ecoute en telnet sur le port 23 et
qui est juste derrière le routeur pour jouer le rôle de firewall filtrant.
Un tcpdump lancé sur ce dernier me rapporte bien qu'il recoit mon ip
1.2.3.4 comme ip distante.

Pourquoi la même config qu'avant ne fonctionne pas ? Pour l'instant, je
cherche à faire marcher le truc, j'optimiserai aprés, mais la, j'ai besoin
que ça fonctionne.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC
Suite à ca, les infos sont routées et devraient normalement aller
dans le hook FORWARD, puis POSTROUTING.

Donc telle quelle, la règle me semble bonne.
Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

Il est possible que le paquet soit matché par une autre règle avant
et donc que celle-ci soit inefficace, mais je n'y crois pas trop...

Bon courage !

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Vous avez filtré cet utilisateur ! Consultez son message

"Gillot" wrote in message
news:

Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

exemple : si j'appelle du poste distant (1.2.3.4) sur mon ipfixe
(ex: 5.6.7.8) :
# telnet 5.6.7.8:2323

Je tombe bien sur mon serveur linux qui ecoute en telnet sur le port 23 et
qui est juste derrière le routeur pour jouer le rôle de firewall filtrant.
Un tcpdump lancé sur ce dernier me rapporte bien qu'il recoit mon ip
1.2.3.4 comme ip distante.

Pourquoi la même config qu'avant ne fonctionne pas ? Pour l'instant, je
cherche à faire marcher le truc, j'optimiserai aprés, mais la, j'ai besoin
que ça fonctionne.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC
Suite à ca, les infos sont routées et devraient normalement aller
dans le hook FORWARD, puis POSTROUTING.

Donc telle quelle, la règle me semble bonne.
Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

Il est possible que le paquet soit matché par une autre règle avant
et donc que celle-ci soit inefficace, mais je n'y crois pas trop...

Bon courage !

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

PASCAL Gilles

23/02/2004 à 17:08

"Gillot" wrote in message
news:
Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

Il nate que le port, puisque je reçoit la même addresse au niveau du poste
linux (visible avec tcpdump ou iptraf), mais en port 23 au lieu de 2323.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

D'accord avec ça.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

Oui, je l'ai dégagé.

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

La, c'est un peu poussé pour mon petit cerveau, mais bon, je suis d'accord
dans le raisonnement.

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC

Oui, je peux le constaté avec iptraf, qui m'affiche ceci (exemple) :

$IPEXT:1078 = 4 packets 192 Bytes S--- eth1
$IPFWEXT:23 = 0 packets 0 Bytes ---- eth1
$IPEXT:1078 = 4 packets 192 Bytes S--- eth0
$IPLOC:23 = 0 packets 0 Bytes ---- eth0

Donc telle quelle, la règle me semble bonne.

A moi aussi

Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

ça, je sais pas faire.

J'ai utilisé un script réduit pour tester, le voici :

-----------------------------------------------------
#!/bin/bash

/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F -t nat

# Je remet les rêgles par défaut
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

# Polices par défault
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT

# Insertion des modules de gestion réseau, tunneling etc...
/sbin/modprobe ip_tables
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe ip_gre
/sbin/modprobe ip_conntrack

echo On redirige le port 23 sur l AS400.
# =======================================
/sbin/iptables -A FORWARD -s 80.15.185.10 -d 192.168.1.254 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j DNAT --to-destination 192.168.1.254:23

echo ====================================
/sbin/iptables -A FORWARD -j ACCEPT
/sbin/iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE

-----------------------------------------------------------------

Avec ce script, le telnet $IPFIXE 2323 ne réponds pas (on dirait que ça
passe, mais que ça ne réponds pas ...)

Merci pour votre aide.

A+ Gillot ;o)

"Gillot" <pascalgilles@free.fr> wrote in message
news:pan.2004.02.14.01.17.34.992806@free.fr

Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

Il nate que le port, puisque je reçoit la même addresse au niveau du poste
linux (visible avec tcpdump ou iptraf), mais en port 23 au lieu de 2323.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

D'accord avec ça.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

Oui, je l'ai dégagé.

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

La, c'est un peu poussé pour mon petit cerveau, mais bon, je suis d'accord
dans le raisonnement.

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC

Oui, je peux le constaté avec iptraf, qui m'affiche ceci (exemple) :

$IPEXT:1078 = 4 packets 192 Bytes S--- eth1
$IPFWEXT:23 = 0 packets 0 Bytes ---- eth1
$IPEXT:1078 = 4 packets 192 Bytes S--- eth0
$IPLOC:23 = 0 packets 0 Bytes ---- eth0

Donc telle quelle, la règle me semble bonne.

A moi aussi

Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

ça, je sais pas faire.

J'ai utilisé un script réduit pour tester, le voici :

-----------------------------------------------------
#!/bin/bash

/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F -t nat

# Je remet les rêgles par défaut
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

# Polices par défault
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT

# Insertion des modules de gestion réseau, tunneling etc...
/sbin/modprobe ip_tables
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe ip_gre
/sbin/modprobe ip_conntrack

echo On redirige le port 23 sur l AS400.
# =======================================
/sbin/iptables -A FORWARD -s 80.15.185.10 -d 192.168.1.254 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j DNAT --to-destination 192.168.1.254:23

echo ====================================
/sbin/iptables -A FORWARD -j ACCEPT
/sbin/iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE

-----------------------------------------------------------------

Avec ce script, le telnet $IPFIXE 2323 ne réponds pas (on dirait que ça
passe, mais que ça ne réponds pas ...)

Merci pour votre aide.

A+ Gillot ;o)

Vous avez filtré cet utilisateur ! Consultez son message

"Gillot" wrote in message
news:
Le routeur accepte les entrées en port 2323, et les "nate" en port 23 sur
son entrée sur le réseau local. (vérifié avec tcpdump)

Il nate que le port ou il nate aussi l'adresse destination qui devient
alors celle de l'interface externe du fw (ipfwext) ?

Il nate que le port, puisque je reçoit la même addresse au niveau du poste
linux (visible avec tcpdump ou iptraf), mais en port 23 au lieu de 2323.

Ben, je dirais comme Annie. Il faut déjà que l'adresse IP qui était
$IPDYN soit $IPFWEXT. Je ne vois pas comment cela pourrait marcher
autrement.

D'accord avec ça.

Après, en regardant la règle de plus près:
/sbin/iptables -t nat -A PREROUTING -p tcp -d $IPFWEXT --dport 23
-i ppp0 -j DNAT --to-destination $IPLOC:23

Le -i ppp0 doit dégager ;-) ou être transformé en -i eth1

Oui, je l'ai dégagé.

En faisant un telnet de l'extérieur sur le port 2323, la requête
devrait arriver sur le FW avec comme adresse destination l'adresse
du firewall. Ce qui se passe après:

--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter

La, c'est un peu poussé pour mon petit cerveau, mais bon, je suis d'accord
dans le raisonnement.

On voit que le hook PREROUTING est le premier traversé.
Donc normalement, le paquet correspondant normalement à la règle, il
devrait être traité, et donc naté avec l'adresse de destination
$IPLOC

Oui, je peux le constaté avec iptraf, qui m'affiche ceci (exemple) :

$IPEXT:1078 = 4 packets 192 Bytes S--- eth1
$IPFWEXT:23 = 0 packets 0 Bytes ---- eth1
$IPEXT:1078 = 4 packets 192 Bytes S--- eth0
$IPLOC:23 = 0 packets 0 Bytes ---- eth0

Donc telle quelle, la règle me semble bonne.

A moi aussi

Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.

ça, je sais pas faire.

J'ai utilisé un script réduit pour tester, le voici :

-----------------------------------------------------
#!/bin/bash

/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT
/sbin/iptables -F FORWARD
/sbin/iptables -F -t nat

# Je remet les rêgles par défaut
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

# Polices par défault
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT

# Insertion des modules de gestion réseau, tunneling etc...
/sbin/modprobe ip_tables
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe ip_gre
/sbin/modprobe ip_conntrack

echo On redirige le port 23 sur l AS400.
# =======================================
/sbin/iptables -A FORWARD -s 80.15.185.10 -d 192.168.1.254 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j DNAT --to-destination 192.168.1.254:23

echo ====================================
/sbin/iptables -A FORWARD -j ACCEPT
/sbin/iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE

-----------------------------------------------------------------

Avec ce script, le telnet $IPFIXE 2323 ne réponds pas (on dirait que ça
passe, mais que ça ne réponds pas ...)

Merci pour votre aide.

A+ Gillot ;o)

T0t0

23/02/2004 à 18:25

"PASCAL Gilles" wrote in message
news:

Pour débugger, fais une règle de log avec le même pattern et regarde
si cela apparaît dans tes logs.
ça, je sais pas faire.

Il suffit simplement de demander au firewall de loguer les paquets
quand il sont destinés à la règle sur laquelle on se pose des
questions.

Ca donnerait un truc comme ca:
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"

Ainsi, les paquets devant être natés seront dans les logs
(/var/log/messages)
un "cat /var/log/messages | grep paquets" devrait permettre de voir
facilement si on trouve des traces dans les logs.
Si c'est pas le cas, ca veut dire que les paquets qui arrivent au
firewall ne sont pas au format attendu. Et dans ce cas, il faudra
sniffer sur l'interface dur firewall pour voir ce qui passe.
Tu peux installer tcpdump pour voir.

echo On redirige le port 23 sur l AS400.
# ======================================= >
/sbin/iptables -A FORWARD -s 80.15.185.10 -d 192.168.1.254 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j DNAT --to-destination 192.168.1.254:23

le :23 n'est pas utile car il n'y a pas de modification de port.

C'est bien bizarre, je pense que les paquets sortant du FW/routeur ne
sont pas formatés comme attendu...

Bon courage et n'hésite pas si tu as du nouveau.

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

PASCAL Gilles

24/02/2004 à 10:08

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"

dans "paquets censés être natés", il faut mettre des adresse IP, c'est
bien ça ?

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Si c'est pas le cas, ca veut dire que les paquets qui arrivent au
firewall ne sont pas au format attendu. Et dans ce cas, il faudra
sniffer sur l'interface dur firewall pour voir ce qui passe.
Tu peux installer tcpdump pour voir.

C'est bien bizarre, je pense que les paquets sortant du FW/routeur ne
sont pas formatés comme attendu...

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Bon courage et n'hésite pas si tu as du nouveau.

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Un telnet en local depuis un autre poste, en écoutant avec un
"tcpdump -i eth0 port 23" sur ce même poste, voila le résultat d'une
connexion qui a abouti :

09:57:57.299203 gilles.54357 > 192.168.1.254.telnet: S 111808896:111808896(0) win 5840 <mss 1460> (DF) [tos 0x10]
09:57:57.300212 192.168.1.254.telnet > gilles.54357: S 57863424:57863424(0) ack 111808897 win 8192 <mss 1452> (DF)
09:57:57.300263 gilles.54357 > 192.168.1.254.telnet: . ack 1 win 5840 (DF) [tos 0x10]
09:57:57.306834 gilles.54357 > 192.168.1.254.telnet: P 1:28(27) ack 1 win 5840 (DF) [tos 0x10]
09:57:57.389533 192.168.1.254.telnet > gilles.54357: P 1:7(6) ack 28 win 8192 (DF)
09:57:57.389585 gilles.54357 > 192.168.1.254.telnet: . ack 7 win 5840 (DF) [tos 0x10]
09:57:57.391177 192.168.1.254.telnet > gilles.54357: P 7:62(55) ack 28 win 8192 (DF)
09:57:57.391188 gilles.54357 > 192.168.1.254.telnet: . ack 62 win 5840 (DF) [tos 0x10]
09:57:57.391601 gilles.54357 > 192.168.1.254.telnet: P 28:150(122) ack 62 win 5840 (DF) [tos 0x10]
09:57:57.392824 192.168.1.254.telnet > gilles.54357: P 62:68(6) ack 150 win 8192 (DF)
09:57:57.392881 gilles.54357 > 192.168.1.254.telnet: P 150:161(11) ack 68 win 5840 (DF) [tos 0x10]
09:57:57.393689 192.168.1.254.telnet > gilles.54357: P 68:71(3) ack 161 win 8192 (DF)
09:57:57.393731 gilles.54357 > 192.168.1.254.telnet: P 161:164(3) ack 71 win 5840 (DF) [tos 0x10]
09:57:57.599798 192.168.1.254.telnet > gilles.54357: P ack 164 win 8192 (DF)
09:58:01.033280 192.168.1.254.telnet > gilles.54357: P 71:1493(1422) ack 164 win 8192 (DF)
09:58:01.064621 gilles.54357 > 192.168.1.254.telnet: . ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.527548 gilles.54357 > 192.168.1.254.telnet: F 164:164(0) ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.528398 192.168.1.254.telnet > gilles.54357: P ack 165 win 8192 (DF)
09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)

On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.

Qu'en pensez-vous ?

Je continue à plancher sur le problème...

Merci encore à ceux qui essayent de m'aider.

A+ gillot ;o)

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"

dans "paquets censés être natés", il faut mettre des adresse IP, c'est
bien ça ?

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Si c'est pas le cas, ca veut dire que les paquets qui arrivent au
firewall ne sont pas au format attendu. Et dans ce cas, il faudra
sniffer sur l'interface dur firewall pour voir ce qui passe.
Tu peux installer tcpdump pour voir.

C'est bien bizarre, je pense que les paquets sortant du FW/routeur ne
sont pas formatés comme attendu...

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Bon courage et n'hésite pas si tu as du nouveau.

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Un telnet en local depuis un autre poste, en écoutant avec un
"tcpdump -i eth0 port 23" sur ce même poste, voila le résultat d'une
connexion qui a abouti :

09:57:57.299203 gilles.54357 > 192.168.1.254.telnet: S 111808896:111808896(0) win 5840 <mss 1460> (DF) [tos 0x10]
09:57:57.300212 192.168.1.254.telnet > gilles.54357: S 57863424:57863424(0) ack 111808897 win 8192 <mss 1452> (DF)
09:57:57.300263 gilles.54357 > 192.168.1.254.telnet: . ack 1 win 5840 (DF) [tos 0x10]
09:57:57.306834 gilles.54357 > 192.168.1.254.telnet: P 1:28(27) ack 1 win 5840 (DF) [tos 0x10]
09:57:57.389533 192.168.1.254.telnet > gilles.54357: P 1:7(6) ack 28 win 8192 (DF)
09:57:57.389585 gilles.54357 > 192.168.1.254.telnet: . ack 7 win 5840 (DF) [tos 0x10]
09:57:57.391177 192.168.1.254.telnet > gilles.54357: P 7:62(55) ack 28 win 8192 (DF)
09:57:57.391188 gilles.54357 > 192.168.1.254.telnet: . ack 62 win 5840 (DF) [tos 0x10]
09:57:57.391601 gilles.54357 > 192.168.1.254.telnet: P 28:150(122) ack 62 win 5840 (DF) [tos 0x10]
09:57:57.392824 192.168.1.254.telnet > gilles.54357: P 62:68(6) ack 150 win 8192 (DF)
09:57:57.392881 gilles.54357 > 192.168.1.254.telnet: P 150:161(11) ack 68 win 5840 (DF) [tos 0x10]
09:57:57.393689 192.168.1.254.telnet > gilles.54357: P 68:71(3) ack 161 win 8192 (DF)
09:57:57.393731 gilles.54357 > 192.168.1.254.telnet: P 161:164(3) ack 71 win 5840 (DF) [tos 0x10]
09:57:57.599798 192.168.1.254.telnet > gilles.54357: P ack 164 win 8192 (DF)
09:58:01.033280 192.168.1.254.telnet > gilles.54357: P 71:1493(1422) ack 164 win 8192 (DF)
09:58:01.064621 gilles.54357 > 192.168.1.254.telnet: . ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.527548 gilles.54357 > 192.168.1.254.telnet: F 164:164(0) ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.528398 192.168.1.254.telnet > gilles.54357: P ack 165 win 8192 (DF)
09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)

On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.

Qu'en pensez-vous ?

Je continue à plancher sur le problème...

Merci encore à ceux qui essayent de m'aider.

A+ gillot ;o)

Vous avez filtré cet utilisateur ! Consultez son message

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"

dans "paquets censés être natés", il faut mettre des adresse IP, c'est
bien ça ?

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Si c'est pas le cas, ca veut dire que les paquets qui arrivent au
firewall ne sont pas au format attendu. Et dans ce cas, il faudra
sniffer sur l'interface dur firewall pour voir ce qui passe.
Tu peux installer tcpdump pour voir.

C'est bien bizarre, je pense que les paquets sortant du FW/routeur ne
sont pas formatés comme attendu...

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Bon courage et n'hésite pas si tu as du nouveau.

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Un telnet en local depuis un autre poste, en écoutant avec un
"tcpdump -i eth0 port 23" sur ce même poste, voila le résultat d'une
connexion qui a abouti :

09:57:57.299203 gilles.54357 > 192.168.1.254.telnet: S 111808896:111808896(0) win 5840 <mss 1460> (DF) [tos 0x10]
09:57:57.300212 192.168.1.254.telnet > gilles.54357: S 57863424:57863424(0) ack 111808897 win 8192 <mss 1452> (DF)
09:57:57.300263 gilles.54357 > 192.168.1.254.telnet: . ack 1 win 5840 (DF) [tos 0x10]
09:57:57.306834 gilles.54357 > 192.168.1.254.telnet: P 1:28(27) ack 1 win 5840 (DF) [tos 0x10]
09:57:57.389533 192.168.1.254.telnet > gilles.54357: P 1:7(6) ack 28 win 8192 (DF)
09:57:57.389585 gilles.54357 > 192.168.1.254.telnet: . ack 7 win 5840 (DF) [tos 0x10]
09:57:57.391177 192.168.1.254.telnet > gilles.54357: P 7:62(55) ack 28 win 8192 (DF)
09:57:57.391188 gilles.54357 > 192.168.1.254.telnet: . ack 62 win 5840 (DF) [tos 0x10]
09:57:57.391601 gilles.54357 > 192.168.1.254.telnet: P 28:150(122) ack 62 win 5840 (DF) [tos 0x10]
09:57:57.392824 192.168.1.254.telnet > gilles.54357: P 62:68(6) ack 150 win 8192 (DF)
09:57:57.392881 gilles.54357 > 192.168.1.254.telnet: P 150:161(11) ack 68 win 5840 (DF) [tos 0x10]
09:57:57.393689 192.168.1.254.telnet > gilles.54357: P 68:71(3) ack 161 win 8192 (DF)
09:57:57.393731 gilles.54357 > 192.168.1.254.telnet: P 161:164(3) ack 71 win 5840 (DF) [tos 0x10]
09:57:57.599798 192.168.1.254.telnet > gilles.54357: P ack 164 win 8192 (DF)
09:58:01.033280 192.168.1.254.telnet > gilles.54357: P 71:1493(1422) ack 164 win 8192 (DF)
09:58:01.064621 gilles.54357 > 192.168.1.254.telnet: . ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.527548 gilles.54357 > 192.168.1.254.telnet: F 164:164(0) ack 1493 win 8532 (DF) [tos 0x10]
09:58:02.528398 192.168.1.254.telnet > gilles.54357: P ack 165 win 8192 (DF)
09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)

On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.

Qu'en pensez-vous ?

Je continue à plancher sur le problème...

Merci encore à ceux qui essayent de m'aider.

A+ gillot ;o)

T0t0

24/02/2004 à 10:32

"PASCAL Gilles" wrote in message
news:

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"PASCAL Gilles" <coop.ardechoise@wanadoo.fr> wrote in message
news:pan.2004.02.24.09.08.01.201757@wanadoo.fr

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Vous avez filtré cet utilisateur ! Consultez son message

"PASCAL Gilles" wrote in message
news:

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

PASCAL Gilles

24/02/2004 à 10:34

"PASCAL Gilles" wrote in message
news:
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

Aprés enquète, il s'avère que le problème n'est pas au niveau des règles
iptables, mais bien au niveau du poste interne (un as400), sur lequel la
passerelle n'était pas paramétrée correctement.

Donc le problème est résolu.

Il suffisait d'y mettre le doigt dessus.

Merci encore de m'avoir aidé.

A+ GIllot ;o)

"PASCAL Gilles" <coop.ardechoise@wanadoo.fr> wrote in message
news:pan.2004.02.24.09.08.01.201757@wanadoo.fr

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

Aprés enquète, il s'avère que le problème n'est pas au niveau des règles
iptables, mais bien au niveau du poste interne (un as400), sur lequel la
passerelle n'était pas paramétrée correctement.

Donc le problème est résolu.

Il suffisait d'y mettre le doigt dessus.

Merci encore de m'avoir aidé.

A+ GIllot ;o)

Vous avez filtré cet utilisateur ! Consultez son message

"PASCAL Gilles" wrote in message
news:
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 23 -j LOG /
--log-prefix "paquets censés être natés"
dans "paquets censés être natés", il faut mettre des adresse IP, c'est

bien ça ?

Non non, il faut mettre "paquets censés être natés" :-)
C'est jsuet pour avoir une ligne reconaissable dans les logs. Tu peux
mettre aussi "T0t0" si tu veux, il suffira de faire le bon grep après.

"tail -f /var/log/messages" ne donne rien avec mes adresses ip du poste
extérieur, du poste linux et du poste local à atteindre...

Mouais... bizarre.

Voici les résultats de tcpdump :

tcpdump -i eth1 port 23

09:40:19.768997 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:22.725785 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:28.724765 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:40:40.722680 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1098 > 192.168.100.1.telnet: S 87949339:87949339(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Les paquets arrivent bien.

tcpdump -i eth0 port 23

09:41:45.791123 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:48.738755 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:41:54.736918 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)
09:42:06.734435 ALyon-102-1-1-10.w80-15.abo.wanadoo.fr.1099 > 192.168.1.254.telnet: S 88035375:88035375(0) win 65535 <mss 1420,nop,nop,sackOK> (DF)

Ils sortent apparemment bien du firewall.
Il faudrait maintenant sniffer au niveau de la machine 192.168.1.254
pour voir si elle les reçoit bien.
Si elle reçoit bien les paquets, il faut voir au niveau du serveur
telnet ce qu'il en dit (s'il reçoit quelque chose)

ben voila, je ne sais pas trop qu'en tirer, il semble qu'il n'y ai pas de
retour, non ??

Oui, comme si 192.168.1.254 ne répondait pas.

09:58:02.528933 192.168.1.254.telnet > gilles.54357: FP 1493:1493(0) ack 165 win 8192 (DF)
09:58:02.528976 gilles.54357 > 192.168.1.254.telnet: . ack 1494 win 8532 (DF)
On peut constater qu'il y a une réponse de la part du poste 192.168.1.254.
Qu'en pensez-vous ?

Arf, qu'il y a un truc bizarre kek part...

Aprés enquète, il s'avère que le problème n'est pas au niveau des règles
iptables, mais bien au niveau du poste interne (un as400), sur lequel la
passerelle n'était pas paramétrée correctement.

Donc le problème est résolu.

Il suffisait d'y mettre le doigt dessus.

Merci encore de m'avoir aidé.

A+ GIllot ;o)

iptables et translation d'adresses/ports par routeur adsl

8 réponses

Veuillez sélectionner un problème