> >From your post:
> rdr ep0 aaa.bbb.ccc.149/0 port 53 -> 192.168.2.149 port 53 tcp/udp
> 
> My interpretation:
> You have a name server running on 192.168.2.149 (on the internal network).
> You are redirecting external queries at aaa.bbb.ccc.149 to 192.168.2.149

Right.  (aaa.bbb.ccc.149 is the IP of the name server I've been running
for the last 4 years, so I was hoping to keep that IP even though it is
physically behind the FW.)

> Based on my interpretation:
> It would be a good idea to make sure your client machine can ping -n
> 192.168.2.149, and then make sure your client can use 192.168.2.149 as a
> nameserver.  If it can't, the problem is in the routing, named
> configuration, or the client configuration.  (gee, sure narrowed that

I tend to think that my problem is that queries from inside the FW go out,
but either are not able to get back into the name server, or the name
server's response is not able to get out and/or back in, steps 2,3 or 4:

      internal client  == ns query ==> FW ===\\      (step 1)
                                             ||
      internal ns      <== ns query == FW ===//      (step 2)
      |         |
      internal ns      == ns reply ==> FW ===\\      (step 3)
                                             ||
      internal client  <== ns reply == FW ===//      (step 4)

Somehow state would have to be kept throughout the transaction, but
I don't have the foggiest idea where to start to do that.  The following
is working flawlessly:

      internal ns  <== ns query == FW <== ns query from external client
      |         |
      internal ns  == ns reply ==> FW ==> ns reply to external client

I've tried the following, but the query times out rather than fail.
Again, I have no idea where to look.  One problem might be that the
name of 192.168.2.149 (ns1.bio.kindai.ac.jp, in /etc/hosts) and
aaa.bbb.ccc.149 (ns1.kindai.ac.jp, in named's kinki.zone) are
different.  The fact is, though, the "internal ns" is the authority
name server for kindai.ac.jp, not the sub-domain bio.  The internal
lan has no name server of its own, only /etc/hosts.
 
        internal client
         ||      /||\
    ns query   ns reply
        \||/      || 
         internal ns

> > > Could you post the output of 'netstat -nr'?
> > 
> > It's a pretty busy LAN so I've edited out the various unrelated PCs.  The
> > following is the output of the firewall (i586 running NetBSD1.4.2/i386).
> > Destination         Gateway            Flags     Refs     Use    Mtu  Interface
> > default            aaa.bbb.ccc.254     UGS         0    77421      -  ep0
> > 127.0.0.1           127.0.0.1          UH          1       24      -  lo0
> > aaa.bbb.ccc/24      link#1             UC          0        0      -  ep0
> > aaa.bbb.ccc.149     00:10:5a:7c:38:c4  UHL         0     1404      -  lo0 =>
> > aaa.bbb.ccc.149/32  link#1             UC          0        0      -  ep0
> > aaa.bbb.ccc.201     08:00:20:9f:9d:d3  UHL         0       25      -  ep0
> > aaa.bbb.ccc.254     00:e0:2b:65:12:00  UHL         1        0      -  ep0
> > 192.168.2           link#2             UC          0        0      -  fxp0
> > 192.168.2.12        00:90:cc:10:6e:97  UHL         0       21      -  fxp0
> > 192.168.2.149       08:00:20:0f:de:94  UHL         1       46      -  fxp0
> > 
> > aaa.bbb.ccc.201 is the machine outside of the firewall running bind which
> > the internal clients can reach.  aaa.bbb.ccc.254 is the gateway to the
> > Internet.
[...]
> > > Have you placed 'sysctl -w net.inet.ip.forwarding=1' in your /etc/rc.local?
> > 
> > The kernel does that function as it was compilied with the GATEWAY option.
>
> I thought that the GATEWAY option just provided the feature of forwarding,
> but did not turn it on, and that it had to be explicitly enabled using
> sysctl.  Do you know otherwise?

I don't *know*, but except for this internal name server problem, all other
filtering and translation rules seem to be working as expected.

Any other tips much appreciated.  Thanks for what has already come in.

henry nelson