BSD DevCenter
oreilly.comSafari Books Online.Conferences.


BSD Firewalls: IPFW Rulesets
Pages: 1, 2, 3

Let's see what happens by adding these rules. Once I've double-checked my changes for typos and saved the file, I'll type:

killall init
press Enter, then type:

and watch my boot messages to make sure my rules load without any syntax errors. If you instead receive an error message, your security level may be set to 3 or higher and you'll have to first change this line in /etc/rc.conf to a smaller value:


then repeat the killall init command.

Once I'm logged back in, I'll see if I can send any IP packets out to the Internet and receive some replies back:

ping: cannot resolve Host name lookup failure

Alert!. Unable to access document.

Hmmmmm. Looks like I still don't have DNS name resolution. Let's try that again, using an IP address instead:


This time, I find myself at the home page of Let's try pinging that IP address:

PING ( 56 data bytes
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied
--- ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Now, let's try to understand this odd behaviour, as obviously some packets are going in and out of my computer and some are not. Let's start by picking apart which protocols I used in each of the examples above.

Name resolution is failing, as I was only able to access by using its IP address. When I use DNS, I send a name lookup request to my service provider's DNS server, which should send the response back to me. This seems to match our rules, as I make the request on port 53 and should receive a request back on port 53. I better double-check that I am aware of which DNS servers to send a request to:

more /etc/resolv.conf

That doesn't seem to be the problem, so it's time to look a bit deeper at how name resolution works. Let's see if we can glean any information from the online manual pages:

apropos resolve
dnsquery(1) - query domain name servers using resolver
res_query(3), res_search(3), res_mkquery(3), res_send(3), res_init(3), dn_comp(3), dn_expand(3) - resolver routines
resolver(5) - resolver configuration file

I'll then try

man resolver

but will end up at man 3 resolver. Being the curious type, I read it anyway and am intrigued by these lines:

RES_USEVC   Use TCP connections for queries instead of UDP datagrams.

RES_STAYOPEN   Used with RES_USEVC to keep the TCP connection open between queries. This is useful only in programs that regularly do many queries. UDP should be the normal mode used.

I may be onto something here; if DNS is using UDP instead of TCP, my name lookup will fail, as I've made rules only to allow TCP responses to my TCP connections. Now I'll try that manpage for dnsquery:

man dnsquery

<snip to just show intriguing part>

-s  Use a stream rather than a packet. This uses a TCP stream connection with the nameserver rather than a UDP datagram. This sets the RES_USEVC bit of the resolver's options field. (Default: UDP datagram.)

Now, there's a switch I want to try:

dnsquery -s
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39772
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;;, type = ANY, class = IN 49m21s IN CNAME 22m43s IN NS 22m43s IN NS 22m43s IN NS 22m43s IN NS 22m43s IN NS 1h1m3s IN A 1h1m3s IN A 12m37s IN A 11h9m9s IN A 1h8m12s IN A

Looks like name resolution works nicely when I make a DNS request using TCP. Let's try it one more time without that s switch to see if it works with UDP:

Query failed (h_errno=2) : Host name lookup failure

There we go; DNS is using UDP packets, and since I haven't allowed for UDP packets in my ruleset, I'm not getting DNS name resolution.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: