On Thu, 2003-08-21 at 14:57, Jason Dixon wrote:
> On Thu, 2003-08-21 at 14:36, Sean Estabrooks wrote:
> > On Thu, 21 Aug 2003 14:24:04 -0400
> > "Brad Hittle" <[EMAIL PROTECTED]> wrote:
> >
> > > We keep a status for the dialup account users. When they logon, they
> > > recieve a specific IP from us denoting status (ie if they are in the billing
> > > status the ip would range from 192.168.153.*).
> > >
> > > When we only use DNAT, the packets never make their way back to the client
> > > machine. Thats why we are routing the packet back through the proxy server.
> > > I have sniffed every possible place along the line using only the DNAT
> > > (excluding the router, and some other machines it must go through), and have
> > > seen everything working properly.
> > >
> > Not sure i understand your configuration well enough to help much, but
> > if you post your iptables(?) rules for DNAT someone may be able to help.
> > I'm interested to know what you mean by "they recieve a specific IP from us",
> > do you mean in your billing system or do you actually modify their
> > incoming ip in someway "on the wire".
>
> Assuming your "proxy" hasn't rewritten the HTTP header, you should be
> able to get the client's source address from the REMOTE_ADDR value. In
> Perl, this would be $ENV{REMOTE_ADDR}. I'm not sure what the equivalent
> would be in ColdFusion.
Oh, one other thing I forgot to mention. If your clients and the
webserver are on the same network segment, you'll also need to perform
SNAT. Without modifying the source address of the packet (layer 3, not
layer 7), the server will attempt to simply return the packet directly
to the client, rather than through the "proxy", as it should. If you're
familiar with the TCP 3-way handshake, you'll understand what I mean.
If not, try and read up on it.
HTH.
--
Jason Dixon, RHCE
DixonGroup Consulting
http://www.dixongroup.net
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
