Date: Sat, 31 Jul 2004 14:17:14 -0400 From: "JJB" <Barbish3@adelphia.net> To: "Giorgos Keramidas" <keramida@ceid.upatras.gr>, "James A. Coulter" <james.coulter@cox.net> Cc: freebsd-questions@freebsd.org Subject: RE: Firewall Rule Set not allowing access to DNS servers? Message-ID: <MIEPLLIBMLEEABPDBIEGEEDEGIAA.Barbish3@adelphia.net> In-Reply-To: <20040731173613.GA30298@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
-----Original Message-----
From: owner-freebsd-questions@freebsd.org
[mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Giorgos
Keramidas
Sent: Saturday, July 31, 2004 1:36 PM
To: James A. Coulter
Cc: Barbish3@adelphia.net; freebsd-questions@freebsd.org
Subject: Re: Firewall Rule Set not allowing access to DNS servers?
On 2004-07-31 12:08, "James A. Coulter" <james.coulter@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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MIEPLLIBMLEEABPDBIEGEEDEGIAA.Barbish3>