Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 29 subscribers
  • Views 973 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos XG 18.05 is blocking clickmeeting

newxguser

Hello there....

I run XG 310 with 18.05 firmware in proxy mode.

I can't find the reason for Sophos XG blocking communication to *.clickmeeting.com. Adding web exception doesn't work:

I've also created a category called 'exceptions' with clickmeeting.com domain and added it as allowed to the webfilter profile. Despite , a user can only enter *.clickmeeting.com but they cannot enter the room.  

Searching the logs showed some packets are going  through and some aren't in firewall section of the logs.

Destination IP is the address of clickmeeting server.

Communication was possible only when I temporarily switched off all security features , allowed all outgoing ports for that local IP -10.10.0.103

What is strange for me is that communicaton initially is established and then we end up with 'Could not associate packet to any connection'  on port 443 which is always open.

Any ideas?



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    what does the Application and web filters in  Logviewer show?

    Ian

  • 0 in reply to rfcat_vk

    Hi,

    Application control is set to 'allow all' so it shows nothing in logs. Webfilter logs prove traffic is allowed- category "Information technology' and when I added my category exception it changed  for that.

  • 0 in reply to newxguser

    Please review the ssl/tls log.

    ian

  • 0 in reply to rfcat_vk

    SSL\TLS inspection is disabled - I use web proxy only. 

  • +1 in reply to newxguser

    Hello newxguser,

    Adding to what rfcat mentioned, I would recommend you to put the awarrenhttp service in debug mode 

    # service awarrenhttp:debug -ds nosync

    Then you can follow the awarrenhttp_access.log to see what is being blocked.

    # cd /log

    # tail -f awarrenhttp_access.log | grep "x.x.x.x" (Where x.x.x.x is the IP of the computer trying to do the connection.)

    Regards,

  • +1 in reply to emmosophos

    the traffic is out of order - there are some packets which are not expected by the XG. probably at some point, the reply packets from the internet host are not reaching the LAN computer. Especially because your LAN computer is sending from different source ports.

    Please filter the traffic not for dst or src IP but only for the two IPs (free text search) and post an othewr screenshot, also do a packetc capture on GUI:

    replace 51.51.51.51 with the actual IP to which the computer is communicating during the test.

    scroll to the right so status, reason and connection ID are visible

    and post the results

  • 0 in reply to LHerzog

    Thank you for Your replies. For the time being I can only analyze past traffic, because  they use clickmeeting from time to time. I'm going to set free clickmeeting account to simulate the connection and gather information You asked for. I'll post it as soon as I get it.

    ------------------

    I have conducted some test mentioned above - suprisingly communication was ok with web exception enabled. 

    At least I've learnt new diagnostic tools. Thank You all for Your time.

    Regards,

Reply
  • 0 in reply to LHerzog

    Thank you for Your replies. For the time being I can only analyze past traffic, because  they use clickmeeting from time to time. I'm going to set free clickmeeting account to simulate the connection and gather information You asked for. I'll post it as soon as I get it.

    ------------------

    I have conducted some test mentioned above - suprisingly communication was ok with web exception enabled. 

    At least I've learnt new diagnostic tools. Thank You all for Your time.

    Regards,

Children
No Data