Thank you for the suggestion re: split horizon and tinydns. This will
probably be the easiest work around.
On 6/25/05, John Brooks <[EMAIL PROTECTED]> wrote:
> Implement a 'split-horizon' dns setup. Clients on the internal network
> are served the internal address for the resource and never need
rday, June 25, 2005 10:36 PM
> To: [EMAIL PROTECTED]
> Cc: freebsd-questions@freebsd.org
> Subject: Re: IPNAT / IPF / rdr issue
>
>
> I tried that as well, but am still getting the same 'connection
> refused' error from the web browser on the local client machine.
>
>
[mailto:[EMAIL PROTECTED]
Sent: Saturday, June 25, 2005 10:36 PM
To: [EMAIL PROTECTED]
Cc: freebsd-questions@freebsd.org
Subject: Re: IPNAT / IPF / rdr issue
I tried that as well, but am still getting the same 'connection
refused' error from the web browser on the local client machine.
Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of fbsd_user
> Sent: Saturday, June 25, 2005 9:12 PM
> To: Andy Sutcliffe; freebsd-questions@freebsd.org
> Subject: RE: IPNAT / IPF / rdr issue
>
>
> Your using the public ip address of your gateway box f
Implement a 'split-horizon' dns setup. Clients on the internal network
are served the internal address for the resource and never need to
traverse the gateway. External hosts are served from the authoritative
nameservers as is currently happening.
I set up such a system a couple weeks ago with tin
I tried that as well, but am still getting the same 'connection
refused' error from the web browser on the local client machine.
On 6/25/05, fbsd_user <[EMAIL PROTECTED]> wrote:
> Your using the public ip address of your gateway box from the
> private LAN.
> In this mode NAT and thus your rdr rule
Your using the public ip address of your gateway box from the
private LAN.
In this mode NAT and thus your rdr rule is never evoked. Your
request never exits your private network. The gateway system knows
himself by that public ip address.
What you should be doing is using the www.domainname.com so
