On 2008-10-09 Tamas Hegedus wrote: [...] > echo "1" > /proc/sys/net/ipv4/ip_forward
You shouldn't enable IP forwarding before the policies for your chains have been set. Better do something like this: echo "0" > /proc/sys/net/ipv4/ip_forward iptables -P INPUT DROP #... echo "1" > /proc/sys/net/ipv4/ip_forward [...] > iptables -P INPUT ACCEPT > iptables -F INPUT > iptables -P OUTPUT ACCEPT > iptables -F OUTPUT > iptables -P FORWARD DROP > iptables -F FORWARD "iptables -P INPUT ACCEPT" is a bad choice for a firewall. Don't do that in a productive environment. Use "iptables -P INPUT DROP" instead and whitelist what you want to accept. And you can use "iptables -F" to flush all default chains in the filter table in one go. iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -F > iptables -F -t nat You should also set the policies for the nat table: iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT > iptables -F -t mangle Same goes for the mangle table, unless you don't have it in your kernel (which is advisable if you don't want to use it in the first place). > # Flush the user chain.. if it exists > if [ "`iptables -L | grep drop-and-log-it`" ]; then > iptables -F drop-and-log-it > fi > > # Delete all User-specified chains > iptables -X Flushing user-defined chains is pointless if you're deleting them anyway. [...] > iptables -A drop-and-log-it -j REJECT As a suggestion, it's better to reject like this, IMHO: iptables -A drop-and-log-it -p tcp -j REJECT --reject-with tcp-reset iptables -A drop-and-log-it -p udp -j REJECT --reject-with icmp-port-unreachable iptables -A drop-and-log-it -j DROP [...] > iptables -A OUTPUT -o lo -j ACCEPT > iptables -A OUTPUT -o $EXTIF -s $EXTIP -j ACCEPT > iptables -A OUTPUT -o $EXTIF -s $INTNET -j ACCEPT > iptables -A OUTPUT -j drop-and-log-it This is the source of your problem, AFAICS. You allow outgoing packets only on external and loopback interfaces, and reject everything else with your drop-and-log-it rule. That means: packets coming in on port 22/tcp reach the SSH daemon, but the response packets are dropped by your firewall. Therefore your internal client is unable to establish a connection. Personally, unless you have rather high security requirements, I'd suggest to just accept everything in the OUTPUT chain. The packets handled by this chain originated from the host anyway, and only the firewall admins should have accounts on that box. Keep things simple. However, if you want to restrict outgoing traffic from the firewall host itself, I'd suggest to use something like this instead: iptables -P OUTPUT DROP iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # allow particular outbound connections, e.g. DNS iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT #... # reject everything else iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset iptables -A OUTPUT -p udp -j REJECT --reject-with icmp-port-unreachable Regards Ansgar Wiechers -- "The Mac OS X kernel should never panic because, when it does, it seriously inconveniences the user." --http://developer.apple.com/technotes/tn2004/tn2118.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
