Thanks for responding,  but....

>From: "lakomok" <lakomok@free.fr>
>To: "netbsd-help" <netbsd-help@netbsd.org>
>Subject: Re: ip(nat&filter) + webserver question
>Date: Thu, 7 Feb 2002 10:08:25 +0100
>
> > TIA for any help someone can give.
> >
> > I've got the classic setup.  Static IP (w.x.y.z), NetBSD
> > firewall/router(ipfilter/ipnat), internal network with a webserver @
> > 192.168.a.b.
> > Nat is configured to RDR port 80 requests to the internal webserver
> > 192.168.a.b
> >
> > Almost all is well.  WAN computers can access the pages on the webserver
> > correctly, and internal network computers can access the pages if they 
>go
> > directly to 192.168.a.b.
> > BUT.... (isn't there always a BUT?)
> > If INTERNAL computers (i.e. 192.168.c.d) go to w.x.y.z, nuthin' happens.
> > "The page cannot be displayed".
> >
> > This isn't a huge problem, except that i want internal computers to 
>access
> > my domain (my.domain.com, which correctly points to w.x.y.z) from
> > inside......
> >
> > i could always make an entry in the hosts file of each of the internal 
>net
> > computers to make my.comain.com point to 192.168.a.b, but that seems 
>like
> > such a hack that shouldn't be necessary with ip(nat/filter).
>
>No no, install a local DNS which will be able to resolve
>your external name (www.yourdomain.com) into w.x.y.z
>
>or more simply, if your www.domain.com is known from your provider
>DNS, just install a forwarding DNS
>
>see forward in "man named.conf"
>
>moreover, it is maybe a httpd.conf problem
>with the directive ServerName (or something like this)
>your http server must answer back the content of this directive
>to browser so if you put a local name or a local IP
>wan computer won't be able to find a route to your server
>


Actually, i've already got a our DNS provider's DNS server pointing 
my.domain.com to w.x.y.z with an A record already, and that doesn't seem to 
be the problem at all.  going to either http://w.x.y.z OR 
http://my.domain.com from an external computer is just fine, and going to 
http://192.168.a.b from an internal computer is just fine also.



> > My hunch is that i'm doing this to myself in IPFILTER somewhere....
> > here's the relevant entries...
> >
> > # to let in http requests
> > pass in on sip0 proto tcp from any to any port = 80 keep state keep 
>frags
>
>
>you are wrong on this spot
>you have to know that ipnat is processed BEFORE ipfilter
>the rule you add to let pass in port 80 is complety unuseful
>because the rdr rule in your ipnat redirect connections to port 80
>before they reach ipfilter (have a look at your log the ipfilter port 80
>rule is never used)


I'm afraid that's not true:
% ipfstat -hi
(other rules)
74 pass in on sip0 proto tcp from any to any port = 80 keep state keep frags

The rule is getting used.


> > # to let internal guys out (and replies)
> > pass out on sip0 proto tcp from any to any flags S keep state keep frags
>
>you are wrong too here
>if you were in a routed LAN it would correct (i-e all your machine have
>an offcicial IP)
>BUT you are in a LAN with private IP (192.168.c.d)
>the pass out rule is as unuseful than the pass in rule for the same
>reason => ipnat is processed before ipfilter


And
%ipfstat -ho
(other rules)
21144 block out on sip0 from any to any
16406 pass out on sip0 proto tcp from any to any flags S/0xff keep state 
keep frags

the pass out rule is also getting used to allow the internal network to 
access the internet.


>the solution four you, is what people call ipnat overloaded
>
>you have to add a map rule in ipnat configuration
>that translate all your internal IP in your external IP
>and ipnat session rulez you won't need to route back to
>your internal LAN because all outgoing connection through
>ipnat will come back to the right local IP
>
>BUT
>
>I am so sorry, I can't remember the syntax of such ipnat rule
>because my NetBSD box is down for the moment (so I can't
>have a look at it)
>
>but this is the solution to your problem (I think, if I mistook
>anyone will correct me, be sure of this)
>


I will take a look into ipnat overloading.  Thanks for the bit of direction.


> > or maybe it has something to do with the "portmap" in ipnat.conf?  are 
>the
> > internal request's ports getting rewritten before the request tries to 
>go
> > back through the rdr?
> >
> > thanks again for your time.
> >
> > Jeremy Hou
>
>hope that's help
>--
>Nino
>  May NetBSD be with you
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.