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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Giorgos Keramidas Sent: Saturday, July 31, 2004 1:36 PM To: James A. Coulter Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Firewall Rule Set not allowing access to DNS servers? On 2004-07-31 12:08, "James A. Coulter" <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"