Very strange SSL VPN issue. Not sure it if's a bug or by design.
Cisco ASA has:
SSL VPN has:
When a user is on the internet, FQDN works fine.
When a user is on internal network FQDN works fine.
When a user is on the VPN, no traffic passes to virtual hostname IP / FQDN.
Should this be possible for a Network Connected tunnel client to reach the Virtual Port / Sign in Page? if not, is there a way to make the web server work behind the SSL VPN when a user has a tunnel up (Network Connect) or do we need to move it out from behind the SSL VPN?
Unless I've misunderstood it sounds like you've given the VPN box that same IP address as your web server.
The NAT and external virtual port does not need resolve to the true internal IP. The virtual hostname configuration handles the transition to the internal server. The NAT just needs to direct your public IP to the VPN box.
If I understand correctly you effectively want to route from the internal interface or the VPN box back round to the external. Not sure if the VPN boxes will like this but if it does the issue could be on the interconnect between the internal network and the external DMZ. It could be a firewall intrusion prevention mechnism is dropping the traffic due to the unusual routing path even though you have rules in place to allow the traffic. We sometimes get this when VPN users are trying to connect to Site to Site VPN locations.
Yeah, I did not explain it well. The VPN has the NAT IP / external FQDN that the Cisco is pointing to. Then it points to the internal IP / FQDN of the web server. What we are trying to accomplish is have internal clients hit the external FQDN which works, but when they are on aVPN tunnel it does not.