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

Outgoing Google Hangouts video no longer works

Howdie,

I have a problem that's cropped up with Sophos UTM in recent months and was hoping to get some input from others on it. I've been using UTM since the astaro days (Astaro 6 maybe? Don't recall when I first set it up) when the home user IP limit was 10. I still think it's the best solution out there for firewall, IPS, etc. Which is why this is frustrating. I don't want to switch. :) I'm currently running UTM on a quad port Qotom PC (specifically, this guy: https://smile.amazon.com/gp/product/B01AAKGQQG/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1) and before that an older fit-PC (a celeron dual NIC version). I use UTM as my gateway to my ISP (Comcast using the "Blast" speeds which are ~12 up and 150 down).

Up until about a month or so ago I was able to use google hangouts without a problem (i.e., teleconferencing for work). But, recently my outgoing video won't work for hangouts. I can see my video locally, but it won't show up for anyone remotely. This only happens on my network and on any computer / phone / device I use on my network to access a hangout. I assumed I had changed something that broke it.

After much finagling, I couldn't find any setting in UTM that would fix it so I made a backup and reset UTM to factory settings. It still didn't work. So...I put in the most basic of firewall rules (Internal (network) -> Any protocol -> Any) thinking maybe something outgoing was being blocked. Nope. I rechecked to make sure all proxying, filtering, etc was off. Yep, all off. In desperation, I SSH'd to the box (after enabling SSH) and manually cleared all iptables rules (left the nat table untouched however so I still had internet access). Nope, still doesn't work.

To rule out some kind of ISP issue, I took UTM out of the loop entirely and set my Linksys AC1200 router up as my internet gateway. THAT worked. Others could then see my video just fine. Seeing as how I did not have this problem previously with UTM, my only conclusion is that some update has done something to muck up google hangouts outgoing video (I try to apply UTM updates pretty regularly). I'm not clear where this would happen however. I don't know exactly how hangouts video works, but I understand it uses STUN for NAT traversal. Although I believe it has several other protocols it falls back on. The linksys router is quite likely not linux based (probably vxworks) so probably handles NAT a little differently. But...seeing as how this used to work with UTM I'm assuming it's from a UTM update. Unless Google changed something...which would make me very sad.

So, anyone have any idea what might be going on here? 

Also, could some kind soul please try using a hangout on a network behind an up to date UTM (I'm currently using 9-405.5...I haven't yet applied the 9-406.3 update that just came out today) and see if you get video. You can easily replicate the problem by using two browsers (e.g., Chrome and Safari) on the same hangout (it won't work with two tabs in the same browser...hangouts prevents it).

NOTE: Though I never had these rules before, as a troubleshooting exercise I tried opening up ports referenced in here: https://support.google.com/a/answer/1279090?hl=en. That also didn't help. Which isn't surprising since that one rule I added in allowed all outgoing internal traffic anyway.



This thread was automatically locked due to age.
Parents
  • Also,

    One update I have. While looking into this more I discovered that chrome has a built in utility for debugging webrtc stuff (which is what hangouts uses). You just go to chrome://webrtc-internals/. It's pretty cool. There are lots of graphs in there and of particular interest was a graph labeled packetsLost for the "Sending video" stream which gives # of packets lost over time for video sending. When I use hangouts behind UTM that graph is forever increasing. The stats shown for the video stream indicate ~60% of all video packets are lost over time. When I use hangouts from work (different network without UTM) or behind my linksys router, that packetsLost graph is mainly flat with only occasional lost packets. So, something somewhere is definitely causing the packets to not get send (either dropped, rejected, not routed...something).

    Cheers,

    John

  • John, if you didn't look at the Intrusion Prevention log, you can't know if Anti-UDP Flooding activity is causing your problem.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I was not aware udp flood protection would still happen with IPS off. All three DoS protections are actually unchecked in the IPS config as well. But, just the same, I just double checked all four logs while replicating the problem. IPS is completely empty as is the Advanced Threat Protection log (also off anyway). The Application Control log has a few entries of the form:

    2016:09:24-16:57:37 astaro afcd[11313]: _afc_conn_get_age(): The timestamp of connection 0x00043600 is in the future; correcting ...

    But, they're all from much earlier today. NOTE: I do have application control on right now as I've since restored my normal configuration after resetting to factory defaults since resetting address the problem.

    The firewall log does have blocked items in my current configuration, but I don't think any of them are related to this problem. Mostly the items I already mentioned in the original post with one additional guy that's popping up a lot (whether replicating this problem or not) from a btsync box I have running. That's a thing to look into for another day.

    -John

  • Out of curiosity, would you be willing to try a hangout to test if you're seeing this problem (assuming you're behind a UTM box)? It'd be nice to verify I'm not crazy. :) That would at least narrow down if there really is something specific to my setup I've missed with a factory reset or if there's something different from a couple months ago. This definitely used to work...I've been using hangouts while working from home since 2010 and I've been using Astaro for a lot longer than that. :)

    I've found using the chrome://webrtc-internals page in chrome that you don't even have to connect to another person. You can see the packet loss directly in the tool in the graphs at the bottom if you expand the send (video) graph. You just need to be connected to a hangout (no one else has to be on it). On a non-UTM network the packet loss graph is mostly flat and a very low number. It's monotonically increasing on my network showing a lot of packet loss. E.g., here's an example with being on a hangout for only about 2 minutes. The packetLoss graph shows a steady positive slope and is already getting up near the thousands.

  • John, I'm beginning to suspect a hardware issue or an MTU setting.  Does #7 in Rulz help?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I actually tried almost all of the suggestions in #7 before I even found the Rulz post. :) Specifically, #1 doesn't apply (Intel NICs on both machines I used), #2 is ok (settings already off after reset), #4 done, #5 done, #6 done (I suspected the cable modem couldn't handle throughput...I was wrong, but now I have a backup!), and #8 (tried a different port).

    The only two I didn't try are MTU settings (#3) and link settings (#7). I can try those later today when not working. Though I feel like it is a very specific form of packet loss (i.e., basically all hangouts video packets). I would expect all of sorts of connectivity issues in such an instance of a hardware problem rather than only hangouts video.

    By any chance, do you have the ability to try this for yourself behind a UTM router? I'd really love to see if someone else can replicate this issue. Starting a google hangout is very easy (assuming you have a google account :)) E.g., this is one I just created from https://hangouts.google.com/hangouts which I think anyone can access: https://hangouts.google.com/hangouts/_/7zydsosg4vgcnjw4hlrgi2mfnae?authuser=0&hl=en. As I mentioned in a past reply, you can verify the problem by joining that with two different browsers (e.g., firefox and chrome) and observing the lack of video for the caller from the opposite browser in each browser (you can always see your own video).

     

    -John

Reply
  • I actually tried almost all of the suggestions in #7 before I even found the Rulz post. :) Specifically, #1 doesn't apply (Intel NICs on both machines I used), #2 is ok (settings already off after reset), #4 done, #5 done, #6 done (I suspected the cable modem couldn't handle throughput...I was wrong, but now I have a backup!), and #8 (tried a different port).

    The only two I didn't try are MTU settings (#3) and link settings (#7). I can try those later today when not working. Though I feel like it is a very specific form of packet loss (i.e., basically all hangouts video packets). I would expect all of sorts of connectivity issues in such an instance of a hardware problem rather than only hangouts video.

    By any chance, do you have the ability to try this for yourself behind a UTM router? I'd really love to see if someone else can replicate this issue. Starting a google hangout is very easy (assuming you have a google account :)) E.g., this is one I just created from https://hangouts.google.com/hangouts which I think anyone can access: https://hangouts.google.com/hangouts/_/7zydsosg4vgcnjw4hlrgi2mfnae?authuser=0&hl=en. As I mentioned in a past reply, you can verify the problem by joining that with two different browsers (e.g., firefox and chrome) and observing the lack of video for the caller from the opposite browser in each browser (you can always see your own video).

     

    -John

Children
No Data