Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Currently the NAT host and respective clients are able to access any service. I like the NAT host (the device running IPTABLES) to only be able to access HTTP(S), DNS and send/respond to ICMP requests.

I would like the internal clients behind $INTIF to only access HTTP(S) and DNS. I tried multiport but I had little luck. I'm open to other suggestions.

-A INPUT -p tcp -i eth1 --dport 22 --sport 1024:65535 -m state --state NEW -j ACCEPT
-A INPUT -i "$INTIF" -p udp --dport 53 -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "input denied: " --log-level 7

-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -m multiport -p tcp --dports 80,443 -j ACCEPT
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "forward denied: " --log-level 7

-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "output denied: " --log-level 7
share|improve this question
up vote 1 down vote accepted

Remove "NEW" from the second FORWARD rule (this is what is accepting all outgoing connections).

The third and fourth forward rules should be something like

-A FORWARD -i "$INTIF" -o "$EXTIF" -m multiport -p tcp --dports 80,443,53 -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -p udp --dport 53 -j ACCEPT

As an aside, your default INPUT policy is accept, so after logging "input denied" the packet is accepted anyway.

share|improve this answer
I updated the rule set with your recommendations but the internal clients are unable to connect to HTTP after doing so. I have updated the original post to reflect the changes that were made. – Astron Jun 10 '11 at 15:01
@Astron Is it logging the attempts as "forward denied"? – DerfK Jun 10 '11 at 15:36
@DerflK My mistake, the NAT host is also acting as a DNS forwarder so I added the appropriate rule to the INPUT chain to allow for resolution. I assume 53/TCP will not be need as the clients will not be receiving zone transfers. Lastly, should I use a similar method to lock-down the host on the INPUT and OUTPUT chains? – Astron Jun 10 '11 at 16:23
TCP is used for any query (or its results) that will not fit in a UDP packet. The host looks fairly locked down from the outside now that deny is default. It can still connect out to anything so depending on your situation you may want to lock it down further on the OUTPUT chain. If you remove the NEW there you'll need to be sure to allow outgoing DNS plus whatever else that server needs to connect to on both networks. – DerfK Jun 10 '11 at 17:57

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.