Firewall Rule Set not allowing access to DNS servers?
Barbish3 at adelphia.net
Sat Jul 31 11:17:16 PDT 2004
If you had read the start of the thread you would have read the new
handbook firewall section rewrite which explains in detail why there
are rules to control access to the public internet from LAN users.
From: owner-freebsd-questions at freebsd.org
[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Giorgos
Sent: Saturday, July 31, 2004 1:36 PM
To: James A. Coulter
Cc: Barbish3 at adelphia.net; freebsd-questions at freebsd.org
Subject: Re: Firewall Rule Set not allowing access to DNS servers?
On 2004-07-31 12:08, "James A. Coulter" <james.coulter at cox.net>
> 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
> access the DNS servers listed in resolv.conf.
There are many ways in which your ruleset might break. Two of the
important comments I wanted to make when I first saw the posts of
a) Why do you use static rule numbers?
You'd only have to use static rule numbers if your
had more than 65536/100 = 655 rules. This limit is
relatively hard to hit in a SOHO installation (Small
Home Office). If you do reach such limits, there's
definitely something weird going on with the way your
is written ;-)
b) Why do you use so many rules that 'filter' outgoing
I saw smtp, pop3, time, http, https and many others. You
don't need to explicitly allow outgoing connections
the users in the internal LAN are not to be trusted at
and even then IPFW is most of the time not the right way
I'd probably just use something of this form in the /etc/ipfw.rules
and let rc.firewall find it by setting
in my rc.conf file:
# First clean up all the rules of ipfw.
# Packets should be passed to natd *before* any other rule
# mentioned in the natd(8) manpage, unlike your current
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
# 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
# and should not appear in any of our interfaces below this
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
# kernel if sysctl net.inet.icmp.icmplim is enabled, so this
# not very unsafe to do.
add allow icmp from any to any
# Stateful tcp filtering.
add deny tcp from any to any established
# All outgoing and incoming connections are allowed in dc0
# Only outgoing connections are allowed on dc1 (external
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
add allow tcp from any to any 22 keep-state in recv dc1
add allow tcp from any to any 113 keep-state in recv dc1
# 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
extend at the second from last paragraph to allow more services
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
some modifications. Instead of untangling the ruleset you're now
to use which seemed unnecessarily complex to me, I'm posting this
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.
freebsd-questions at freebsd.org mailing list
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions