cancel
Showing results for 
Search instead for 
Did you mean: 

Passthough Proxy IVE Hostname with two User Realms

SOLVED
Highlighted
Super Contributor

Re: Passthough Proxy IVE Hostname with two User Realms

Hi,

 

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.

 

Regards,

Jay

Highlighted
Occasional Contributor

Re: Passthough Proxy IVE Hostname with two User Realms

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 1.2.3.4

Sign In #2 resolves to 1.2.3.5

 

 

Highlighted
Contributor

Re: Passthough Proxy IVE Hostname with two User Realms

As far as I'm aware we're using different sign-in urls on the same IP to different realms for authentication purposes without any problems. PTP policies work fine.

 

https://domain.com/url1 keyfob auth

https://domain.com/url2 sms auth

 

JH

Highlighted
Super Contributor

Re: Passthough Proxy IVE Hostname with two User Realms

Yes, that would be ideal as sign in URL's resolve to different IP's

 

Sign In #1 resolves to 1.2.3.4(external IP)

Sign In #2 resolves to 1.2.3.5(External virtual port IP)

 

Regards,

Jay

 

Highlighted
Occasional Contributor

Re: Passthough Proxy IVE Hostname with two User Realms

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.

View solution in original post