Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 28 subscribers
  • Views 14569 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

WebRTC / Google Hangouts Blocked

Marc Herndon

Does anyone know if there's a way to get WebRTC traffic (used by Google Hangouts) to work through an XG firewall?

I just purchased two IP intercom units from www.nucleuslife.com, got them set up on my network, and confirmed that have Internet/WAN connectivity (I can ask Alexa to do things and get responses).  The problem is they cannot see each other on my LAN.  Each knows the other exists through my Nucleus account, but they show the other as "offline", thus cannot place calls.  I've gone through all my firewall, IPS, etc. logs and show no signs of any traffic being blocked or dropped.  I temporarily created new firewall rules allowing 'any' hosts and services from LAN to LAN, LAN to WAN and even WAN to LAN but it still didn't work.

I contacted Nucleus support and they said something in my network is blocking the WebRTC protocol.  Two direct quotes from them below:

  • "They should be able to contact each other without using the Internet. Are you able to use Google Hangouts on your network? We use the same protocol. Both TCP and UDP ports need to be available, but not any specific ones."
  • "As neither device is seen by the mobile app, it sounds like WebRTC is being blocked by some configuration."

With that information I decided to try placing a hangouts call from my PC on the LAN to my wife's cell phone.  It sat there saying "connecting..." but her phone never rang, nothing came through, and again, no blocked traffic in the various logs.  Googling for Sophos and Hangouts led me to these two links:

The second link is not helpful, other than to suggest that XG blocking Google Hangouts is a known issue?  The first link is specific to UTM, but suggests an external MTU-related solution.  I will look into that deeper this evening after work, but I don't suspect that will be my answer.  My devices are trying to talk LAN-to-LAN and per the support tech they should not need to go out to the WAN to connect.  As such, I don't think a WAN MTU setting could be the culprit?

Does anyone have any thoughts or suggestions?  Can anyone confirm that Google Hangouts is or is not working through their XG Firewall?

Thanks,
Marc



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

    Just a quick followup regarding additional troubleshooting last night and this morning.  I wanted to narrow down whether my switch or router (Sophos) was causing the blockage.  As such, I took a spare port on my XG (port 3) and added it to the LAN zone, and created a DHCP server for it.  I then connected a dumb unmanaged switch to that port, and the two intercom units to that switch.  The idea was to remove my current managed switch from the equation, removing VLANs and other complexities as well, dumbing down to just a basic physical network with nothing on it but the two intercoms.

    On the Sophos, I have the following two rules at the top of my firewall:

    In this configuration the two intercoms got an IP and had Internet/Alexa access, but still cannot see or call each other.  According to the manufacturer's comments above, this is due to the WebRTC protocol being blocked.  The only place it can be being blocked in this simple configuration is the XG software, but I still can't see where. 

    There is no IPS, WAF, etc. policy being applied by my firewall rules, and the rules are full-open for any host and service on the LAN.  There is still nothing in any logs indicating dropped communication.  All DoS prevention under IPS is turned off, and my ATP protection is enabled but set to "log only".

    One last test that only further confuses the issue is that in this configuration with the intercoms not seeing each other, I *was* able to make a hangouts call from my desktop PC (on VLAN 1) to my cell-phone on WiFi (VLAN 40).  Voice and video from the phone were received by the PC, and the PC has no mic or camera so I couldn't tell if voice and video could make it back, but I have to assume it would have.  So if Google Hangouts works and the intercoms do not I might be chasing a wild goose...?  I will contact the intercom company again today and see if they have any additional suggestions.  And of course, suggestions from the forums here are most appreciated as well.

  • 0 in reply to Marc Herndon

    Marc Herndon said:

    I *was* able to make a hangouts call from my desktop PC (on VLAN 1) to my cell-phone on WiFi (VLAN 40).  Voice and video from the phone were received by the PC ... So if Google Hangouts works and the intercoms do not I might be chasing a wild goose...?

    There seems to be no way to edit my previous post, so I'll reply to myself instead.  I did some further testing with Hangouts and found that *only* video calls work.  If I try to initiate an audio call to either my phone or my wife's phone it hangs and times out, without the phone ever ringing.  When I do a video call, I get the previously described behavior, I'm able to accept the call and have full audio & video.

    I have no idea if that's relevant, possibly Hangouts uses a different protocol for audio calls and video calls, but the audio call capability is acting exactly like the Nucleus intercoms, while the video call capability seems to work.  Maybe that will be a helpful test for someone who's able to look into this a little deeper?

    Thanks again,

    Marc

  • +1 in reply to Marc Herndon

    Can you put in a high level firewall rule that is fairly open.  Make sure that under Malware Scanning, neither HTTP or HTTPS is scanned and the Web Policy and Application Policy is None.

    Now using the command line "console" type

    system application_classification microapp-discovery off

     

    See if that works.  If it does, then return to your normal firewall rules and see if it continues to work. 

    If it does, then this is a known issue and is scheduled to be fixed in an upcoming 16.05 maintenance release.

     

    If the above does not work, then it is not the http proxy and out of my expertise.

  • 0 in reply to Michael Dunn

    Thank you very much!  As soon as I typed that command at the console the intercoms linked right up with each other, and I was able to make calls between them.  I'm glad this ended up being a known issue that you have plans to resolve already.  For future reference, say after applying the next firmware version, should I go back to the console and turn microapp-discovery back on, or is it OK to just leave it off and never think about it again?

    Thanks again!!
    Marc

  • +1 in reply to Marc Herndon

    With this command, some forms of application control will not work.  If you do not have any application policy, this won't make a difference to you.

    However my recommendation is that once the fix is done in the firmware, everyone who has turned it off in console should turn it back on again.  You don't want to be stuck 3 years from now cursing why something doesn't work because you disabled it and forgot about it.  :)

     

    Note: I cannot say at this time which firmware update will have this.  It may not be the next one.  But I can say it will be before v17.

  • 0 in reply to Michael Dunn

    Thank you again.  I will keep my eye on upcoming release notes and make sure to change the setting back once there's an indication of the problem being fixed. 

    I wasn't using any application filters previously, but just this evening I created one to keep my daughter's tablet from accessing Youtube.  So far that one seems to be working as expected, so I don't think I'm going to have any trouble leaving the microapp setting off temporarily.

  • 0 in reply to Michael Dunn

    I have to correct myself.

     

    If you ran:
    system application_classification microapp-discovery off

    Then after the fix is in place you do not need to do anything.  The normal behavior will be with it off and all systems that upgrade will turn it off.

     

    Some of the early information on this workaround also recommended doing this (which turns out to be unnecessary):
    system application_classification off

    If you did this you must manually set it back on.

     

Reply
  • 0 in reply to Michael Dunn

    I have to correct myself.

     

    If you ran:
    system application_classification microapp-discovery off

    Then after the fix is in place you do not need to do anything.  The normal behavior will be with it off and all systems that upgrade will turn it off.

     

    Some of the early information on this workaround also recommended doing this (which turns out to be unnecessary):
    system application_classification off

    If you did this you must manually set it back on.

     

Children
No Data