Héctor gracias por la sugerencia me parece mas que interesate, te voy a pedir que recuerdes siempre responder a la lista mas que al mail originario, así todas las respuestas quedan registradas en l alista de correo
saludos! charly El jue, 13-09-2007 a las 11:36 -0500, Héctor González escribió: > Hola Carlos, he tenido problemas similares, parece que por alguna razón, > el código de NAT requiere que aceptes los paquetes de entrada, en el > interface del NAT, y no sólo paquetes relacionados, sino todo. > > Una manera de que averigües qué pasa es insertar reglas de LOG, antes de > cada punto donde tiras paquetes, o niegas accesos, de manera que en tu > log se ve de inmediato cuando las reglas están tirando información que > debería pasar. > > Héctor González > [EMAIL PROTECTED] > > Carlos Pasqualini wrote: > > El jue, 13-09-2007 a las 10:27 +0200, Pascal Hambourg escribió: > > > >> Carlos Pasqualini a écrit : > >> > >> This one has nf_conntrack/nf_nat enabled anyway. > >> Again, please describe precisely what is going wrong. > >> > >> > >> > > > > the point is just that i don't know what it's going on... so i'm looking > > for changes that could be the source of the problem. > > > > when i start to implement a linux box as router, i test it with a script > > that do not filter anything, it just make masquerade. after all works > > well i restart the script but filtering everythng and say "this packet > > > accpet" > > > > the early script (the really unsecure one) give me failures in the > > network, the script it's so simple: > > > > iptables -F for every table / chain... > > iptables -P ACCEPT for everything > > iptables -P INPUT DROP > > > > $IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE > > > > $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > $IPTABLES -A INPUT -i lo -j ACCEPT > > $IPTABLES -A INPUT -p icmp -j ACCEPT > > iptables -N permitido > > iptables -A permitido -p tcp --syn -j ACCEPT > > iptables -A permitido -p tcp -m state --state ESTABLISHED,RELATED -j > > ACCEPT > > iptables -A permitido -p tcp -j DROP > > # external tcp open ports > > for i in `cat /etc/firewall/conf/ext_tcp_open_ports`; do > > echo -n "iptables -A INPUT --protocol tcp -i $EXT --dport $i -j > > permitido" > > iptables -A INPUT -m state --state NEW --protocol tcp -i $EXT > > --dport $i -j permitido && echo " done!" > > done > > (same for input tcp/udp ext/int ports) > > #squid routing: > > iptables -t nat -A PREROUTING -d ! 192.168.20.0/24 --protocol tcp -i > > $INT --dport 80 -j REDIRECT --to-ports 3128 > > echo 1 > /proc/sys/net/ipv4/ip_forward > > > > > > as you can see, it's a very stupid script that it can't fail!!! > > (it can be a security risk, it's ulgy.. but no problem about nat !) > > > > > > now i'm making tests at home with this box, the same script, but only > > one change: > > > > the external device it's a dhcp client on eth0, not a pppoe ppp0 and you > > know what?? IT WORKS! > > > > so, it's nothing about the iptables script ¿WTF?... it's another thing > > that i can't find... > > > > when i use ppp0 as internet connection, i run the script > > from /etc/ppp/ip-up.d/firewall.sh for example. so it executes whenever > > the ppp device it's going up, and whe have internet access. > > > > the failure was that some websites didn't work, no MSN messenger (WTF?) > > and other things like that... some things works, others don't... in a > > way that i can't find any logic about it. that's why i'm asking for > > documentation and not describing the entire situation. > > > > the point that iptables don't change anything between the old and new > > frameworks, tells me a lot. it tells me that i'm doing another even more > > stupid error !! ;) > > > > again > > thanks!! > > > > chary > > > > > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
