On Thu, 21 Aug 2003 15:38:38 -0400 Sean Estabrooks <[EMAIL PROTECTED]> wrote:
> On Thu, 21 Aug 2003 15:18:20 -0400 > "Brad Hittle" <[EMAIL PROTECTED]> wrote: > > > Sean, > > > > Sorry for the lack of information. When a dialup user logs in, we go and > > check their username/password (basic stuff). We have different settings in > > our database of accounts determing that they are active, removed, etc, and > > the whole end result would be something like this: Customer A hasn't paid > > us for the internet service, so we are going to set him to the "billing" > > status (we give them an ip in the range of 192.168.153.*). When Customer A > > logs in, they can connect up just fine. But when they try to visit a > > webpage, for instance www.google.com, they are going to get "You need to pay > > us or no internet for you" message. Once we get this working, we plan to > > extend this for people with multiple logins at the same time, and other > > things that people do to irritate us. > > > > Now we have two different "You need to pay us ..." webpages. One is a > > generic page, and the other is a page that shows who they are, how much they > > owe us, and a confirmation that they saw the message and will pay us (thus > > removing them from the billing status). We want the later page for all the > > billing status, otherwise our phones would be ringing off the hook. > > > > The script we have uses iptables. For now, I am excepting all in, out, and > > forward packets (will change later, but want to get it working first). our > > script looks something like this: > > > > echo "1" > /proc/sys/net/ipv4/ip_forward > > > > iptables -t nat -A PREROUTING -p tcp -s 192.168.153.0/24 -j > > DNAT --to-destination $WEBPAGE > > iptables -t nat -A POSTROUTING -j MASQUERADE > > > > Just to clarify things a bit more, we are using the MASQUERADE option > > because once the webserver sends an acknowledgement packet back to the > > client, it never makes it back. > > > > Hi Brad, > > Thanks for the explanation, i should have picked up on the clues that > you were providing internet services. > > Everything seems to be ok except that you're masquerading even for > connections to your internal webpage. This is why you see the IP > address of the "proxy" box. If you exclude source addresses of > 192.168.153.0/24 from your MASQ rule everything should work fine.. > > > Cheers, > Sean > > Opps, hit send a bit too quickly. I see that you already tried it without the MASQ rule. The MASQ rule does explain why you're seeing the "proxy" box ip in all your packets... If it is not working without the MASQ rule this means your webserver does not know how to route back properly to the 192.168.153.0/24 subnet. One idea would simply to be add a route on the webserver to route all traffic for the 192.168.153.0/24 subnet back to the proxy box.... Cheers, Sean -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
