FC3 traffic can't get thru firewall

Kevin Fries kevin at hcico.com
Mon Feb 14 02:22:53 UTC 2005


Tony Dietrich wrote:

>On Sunday 13 Feb 2005 18:43, Bill Gradwohl wrote:
>  
>
>>Tony Dietrich wrote:
>>    
>>
>>>Wild guess here .. when you/they set up the firewall, did they hardcode
>>>into the firewall the maximum number of internal IPs they expected ... ie
>>>"we're never going to have more than 70 machines, and even tho DNS can
>>>allocate more than 70 addresses, we'll write the firewall script to only
>>>allow the first 70 past"?
>>>      
>>>
>>The firewall has no limits imposed on it. Since this is Sunday, most of
>>the end user boxes are turned off, so I doubt there are more than 30
>>boxes turned on.
>>
>>    
>>
>Oh well, worth a thought .. eliminate all the improbable, and you are left 
>with a few less culprits :p .. and I'm sure anyone who's been around has seen 
>other silly things done in the name of 'security' :p
>
>Have you checked the deny rules as well as the allow rules in your chains?  Is 
>there a typo somewhere? Is there something in hosts.deny on the server that 
>is stopping xinetd from acepting the connections?  Is squid running and 
>swallowing replies because of some ACL?  (OK, so 99.9% of these questions are 
>probably hopelessly wrong, but I was just free-thinking!)
>  
>
I have been sorta following this thread as I too am having one hell of a 
time with the Linux firewall since upgrading FC2->FC3.

Maybe my experiences are similar enough that someone can figure this 
out, because its just f-ing goofy!!

If I clear my firewall rules (iptables -X; iptables -F; iptables -Z) and 
set policy on INPUT, OUTPUT and FORWARD to ACCEPT, my network runs 
great.  But if I set any rules, any at all, the system slows down so 
badly that it might as well be down.  My windows machines keep timing out.

In addition, SSH is no longer accepting connections (no passwords, only 
via public key encryption fails with "Permission denied (publickey).").  
Shut down the firewall, everything is fine.  Now I know what you are 
going to say, its blocking port 22... thats the funny part, port 22 
answers via telnet.  SSH just stops authenticating.  Ditto Postfix, I 
can telnet to port 25 and get a response, but never get the initial 220 
welcome message.  Its almost as if the iptables is allowing the port 
open, but not allowing traffic though.

Also, if I issue an iptables -L command, it takes like 5 - 10 seconds 
for each rule to display.  If the chain has no rules, it displays 
immediately, but if there are any rules, it creeps along until done.

To combat this, I tried to run as simplistic a set of rules as 
possible.  This script brings my network to a crawl and makes it look 
like things are down.

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

# Flush everything
iptables -F
iptables -X
iptables -Z

# Allow unrestricted access from the inside network
iptables -A INPUT -s 192.168.112.0/24 -j ACCEPT
iptables -A OUTPUT -s 192.168.254.112.0/24 -j ACCEPT

# Allow SSH from anywhere
iptables -A INPUT -s 0/0 -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -s 0/0 -p tcp --sport 22 -j ACCEPT

# Allow SMTP from anywhere
iptables -A INPUT -s 0/0 -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -s 0/0 -p tcp --sport 25 -j ACCEPT

# allow DNS from anywhere
iptables -A INPUT -s 0/0 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -s 0/0 -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -s 0/0 -p tcp --sport 53 -j ACCEPT
iptables -A OUTPUT -s 0/0 -p udp --SPORT -j ACCEPT

# allow Webmin from anywhere
iptables -A INPUT -s 0/0 -p tcp --dport 10000 -j ACCEPT
iptables -A OUTPUT -s 0/0 -p tcp --sport 10000 -j ACCEPT

# Everyone else kiss off
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
-----------------------------------------------------------

Windows machine in the office, dead slow, file access even on the 
machine, dead slow, can not log in via SSH, and Postfix does not 
complete handshake, but webmin access from home, quick as a bunny. 

Weird eh?

Kevin Fries




More information about the fedora-list mailing list