Thread Info
  • State Not Answered
  • Replies 2 replies
  • Subscribers 5 subscribers
  • Views 685 views
  • Users 0 members are here
Options
Suggested

passthrough.fw-notify.net authentication returns "Invalid Request" using return token

garth1138

Just upgraded my SG230 Firewall to Firmware 9.720-5.

Since then, the usual passthrough.fw-notify URL as shown below:

(*****)://passthrough.fw-notify(dot)net/static/auth_transparent.html?return=(****)://www.google(dot)com/

Note: the above (*****) is "https" and (dot) is a period. Changed to avoid SPAM filtering on this forum

is returning an error message: "Invalid Request, check URL."

This always, in the past, simply authenticated the user and dumped them onto the Google home screen based on the "return" token in the URL. It appears that the users are being authenticated but the return URL token is not being parsed? This is making users think they are not authenticated.

This is what I find in the webfilter log:

Line  491: 	Line 51379: 2024:10:21-07:37:34 astaro httpproxy[5974]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="10.241.1.157" dstip="" user="" group="" ad_domain="" statuscode="404" cached="0" profile="REF_uUXkJCrrpe (Main User-Based_Restrictions)" filteraction=" ()" size="2469" request="0x7fa54699ec00" url="(*****)://passthrough.fw-notify(dot)net/favicon.ico" referer="(*****)://passthrough.fw-notify(dot)net/static/auth_transparent.html?return=(*****)://www.google(dot)com/" error="File not found" authtime="0" dnstime="0" aptptime="0" cattime="0" avscantime="0" fullreqtime="1073277" device="0" auth="4" ua="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36" exceptions=""

Again Note: the above (*****) is "https" and (dot) is a period. Changed to avoid SPAM filtering on this forum

Any ideas what is going on? No other changes made to the Firewall, just the FW update.

Thanks

  • 0

    Addendum: looking more closely at that log entry, it is simply a complaint about the favicon not being found. Not sure that would cause the issue though

  • 0

    So I have been working with support on this. They seemed to think it was a glich in the UTM and needed a reboot. No such luck.

    The UTM Appliance was restarted and there is no change in the results.

    Just so you know, as was pointed out on the support call, when a user clicks a link that requires authentication through passthrough.fw-notify, the return token shows a url that has added tokens that are not in the initial link

    For example: If, while not authenticated to the firewall, I click a bookmark that points to (*****)//www.facebook(dot)com (which is not excepted from authentication in the webFilter) the URL for the passthrough.fw-notify authentication request that comes back is such:
    (****)//passthrough.fw-notify(dot)net/static/auth_transparent.html?return=(*****)//www.facebook(dot)com/&ts=1730300930&cs=cfd803bdee1820650e34739a62cc30131d1a3488

    You will please note the " ts=1730300930&cs=cfd803bdee1820650e34739a62cc30131d1a3488 " tokens that have been added to the end of the "return=" part of the URL. I have no idea what they are used for or how they are generated. They were not part of the original URL request.
    When I authenticate successfully, the page returned is the normal page expected from (*****)//www.facebook(dot)com/
    and the URL in the browser address for facebook does not reflect those added tokens.

    However, if I manually supply this URL to a browser: (*****)//passthrough.fw-notify(dot)net/static/auth_transparent.html?return=(*****)//www.google(dot)com/
    without the "ts=_______ & cs=__________" tokens on the end, it will authenticate but will give the error, "Invalid Request, check URL"

    So I believe the issue is that the passthrough.fw-notify(dot)net return token is now expecting those "ts=_______ & cs=__________" tokens on the end.
    Possibly the developers could shed some light on this because prior to the latest firmware update, this was not the case.

    (****) = https: in above to pass spam filters

Unfiltered HTML