2 sign in URL's resolving same IP is not recommended, can you create a virtual port and map the secind sign in URL to the virtual port ip.
Probably could, but wouldn't be ideal from a user experience point of view (customers acting dumb and not entering a port number etc).
How about aliasing a 2nd IP instead, would that solve the problem?
Sign In #1 resolves to 22.214.171.124
Sign In #2 resolves to 126.96.36.199
Yes, that would be ideal as sign in URL's resolve to different IP's
Sign In #1 resolves to 188.8.131.52(external IP)
Sign In #2 resolves to 184.108.40.206(External virtual port IP)
Due to it being a production system and change control procedures, it would have taken longer to try the different IP approach, so I tried the suggestion itdept listed - using a different path. It works.
This got me thinking about why the SSL VPN authenication may break on a different domain, then it hit me - Cookies. I'm betting that as with most cookie-based systems the SSL VPN sets the domain that the cookie can be read on, so if its set to 'www.company.com' then browsers will only use it on that hostname, whereas setting it to '.company.com' would allow subdomains to use it as well. So I think the SSL VPN is using the full domain, and when the client tries to access the different subdomain (secure.company.com) the browser doesn't send the cookie and therefore the SSL VPN believes you're not authenticated.
I haven't yet been able to find a setting in the SSL VPN that would allow you to change the cookie domain, but if you could and can change it to the base domain, I bet it would work.