We're experiencing an issue on our Corpoate network, connecting to an external Supplier. The external Supplier use an AnyConnect device with a frontend, after logging in, they then appear to use the AnyConnect RDP Port Forwading functionality (sorry, I don't know the official Cisco product name for this "AnyConnect SSL Clientless VPN"?).
Access to this Supplier Site works fine from a typical ADSL Network, and other locations - but not on our Corporate network. This access appears to do some "magic" on the PC, which causes the RDP Traffic destined for 172.1.2.3 to be Port Forwarded through to the Supplier's ASA, which then translates the flow to the Actual 10.205.x.x IP address of the RDP Server in their estate.
On our Corporate estate, we make use of Websense proxies - explicitly pointed to by a WPAD/PAC file - and importantly, the WPAD/PAC also proxies all DNS requests to external websites. To reiterate, our Corporate internal DNS servers do not resolve external DNS entries - Internet access works fine to external websites, it is just that the original DNS request is also proxied via the Websense proxy, which then makes the DNS lookup (and HTTP/HTTPS proxying) on the client's behalf.
When I've Wiresharked this flow, it appears that subsequent DNS lookups - once the AnyConnect session is created - to the Supplier's website fail. I assume what the SSL VPN Port Forwarding Java/ActiveX Client does is to hijack these DNS lookups, and redirect them to 127.1.2.3 - to force them via the Port Forwarding "Tunnel"?
If so, can you please advise what client-side (or Supplier server-side) changes we need to make, given that our internal DNS servers cannot be made to resolve external domain names (those outside or Corporate/Company internal hostnames)? Or is this a known bug?
