Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 8091 views
  • Users 0 members are here
Options
Suggested

XG port 8090 (IPS error messages) not accessible

Dom Nik

Hi Sophos Team,

I did an upgrade of a software appliance and found out, that the generated error message which will be displayed in the browser are not accessible by the clients.

The messages are published through port 8090. You can replicate the issue, e.g. by trying to download EICAR test virus, which triggers the IPS (web malware scanning enabled).

 

Is this a bug or is this a new behavior in v18, which means I have to create a FW rule for this?

Until v17.5 these things were managed automatically by "Administration --> Device Access".

 

My second question on this topic is if there are any details what the "Do not apply this migrated rule to system-destined traffic."-option in the FW rules exactly means amd how we should deal with this.

 

Thanks and Best Regards

Dom

Parents
  • +1

    There is a mix of both.

    The new stream based engine has to deal differently with malware scanning. Because XG does not act as a Proxy anymore, it cannot give a direct block page. It will redirect you. Thats the wanted behavior. But the redirect to 8090 needs to work. 

    It will redirect you to the captive portal. Can you check, if the captive portal in Device Access is enabled for this zone? (Port 8090 is captive Portal). 

     

     

    The second question: Please open a new Thread for this to keep one question per Thread. 

    __________________________________________________________________________________________________________________

Reply
  • +1

    There is a mix of both.

    The new stream based engine has to deal differently with malware scanning. Because XG does not act as a Proxy anymore, it cannot give a direct block page. It will redirect you. Thats the wanted behavior. But the redirect to 8090 needs to work. 

    It will redirect you to the captive portal. Can you check, if the captive portal in Device Access is enabled for this zone? (Port 8090 is captive Portal). 

     

     

    The second question: Please open a new Thread for this to keep one question per Thread. 

    __________________________________________________________________________________________________________________

Children
  • 0 in reply to LuCar Toni

    Hi LuCar Toni,

    thanks for your reply. This is the solution!

    Captive Portal needs to be active, when using the new DPI engine.

     

    -------

    Important, as there are other threads that might point to this topic:

    This also seems to solve problems with sporadic rendering problems of websites and very long loading times of websites packed with loads of ads and the behavior that browsing with the new DPI engine felt slower than with the old proxy.

    The reason is that sources of a blocked web category (e.g. advertisements) are redirected to port 8090 which cannot be accessed. The browser then waits "forever" to get all these sources in the background and sometimes doesn't even start to display the page at all...

  • 0 in reply to LuCar Toni

    Hello Lucar,

    I would recommend a warning symbol somewhere reasonable to flag to users not using the enforced proxy that the Captive Portal has to be enabled to present blocked messages.

     would this be something reasonable to add to the list to prevent user error?

    I have some customers who disable the Captive Portal.

    Emile

  • 0 in reply to Emile Belcourt

    It does seem like it's the cause of some confusion. There are a number of key end-user interactions that are driven through port 8090 along with the Captive Portal. I agree it would make sense for us to perhaps change the labelling of that option in the Device Access page to reflect that it has other effects as well.

    Would customers still need another way to disable the captive portal specifically? Or do they just disable it as a matter of hygiene because they believe the port/services to be unused?

    Regards

    Rich

  • 0 in reply to RichBaldry

    Hi Rich,

    I disabled everything unused simply because its a security / hardening practice to minimize the attack surface - and of course for performance / resource usage reasons. :)

    (I‘m just a home user)

    Thanks and Best Regards

    Dom

  • 0 in reply to RichBaldry

    Hi Richard,

    Personally, I'd like to see a separation of Web Proxy resources and captive portal and the resources used by the XStream redirect methods.

    I'll need to re-test, but i'm confident with the Captive Portal being unavailable, you can still get blocked/warn messages and proceed on current GA versions of the XG.

    Also, as noted by Dom, it's good security practice to disable what is not used. Lacing it into the Captive Portal opens up a question not worth answering.

    I hope that helps!

    Emile

  • +1 in reply to Emile Belcourt

    Hi Emile,

    On the current GA versions of XG, the block/warn messages are all delivered as responses to the blocked requests. This is possible because of the proxy architecture. It only has to use services on port 8090 when there are follow-up actions - such as when you click 'proceed' after a warning, or when you download a file that needs a Sandstorm scan.

    In version 18, with the DPI engine, we are limited as to how much data we can inject into a filtered stream. This means we have to respond to blocked requests with a small redirect response, which causes the browser to then go to the port 8090 URL on the firewall to retrieve the full block page content.

    So the impact on version 18 of blocking access to port 8090 services, by disabling access to Captive Portal, is definitely going to be more visible than with v17.x.

    Cheers

    Rich

Unfiltered HTML