Firewall Rule Set not allowing access to DNS servers?

Giorgos Keramidas keramida at ceid.upatras.gr
Sat Jul 31 10:36:49 PDT 2004


On 2004-07-31 12:08, "James A. Coulter" <james.coulter at cox.net> wrote:
> My LAN is configured with static IP addresses, 192.168.1.x.
>
> I have no problems communicating within the LAN.
>
> I have full connectivity with the internet from every machine on my LAN when
> the firewall is open.
>
> When I use the rule set in question, I can ping and send mail but I cannot
> access the DNS servers listed in resolv.conf.

There are many ways in which your ruleset might break.  Two of the most
important comments I wanted to make when I first saw the posts of this
thread are:

	a) Why do you use static rule numbers?

	   You'd only have to use static rule numbers if your ruleset
	   had more than 65536/100 = 655 rules.  This limit is
	   relatively hard to hit in a SOHO installation (Small Office,
	   Home Office).  If you do reach such limits, there's
	   definitely something weird going on with the way your ruleset
	   is written ;-)

	b) Why do you use so many rules that 'filter' outgoing traffic?

	   I saw smtp, pop3, time, http, https and many others.  You
	   don't need to explicitly allow outgoing connections unless
	   the users in the internal LAN are not to be trusted at all
	   and even then IPFW is most of the time not the right way to
	   do it.

I'd probably just use something of this form in the /etc/ipfw.rules file
and let rc.firewall find it by setting firewall_type="/etc/ipfw.rules"
in my rc.conf file:

	# First clean up all the rules of ipfw.
	flush

	# Packets should be passed to natd *before* any other rule as
	# mentioned in the natd(8) manpage, unlike your current script.
	add divert natd all from any to any via dc1

	# Allow only lo0 interface to use the 127.0.0.1 address.
	add allow ip from 127.0.0.1 to 127.0.0.1 via lo0
	add deny ip from 127.0.0.1 to any
	add deny ip from any to 127.0.0.1

	# Add only the dc0 interface to receive or send packets in the
	# 192.168.0.0/16 address range.
	add allow ip from 192.168.0.0/16 to 192.168.0.0/16 via dc0
	add deny ip from 192.168.0.0/16 to any
	add deny ip from any to 192.168.0.0/16

	# Block packets with addresses that are used in private networks
	# and should not appear in any of our interfaces below this point.
	add deny ip from 10.0.0.0/8 to any
	add deny ip from any to 10.0.0.0/8
	add deny ip from 172.16.0.0/12 to any
	add deny ip from any to 172.16.0.0/12

	# Allow DNS and NTP through.
	add allow udp from any to any 53,123 keep-state out

	# Pass all ICMP messages through.  They're rate limited by the
	# kernel if sysctl net.inet.icmp.icmplim is enabled, so this is
	# not very unsafe to do.
	add allow icmp from any to any

	#
	# Stateful tcp filtering.
	#

	add check-state
	add deny tcp from any to any established

	# All outgoing and incoming connections are allowed in dc0 (private iface).
	# Only outgoing connections are allowed on dc1 (external iface).
	add allow tcp from any to any keep-state out xmit dc0 setup
	add allow tcp from any to any keep-state in  recv dc0 setup
	add allow tcp from any to any keep-state out xmit dc1 setup

	# Only selected services are allowed to pass through external iface.
	add allow tcp from any to any  22 keep-state in recv dc1 setup
	add allow tcp from any to any 113 keep-state in recv dc1 setup

	# The default firewall policy.
	add deny log logamount 0 ip from any to any

No inline numbers, a simpler layout and a logic that you can hopefully
extend at the second from last paragraph to allow more services through
your external interface (the `in recv dc1 setup' rules).

Note that I haven't tested this, so it might contain syntax errors
because it's based on the ruleset I'm using at home but it also includes
some modifications.  Instead of untangling the ruleset you're now trying
to use which seemed unnecessarily complex to me, I'm posting this just
in case it's useful but it's up to you to bring it to shape for your
setup if it doesn't "Just Work(TM)" when you load it.

- Giorgos



More information about the freebsd-questions mailing list