What topology/strategy for providing external web access to multiple internal services?

Question

I have a growing demand for access to internal LAN services from the internet. Up until recently the only service provided via the web was access to email(Exchange-OWA). Now we have a vendor supplied web app that provides access to our main records system. I use a Sonicwall NSA 2400 at my edge with a single public IP address on the WAN interface. The primary LAN interface connects to our switch core. The secondary LAN interface connects to a simple 24 port switch and acts as a DMZ, though it hasn't been used(much) until now. All my servers are virtualized(VMware ESXi) and have the possibility to connect to either the primary LAN or the DMZ. Access to OWA was facilitated in the sonicwall by a NAT policy that allowed the port 443 traffic to be redirected to our mail server internally.

With the new webapp I attempted to set up a new NAT policy that used a non-standard port number to carry https traffic to the new server, rather than having the default 443 traffic get forwarded to the mail server. The vendor configured the server accordingly. What we found(obviously now) was that a long url with the non-standard port number has to be used to avoid a forwarding conflict with the mail server. So we started thinking about how to do redirection. Well, that is what brings me to the question of what is the best overall strategy for allowing different incoming requests to our public ip to be routed securely and reliably to the correct inside server/services. Should I continue relying solely on my firewall nat and port forwarding? Is a better plan to build a portal of some kind? We do anticipate have even more servers/services that need access from the internet using web browsers and other applications. Any good ideas?

Answer 1

There might be a couple of solutions for you:

1. Buy more public IP from your ISP. This way, you can dedicate each public IP to each of your services provide web access.

2. Having all 443 traffic forwarded to a proxy. My working place uses nginx so I would suggest that. Offload the SSL cert at the proxy, read the content of the header to determine the service and forward that traffic to the corresponding server. An F5 LTM module is also perfect for the job. But it is a bit costly.

Answer 2

Do you have three router interfaces? (or can you expand and add a third?)

Then you can have the tiny LAN outside your router as-is. (e.g. with public mail server NAT'd inward to the real server.

Add a new network of public numbers on the third interface. Firewall to just the ports you need 80/443 so the public can go directly to that third LAN.

Then you can add rules to allow the web systems in the third LAN (really a DMZ) to cross over to your true internal LAN through the router.

That way you can always change f/w rules to allow whatever you want to that third LAN (the new DMZ). Without exposing what's over on the true internal LAN.

Answer 3

There's a fair chance this answer won't be applicable in your situation, but I feel I have to say it anyway:

You can implement IPv6 and obtain more than enough addresses so every service can run on its own address on the ports you want them to run on.

Of course, this requires every visitor to have a working IPv6 connection so it will probably not be a real option at this point in time, but it certainly is one of the best ways to solve NAT problem.