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.
  • 0

    HI Marc, 

    We have not seen such issue , Could you let us know the Ports used for communication. Also allow us some time to simulate and also post any configuration used in application filter and Web filter used on the firewall rule 

  • 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

    For completeness, I wanted to mention that I've actually tested 4 different switches now, connected to the XG firewall.  The original managed switch was a TP-LINK TL-SG2424P.  I've since tried three unmanaged switches, a Dell PowerConnect 2608, a DLink DGS-2208, and a TrendNet TE100-S5.  The latter one was a junk 10/100 switch I had lying around, just seeing if it made any difference vs. the other three being Gigabit.

    So I feel comfortable saying at this point that the switches are not blocking communication.  Later today when I can bring the network down I plan to swap out the XG firewall for an off the shelf Netgear router to see if that allows the intercoms to communicate.  That should conclusively show whether the problem lies in the XG or not.  And hopefully by then I'll have more feedback from Nucleus as well.

  • 0 in reply to Aditya Patel

    OK final update, I swapped a Netgear R7000 in place of the XG firewall this afternoon and with the intercoms plugged into the Netgear directly, or with them plugged into a switch which was plugged into the Netgear, they came right online and were able to call each other.  So that pretty much ruled out that the problem could be anything but the XG firewall.

    I then decided since the network was already down I might as well go all out, and I reset the XG firewall to factory defaults.  When it came back up I stepped through the wizard, configured for Gateway mode, and allowed it to create the #Default_Network_Policy rule, with all LAN to WAN services allowed, no scanning, IPS, or web policy applied.  I then plugged the switch into the LAN port of the XG (the same switch that had just worked w/ the R7000), and the two intercoms into the switch.  As before, they obtained DHCP and had full Internet connectivity, but could not see or call each other.  As a final effort I created one more firewall rule allowing all LAN-to-LAN with no scanning, IPS or web poilicies, but as expected it made no difference.

    So in summary, through all of my troubleshooting, hardware swapping, and config resetting, I've determined beyond any possible doubt that the XG firewall is the culprit in blocking the intercoms from communicating.  I've also shown that it wasn't my original XG configuration causing the blockage, as a factory fresh unit with nothing but an "allow all" rule still blocks the intercoms.  It doesn't appear to be a firewall rule or related WAF/IPS/etc. policy that's doing the blocking, it has to be something lower level than that, likely something not accessible from the GUI.  I'm going to contact Nucleus again and find out if there's anything they do other than WebRTC, maybe some kind of handshake that XG is preventing, causing the units not to detect each other.  Anything that I find out I'll pass along.

    All that said, it seems like only an XG developer will be able to get to the bottom of this, but I'd greatly appreciate the help if anyone is willing.  @Aditya Patel?  I *REALLY* don't want to have to switch to a competing firewall solution, after spending the last couple months getting XG all dialed in and training my wife on how to use it :).  But I really need these intercoms to work... Thank you!

  • 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.