[OT] Firewall Rule Set not allowing access to DNS servers?

[Steve Bertrand]

> 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 ;-)
>

Giorgos, I am interested in where I can get more information about
this. Are you suggesting that IPFW reads the ruleset and formulates a
rule number according to position in the script? (I always use custom
scripts).

If this is true, how does this ``dynamic'' feature get affected when
one houses multiple rule _sets_?

Can you please provide any links to information that I can gain
valuable information on this? This would certainly make ruleset
creation much easier ;o)

Also, links to any information on how/what/why on the 16b/100 limit on
the dynamic rules, so I (we) can learn more about this?

I must admit, I've never even come within 1/15 of this number, but it
is interesting. All my rules have always been simply, allow, allow,
allow, DENY.

Tks much,

Steve



> 	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
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
>