Apparently tomcat doesn't run as root for security reasons, which explains why it can't open ports < 1024 in Linux. (This was new to me because we always frontend with Apache.) Anyhow, now I need to figure out how to get an iptables config that redirects 443 -> 41443 loaded onto this system without being able to directly run iptables config commands and without breaking what is already in place. Going to take some more research. Not sure why Symantec doesn't have an iptables redirection pre-installed; what customer would want to advertise a non-standard port to their user base? Will post updates for anyone interested...

Successfully gained root, but looks like iptable modules aren't part of the kernel. This is going to be even tougher than I tought...

If memory servs you can use VMWARE Server to NAT the traffic from 443 to 41443 which should solve your problem.

John-- Good suggestion, hadn't thought of using VMware for the port redirect. However, this is on VMware ESX Server, not VMware Server, so networking mirrors our regular topology, no NATing involved. I'll look into it further to see what my options are there. I'd also have to see if that breaks other things that use 443, such as Brightmail updates. Thanks!

PS-- Backup plan is to redirect from another web server. But I'd really prefer not to.

As I thought, that's not something you can do with ESX Server. ESX Server doesn't run atop an OS like VMware Server or Workstation do, so it doesn't ship with NAT functionality -- doesn't need it. Next step is to look into redirecting with the firewall...

Doni, 

Thanks for your thoughts.  You are partially correct, the VMware documentation is not clear on how to do this however it is very possible.

From the VMware admin Guide:

"Advanced Networking – Covers advanced networking tasks such as setting up
MAC addresses, editing virtual switches and ports, and DNS routing. In addition,
it provides tips on making your network configuration more efficient."

VMware Assumes that a network admin is proficient enough to understand and configure a switch to accomplish what your trying to do.   The do provide some documentation on configuration HERE

Thanks,

John

Thanks, but those advanced networking topics have nothing to do with NAT. I am quite familiar with them. The ports it is referring to are not TCP ports, they are vSwitch ports (to serve vNICs). vSwitch ports are to vSwitches as physical switch ports are to physical switches. I am not aware of any way to NAT in ESX without setting up a router. And this includes command line options (esxcfg-vswitch). Was a good thought, though.

I setup my PIX to redirect... then realized that doesn't help me with internal clients. Whoops. ;) So I'll need to setup a dedicated router for this or a web server redirect, unless Symantec can explain how to use port 443 natively (in the other thread).

Lloyd @ Symantec escalated the question for me and got a definitive response that it is indeed not possible to use 443 (to not have to specify 41443), even with the latest v7.7. As my own research above has shown, one would need to be a root user and do some heavy Linux reconfig, if possible it all, which is of course not supported.

So it looks like redirecting from another web server is my only option, which is unfortunately an unnecessarily burdensome requirement. Any end-user-facing web server should use standard port 443 for SSL. If other Symantec services conflict with port 443, change those background service ports, not the end-user-facing URL. From a customer service standpoint, it's hard enough to get users to remember the 's' in https (since Symantec doesn't support an internal redirect for that either), let alone a non-standard port number.

I hope Symantec will add this internal capability in the next release, since requiring a separate web server defeats the purpose of an appliance model. Thanks

Doni,

     That's too bad Symantec Says there is no way to do it.  I agree that they should add that functionality into the next version of the software.

I'll be submitting a formal request to Symantec shortly. Thanks again to Lloyd @ Symantec who was exceptionally attentive in discussing this issue. But at this point its a development request, with a work around needed for the time being.

Holy {please keep it courteous} tech support, Batman -- it worked! Thanks!!! Where did you find this info? And why in the heck did I just spend days on my own AND WITH SYMANTEC SUPPORT to have them tell me there was no way to do this? Doesn't Symantec know their own products??? Apparently not. This is great news, but makes me even more likely to look to other vendors next budget season. Inexcusable to be lead on a wild goose chase. I don't have time for this. Security vendors are supposed to make my life easier, not harder.

As I said in the related post,  it's a bit unfair to slam support, not really their fault here.  We dropped the ball by missing it out of not only the shipped documentation but also the internal support training.  We've remedied that now so that everyone here *should* know.

Apologies.

--ian