iptables blocking port 53 unexpectedly on a dual NIC Fedora install
On a Fedora 12 box with two NICs, I am trying to achieve this behavior:
All ports should be open on eth0 (which is on the LAN side)
Only ports 80 and 22 should be open on eth1 (which is the WAN side - although there's some port forwarding magic elsewhere).
Here's my /var/sysconfig/iptables:
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
The symptom is that when I run BIND on this box, LAN clients attempting to access through eth0 (using port 53) get timeouts. However, if I stop iptables, clients succeed as expected.
I thought the line "-A INPUT -i eth0 -j ACCEPT" would accept any an all traffic through eth0. Any ideas what I'm doing wrong, or how to troubleshoot?
You should not use REJECT for all traffic that does not match, as it opens you up for DOS. At least rate-limit it using the rate module.
Try removing the INPUT -j REJECT rule, so iptables should be allowing everything through everywhere and see if you still get the timeouts.
If that doesn't work help enable the rule again and run 'tcpdump -i eth0 port 53' and post the output.
One trick I use when debugging iptables is to make a specific rule what what I think the traffic should match, and then run 'watch' on 'iptables -vnL'. This will give you a realtime update on what rules are matching.
Set up some rules to match for our BIND traffic:
watch --interval 0 'iptables -vnL | grep -v "0 0"'
('grep -v' removes any lines that match '0 0' which is an iptables rule with no matches yet. You might not need that unless you have lots of rules)
Thanks, SJW, particularly for the technique to watch which rules are triggering in real time. That's a very slick trick!
I added the rule you suggested to accept udp on port 53 and it triggers correctly. I still have no idea why the rule to accept all input on interface eth0 almost never triggers (I have seen it trigger once, but not in response to anything I did). Any ideas on what's wrong with that rule would be appreciated. I understood the rules are evaluated in order, and the interface check precedes the upd/port-53 check, so why doesn't the interface rule fire?
It will only trigger for new traffic because you have a rule at the top accepting all established/related traffic. So the first packet in a stream from eth0 should match the rule, then all other packets will match established/related.
With the rule accepting port 53 in place, does the DNS still timeout?
Very helpful, again. With the rule for port 53 in place, the client timeouts are eliminated. Thank you!
That rule was mostly for debugging, at the moment it is allowing 53 in from your external interface as well.
Can you post this from some of your clients:
cat /etc/resolv.conf shows this:
nameserver 192.168.1.203 # the LAN address of my BIND server
nameserver 220.127.116.11 # OpenDNS primary DNS
nameserver 18.104.22.168 # OpenDNS secondary DNS
or, on another group of machines, this:
nameserer 192.168.1.254 # The LAN address of my router, also a DHCP server
The DHCP server has the local address (...203) as the primary DNS and has OpenDNS as a secondary.
In order to close 53 to the public, I changed the rule for port 53 to specify the LAN interface (eth0):
-A INPUT -p udp -i eth0 --dport 53 -j ACCEPT
|All times are GMT -5. The time now is 06:41 AM.|