Reverse proxy may work, although it does add an layer to the complexity that may not be necessary unless the otrs server is expected to be hammered by incoming customer web requests or DDOS. http://forums.iis.net/p/1158552/1907735.aspx discusses the topic, too, which, yes, snickers at the apparent "security" of apache, but brings up the point of complexity for what practical purpose? Performance, or just getting the access to the website, or security because ...
 
After reading the wikipedia article, you'll probably come to the same conclusion. Your server probably is good enough to handle the load that your clients are going to throw at it, and yet if it wouldn't, you'd certainly know that it's time to use a reverse proxy to load balance, etc.
 
Nils' solution is the right one for long term. Your needs may vary.


 
On Fri, Dec 10, 2010 at 2:39 PM, Nils Leideck <nils.leideck@leidex.net> wrote:
Dear both,

my recommendation to this wouldn’t be a port forwarding.
Instead I recommend to use a reverse proxy for the access provided to customers.

Read this first: http://en.wikipedia.org/wiki/Reverse_proxy

Bundled with a virtual IP address we setup very performant OTRS services.

Cheers, Nils


On 10.12.2010, at 14:21, Gerald Young wrote:

You don't have to fully DMZ it. Just port-forward the web port (80 or 8080->80 or something that makes sense). Note that if you use any port besides 80, you will likely want to change the signature/footer of outbound emails to reflect the port you're opening. You can add an additional Listen directive to the apache config to reflect the new port (requires restart of apache). 

"For example, to make the server accept connections on both port 80 and port 8000, use:
   Listen 80 
   Listen 8000"
You may also need to make specific changes to the config of otrs. Having otrs listen on both ports makes it really easy for you transition so that your internal users won't notice a change in how they connect. However, if you're using an internal name for your otrs server -- usually a LAN will reference by a single servername, not a FQDN -- you'll want to make sure that your otrs server is accessible internally by the FQDN and that the otrs config reflects that FQDN. In my case, I created a CNAME both on my AD DNS server and the external domain dns server: http://support.mydomain.tld would resolve to my external IP address for the world and my internal IP address for my LAN.

On Fri, Dec 10, 2010 at 3:10 AM, Lars Jørgensen <ITLJ@gyldendal.dk> wrote:

Hi,

 

If you need to give external customers access to the customer frontend, the first solution that comes to mind is to place a server with the customer frontend in the DMZ and let it talk to the internal database. Is this the best practice and do any configuration guide exist for this?

 
 

Lars


---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

— 
Nils Leideck
Senior Consultant

http://webint.cryptonode.de / a Fractal project


---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs