getting to www servers from inside where they have an Internal IP
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. Any tips? anyone doing this now and care to share their solutions? Any alternative approaches or ways to accomplish what is needed? ===============network Internal workstations (10.x.x.x) Internal webserver:7777 (10.x.x.x) Squid Proxy : 8080 ^ | intranet | =========|== firewall w/ NAT == internet | | V The Ugly World web browsers hit firewall on :80 ===============/network == proxies and http I am using a squid proxy on host:proxyhttp:8080 that is not transparent (ie: needs the proxy manually configured in the web browsers). This is because transparent proxies don't work for ports other than 80, unless they are configured for each outgoing http port, which then always goes via squid and cannot be used for any other purpose. Ran into this when trying to hit a CPanel at a web hoster that was on some high numbered port.
hanasaki wrote:
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.
Do a traceroute to confirm what is happening here. I suspect what is really happening is an intranet request for the website only goes the firewall and that's all. What it seems you want is a nice squid solution here, but does your internal intranet traffic even touch squid unless it goes out for external internet?
The traceroute hits: client / intranet workstation browser firewall stalls because i don't let traceroute out The client browser hits: the squid proxy I am already using What is the "nice" solution and how is it implemented? Chris Boyd wrote:
hanasaki wrote:
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.
Do a traceroute to confirm what is happening here. I suspect what is really happening is an intranet request for the website only goes the firewall and that's all. What it seems you want is a nice squid solution here, but does your internal intranet traffic even touch squid unless it goes out for external internet?
I do something very similar to this, since none of our servers have externally available ip addresses and sit behind load balancers. However, the simplest method I found was to use DNS views to separate the internal and external requests. You mention that a DNS solution would be to expensive because of frequent changes, but if you wanted to automate the process, it would be pretty straightforward to setup dynamic updating. On 1/28/06, hanasaki <hanasaki@hanaden.com> 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.
Any tips? anyone doing this now and care to share their solutions? Any alternative approaches or ways to accomplish what is needed?
===============network Internal workstations (10.x.x.x) Internal webserver:7777 (10.x.x.x) Squid Proxy : 8080 ^ | intranet | =========|== firewall w/ NAT == internet | | V The Ugly World web browsers hit firewall on :80 ===============/network
== proxies and http I am using a squid proxy on host:proxyhttp:8080 that is not transparent (ie: needs the proxy manually configured in the web browsers). This is because transparent proxies don't work for ports other than 80, unless they are configured for each outgoing http port, which then always goes via squid and cannot be used for any other purpose. Ran into this when trying to hit a CPanel at a web hoster that was on some high numbered port. _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
-- Mortality sucks...
On 1/28/06, hanasaki <hanasaki@hanaden.com> wrote:
IE/Firefox. The DNS solution is high maintenance (hosts change quite often for business reasons). The proxy pac is, from what i understand
Why is that high maintenance? If you must change the IP address of a server, changing the address for your internal DNS server only takes a few moments more.
harder in the sense... wouldn't it be much easier to just add a new virtual host to the webserver and be able to hit it w/o having to update internal DNS (ie: only the external world dns). Monty J. Harder wrote:
On 1/28/06, *hanasaki* <hanasaki@hanaden.com <mailto:hanasaki@hanaden.com>> wrote:
IE/Firefox. The DNS solution is high maintenance (hosts change quite often for business reasons). The proxy pac is, from what i understand
Why is that high maintenance? If you must change the IP address of a server, changing the address for your internal DNS server only takes a few moments more.
On Sat, 28 Jan 2006 18:42:56 -0600 hanasaki <hanasaki@hanaden.com> wrote:
harder in the sense...
wouldn't it be much easier to just add a new virtual host to the webserver and be able to hit it w/o having to update internal DNS (ie: only the external world dns).
With something link BIND 9 which can do split DNS views of the outside world and inside world having "split DNS" literally means you have to change two lines of zone configs instead of one. So for example, if you're adding new-host.domain.com to both you have have to add it into db.domain.com-external and db.domain.com-internal and rndc reload the config. I'm still wondering why this is "hard". --------------------------------- Frank Wiles <frank@wiles.org> http://www.wiles.org ---------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 charles@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD3BdcLywbqEHdNFwRAuw0AKCtkBPaDS8ts8QhNMMeawqr1PiwBwCgsPa0 FaFrclc355brNtSIhiIE8FQ= =wXCm -----END PGP SIGNATURE-----
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 charles@steinkuehler.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hanasaki wrote:
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 :(
It's been a while since I set something like this up, and it was with a 2.2 kernel and ipchains, not iptables. tcpdump will be your friend...you need to make sure the packets are getting properly mangled by your firewall in both directions. If that's happening correctly, the client and web server should "just work". What's probably happening with a basic port-forward rule in place is the client sends a request to the FW. The FW modifies the destination IP:port and sends the request to the web-server. The web-server sees the actual source IP of your internal machine, and sends the reply directly to it instead of to the firewall (so it can get un-mangled). If the above assumption is correct, I think you need to add a MASQUERADE rule to the traffic from your local IP range as it leaves the firewall, giving it the IP address of your FW box instead of your client system. ...but all bets are off w/o TCP dumps of the input and output traffic from your firewall and/or web server and client systems. - -- Charles Steinkuehler charles@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD3L2OLywbqEHdNFwRAvEiAJwMoGKKjgNRUVmRIVXSBFSYu9wIRgCfUmnw afOqAldvhMBsmQKr8R10EGI= =tCbT -----END PGP SIGNATURE-----
participants (6)
-
Charles Steinkuehler -
Chris Boyd -
Frank Wiles -
hanasaki -
Monty J. Harder -
Rick Buford