We'd love to hear about it! Click here to go to the product suggestion community
I have an internal website that my external workers have been accessing via the portal (VPN > Clientless Access). As of yesterday my remote workers can't access pages correctly. I've restarted Sophos XG and the Server. I've noticed in the Log Viewer the following...
Log Comp: SSL VPN
Username: My Username
Message: Use "My Username" was allowed access of the HTTP resource http://images/logo.jpg
Is this correct? Does the IP address of the internal server need to be prefixed? Eg. http://10.12.44.10/images/logo.jpg
The portal website sometimes displays the page poorly or not at all and I can see the following source code...
The URL for this blank white page is = https://myexternalip/userportal/CRSSL/http/ClientLogin.aspx
The source code for that page is...
"<!--#set var="TITLE" value="SSLVPN User Portal Error:"
--><!--#include virtual="include/top.html" -->
<!--#if expr="$REDIRECT_ERROR_NOTES" --> <!--#include virtual="include/spacer.html" --> <!--#echo encoding="none" var="REDIRECT_ERROR_NOTES" --> <!--#endif -->"
Please can you help or throw any suggestions my way? Many thanks
EDIT: The first page kind of works. There's no neat formatting or styling. However I can see text. The URL displays the following...
When I click any link, a white page appears and the URL changes to https://externalip/userportal/CRSSL/pagename.aspx
It's not prefixing the URL and therefore nothing is displaying correctly. Please can others check this to see if it's just me :)
No getting exactly the same thing, added an internal http page, it opens, seems to load the index page as visible on the top bar, but blank page, with following source:
In reply to ChrisWhiting:
Logs say "user denied access of the HTTP resource"
can you share some screenshot? Error, bookmark and VPN Clientless configuration'
In reply to lferrara:
Good Morning, Thanks for replying back to me.
Here is a very basic IIS landing page screenshot. If this worked, I have a feeling I'd be able to fix the actual internal website.
In reply to PhilHalford1:
Have you find a solution to this problem. I´m about to publish an internal website using the user portal but get the same error.
We got the same error too on 16.01.2.
Is there a way to fix the path translate error?
The issue is associated to NC-10370. We are still waiting for the final fix and the next ETA for the fix will be with 16.05 MR2.
In reply to sachingurung:
Do you know when will Sophos release 16.05 MR2?
I have already posted this on the 14th of February, there are at least 3 known issue with HTTP via clientless:
Sophos just doesn't care otherwise before releasing a new update they would just test with any web page and see the issue by them self ...
In reply to MassimoForni:
I partially agree with you. More testing should be performed internally before they release a new version but issues occur.
Internally they have priorities that must respect. Of course a bug on ips module or waf takes precedence than clientless.
We hope to get the mr2 soon and that in Sophos they take more attention!
Ok about priorities, but these bugs means they just didn't even tried a single html page with ANY js/css/image
That's it... And these known issues are around since 15.1, I'm not talking 2-3 weeks...
Even worst is the support which took 1 week only to connect via logmein to my PC because they want to see the issue (and I must add they don't want to spend 1 minute to replicate it on their labs) and after I recreated from ground up the whole issue the support told me that clientless for http(s) "apparently" does not work and to just use a SSL VPN...
Is anyone else still having issues with this BUG using Clientless VPN and HTML issues?
If not, that is awesome, please share what you did!!
In reply to Jeremy Cullen:
The bug didn't fix totally on 16.05.5 MR5, and Sophos doesn't seems to fix the feature anymore...
So we give up the feature, and don't suggest customer to use it.
In reply to ShunzeLee:
Can someone open a ticket with Support?
sachingurung , Aditya Patel can you investigate this issue? It seems not completely fixed on MR2.
I have the case #6997681 opened since the 7th of February...