of course its Linux! i am feeling a bit insulted that anyone would think otherwise ;) grin
The "wacky" port numbers for the httpd are to keep it off low numbered ports and run as non-root. Any suggestions for something better and how to do it?
ah.. "split dns" cute term... what iptables rules can be put in the firewall to bounce the traffic back? Tried it and failed :(
DMZ comes when more money comes in :)
Charles Steinkuehler wrote:
hanasaki wrote:
The goal is to have an internal webserver:
- DONE - running on a high numbered port
- DONE - firewall forwards 80->7777 on webserver
- DONE - external hits on www.blah.com served by the httpserver
- ???? - internal/intranet also can hit the webserver as www.blah.com
The problem is that www.blah.com resolves to the external internet IP and then gets routed out of the firewall which does not come back in and get forwarded to the internal webserver. It would be ideal if internal web browser hits went straight to the internal server.
I know this will work if i setup the host/domain www.blah.com on internal dns so it resolves to the internal server IP. It would also probably work with some fancy proxy config pac for the proxy setup in IE/Firefox. The DNS solution is high maintenance (hosts change quite often for business reasons). The proxy pac is, from what i understand fallen in disfavor and a bit of a pain to admin and keep working over both IE and Firefox. Proxy pac's also require an internal website to get them from in the config. We need to minimize user involvement in setup and also minimize overhead.
If you don't want to do the split zone DNS thing (which wouldn't cover for the wacky ports used by your webserver), you have to loop all traffic through the firewall, ie packet flow looks like:
client -> FW -> server -> FW -> client
This seems wacky, but is exactly what you'd get if you put your server(s) on a DMZ network (a GoodIdea, by the way).
Since your server is sitting next to your client machines, the firewall will have to do NAT (or transparent proxying) and talk to the server with an IP assigned to the firewall. The server will then send the responses back to the firewall where they can be mangled as required and sent on to the client system.
No black magic involved, although you have to be a bit careful about exactly how you create your port-forward, NAT, and IPTables setups. The firewall *IS* a linux box, right?!?
-- Charles Steinkuehler [email protected]