Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've just taken over administration of a fairly complex firewall ruleset for a firewall box running Fedora Core 12, and there's one thing about it that is puzzling me.

When I run nmap on the gateway from outside the network, I see all the expected services, but also sunrpc on port 111. The INPUT chain has DEFAULT DROP set, and there is no rule allowing port 111. As best I can tell (watching the packet counters before/during/after the scan) it's being allowed by the rule: "-m state --state RELATED,ESTABLISHED -j ACCEPT" but I don't understand why a brand new TCP connection would be considered RELATED or ESTABLISHED.

Any suggestions would be greatly appreciated.


Conntrack modules:

nf_conntrack_netlink    14925  0 
nfnetlink               3479  1 nf_conntrack_netlink
nf_conntrack_irc        5206  1 nf_nat_irc
nf_conntrack_proto_udplite     3138  0 
nf_conntrack_h323      62110  1 nf_nat_h323
nf_conntrack_proto_dccp     6878  0 
nf_conntrack_sip       16921  1 nf_nat_sip
nf_conntrack_proto_sctp    11131  0 
nf_conntrack_pptp      10673  1 nf_nat_pptp
nf_conntrack_sane       5458  0 
nf_conntrack_proto_gre     6574  1 nf_conntrack_pptp
nf_conntrack_amanda     2796  1 nf_nat_amanda
nf_conntrack_ftp       11741  1 nf_nat_ftp
nf_conntrack_tftp       4665  1 nf_nat_tftp
nf_conntrack_netbios_ns     1534  0 
nf_conntrack_ipv6      18504  2 
ipv6                  279399  40 ip6t_REJECT,nf_conntrack_ipv6

INPUT chain on the filter table:

-A INPUT -s -p tcp -m tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT 
-A INPUT -s -i lo -j ACCEPT 
-A INPUT -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT 
-A INPUT -d -i eth0 -j ACCEPT 
-A INPUT -d -i eth0 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p tcp -m multiport --dports 22,80,443 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p tcp -m multiport --sports 22,25,80,443 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p udp -m udp --dport 1194 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p udp -m udp --sport 1194 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p udp -m multiport --sports 53,123 -j ACCEPT 
-A INPUT -d {public_ip}/32 -i ppp0 -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -i eth0 -m state --state NEW -j ACCEPT 
-A INPUT -d {public_ip}/32 -m state --state NEW -j ACCEPT 

eth0 is connected to the internal network, eth3 is connected to an ADSL modem in bridge mode, ppp0 is the WAN connection tunneled over eth3.

share|improve this question
The behaviour of --state RELATED is affected by which conntrack modules are loaded in the kernel. Could you do an "lsmod|grep conntrack" and let us know which ones you have active? –  MadHatter Oct 6 '10 at 9:09
"[T]here is no rule allowing port 111." Are you sure? Can you post the rules? –  Mark Wagner Oct 6 '10 at 23:03
I've added more detail to the initial post. I've only posted the INPUT chain because there's a bunch of NAT and accounting stuff happening as well and the full ruleset is quite long. –  complexgeek Oct 7 '10 at 0:21

1 Answer 1

-A INPUT -d {public_ip}/32 -m state --state NEW -j ACCEPT

This says, "accept all new connections" and that says it all.

If you want to diagnose this yourself, look at the iptables counters before and after your scan. Not only will you see that rule increment, but you'll also notice it's letting in a rather large number of new connections.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.