On Thu, 10 Oct 2002, Marc Hunter wrote:
> Thank you all for your responses so far.
>
> We tried the divert option and it almost worked :>
>
> We can see that the packet got natted but the request still times out.
> From what I can gather what is happening is that machine A (user) sent
> the packet to machine B (firewall) which sent the packet to machine C
> (internal web server) which responded with a packet to machine A,
> however machine A was expecting its answer from machine B. (Assuming a
> tcp connection request must receive the response from the machine it was
> sent to...)
>
> What is curious is that the nat converted the 'to' address correctly,
> but didn't change the from address to the firewall address as it does
> with outside traffic, so we could be missing something. Our additional
> divert looks as follows:
>
> divert natd log tcp from 192.168.0.0/24 to 24.70.100.100 80 in via rl1
>
> our natd.conf says:
>
> redirect_port tcp 192.168.0.129:80 80
>
> (and the interface is set to rl0 which is the outside world).
>
> > 1) Use another domain (point to inside)
> > 2) Setup subdomain www.internal.domain.com
>
> It actually is a subdomain which we are using, but neither of these
> options is feasible as we need to have our website links the same
> whether a page is accessed internally or externally...
That is an HTML coding problem. You shouldn't be coding with
full domain references in the HTML code.
>
> > 3) Setup nameserver to respond differently depending on source IP
>
> I suppose if there is no other way we will have to consider this, but we
> hadn't counted on having to do this :<
It's easy, just run an internal nameserver....
>
> > 4) Run a proxy server
>
> This whole project is to get rid of our Wingate proxy, a hardware firewall
> and a linux firewall, so we were hoping to avoid this (thus the use of nat).
>
> Someone suggested using the ipfw fwd command, which we will try, but I
> suspect it will present the same problem as the divert above...
>
ipfw fwd will not work.
> Here are some questions which may reveal our ignorance:
> Can you 'attach' natd to both the internal and external
> interfaces?
> Perhaps have two copies running and the one on the internal
> interface would only get triggered by the divert rule we added above? I
> suppose it would have to run on a different port in any case...
Yes, you could do this but it's not necessary and it's very ugly.
Run an internal nameserver!! It's just that easy ;-P
> Would ipf and ipnat have a solution to this problem or are they roughly
> the same thing, different syntax (insofar as basic firewall/nat needs
> go)?
It's possible, I'm not familiar with ipf/ipnat.
Nick Rogness <[EMAIL PROTECTED]>
-
"Wouldn't it be great if we could answer people with a
kick to the crotch?" [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
