RE: SM17 build 7242, video chat in team workspaces
Problem reported by Christopher Hiatt - 1/24/2020 at 3:32 PM
Resolved
Has anyone tried to use video chat in team workspaces across different networks? I setup a new install of SM17 to test everything out and am having an issue with this feature. If users are on the same network everything works fine. But users on separate networks will not connect the video. All other features still work fine.

I looked at the firewall logs on one location and when video starts there are connections created in a reserved IP range between the clients that the firewalls are correctly blocking. Something like 100.115.92.x. 

I can see no special setup instructions for the video chat other than having the site SSL secured which it is so I'm a bit stumped here.



11 Replies

Reply to Thread
0
Christopher Hiatt Replied
I tried this again this morning with mixed results. This seems dependent on the firewall appliance in play and how they treat certain protocol traffic. I'm by no means an expert on any of this so I tried several scenarios to see why it fails sometimes.

It generally works from cell to cell or if users are behind generic, home user type routers with no real filtering or firewall features.

-Cell to cell through TMO works fine.
-Cell to cell between TMO and Verizon works fine.
-Cell to wired internet with one user behind generic Linksys router works fine.
-Wired internet to wired internet with one user behind generic Linksys and the other on generic Netgear works fine.

Where it didn't work.

-Wired internet to wired internet with one user behind generic Linksys and the other behind Ubituiti with DPI and other app security features turned on. If both users are behind same Ubiguiti it works fine but any additional user on the other side of it does not share video.

-Wired internet to cell with one user behind Netgate firewall is no good. Same as above. If both users are behind the Netgate device it works fine. Add a third on the other side of the Netgate and they do not share video.

Doing packet captures during video connections it looks like the actual video protocol is attempting to create connections in a 100.115.92.0/29 space which is reserved under RFC 6890 and should not be found in the public address space. The Ubiquiti and Netgate are properly blocking this traffic as it should not be seen on the WAN. The generic routers from Linksys, Netgear and the others don't seem to care so this traffic passes without issue.

The 100.115.92.0/29 is also trying to send/receive to 192.0.0.4 which is a protocol address that encapsulates IPV4 traffic in IPV6 only networks. I had IPV6 disabled internally but did open it all up all the way through but the problem persists since it is still trying to send/receive from the 100.115.92.0/29 network.

If anyone else can't connect to video, see if you also have blocks on your firewalls from 100.115.92.0/29 or 192.0.0.4

Thanks!

0
Christopher Hiatt Replied
Anyone had a chance to test video chat in team workspace? Trying to see if anyone else is having an issue with video getting blocked between users across a firewall.
1
Dave Feuer Replied
Yeah, it's not working for me either with a client behind a SonicWall.
Opened a ticket. Lets see what they come up with.
-Dave
0
Christopher Hiatt Replied
Any feedback on your end?

It's dead on SM16, half works on 17. Maybe this is just one of those features to disable so I stop getting support requests for it.
1
Christopher Hiatt Replied
With the work from home conditions changing lately I'm getting a lot more complaints about users not being able to share video between their locations.

Are the transport issues on video chat in SM17 being looked at?
0
Chris Replied
Try opening Firewall Ports:
3478 UDP & TCP (STUN and TURN)
5349 UDP & TCP (STUN and TURN over TLS)
0
Christopher Hiatt Replied
That doesn't fix anything.

It depends on the firewall the client is using. Their device is the one blocking the connection. Clients on application and protocol aware devices are the ones having trouble connecting.  In doing my own testing across a pfSense device I saw traffic from the video client trying to connect to a 100.115.92.0/29  address space which should not be seen going across a WAN connection. The firewall properly blocked this connection.

Clients using dumb firewalls, generic home type routers or cell to cell connections are working fine.
0
Kyle Kerst Replied
Employee Post
Hello everyone, sorry for the delay in getting back to you on this. I do know we're investigating further on a couple of open tickets but are also getting mixed results. I personally found in one instance that an Avast Business Antivirus solution was preventing users from seeing each other though they were all successfully connected via video. After temporarily disabling this functionality users were able to see each other again. In other instances these issues appear to relate to the firewall in use as users have pointed out on this thread. I believe Universal Plug N Play may have something to do with this as well as the video connections likely need to be able to open dynamic ports. We'll continue investigating and will update as we find out more. Thanks for your time and efforts on this so far everyone!
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
David Sovereen Replied
100.115.92.0/29 is CG-NAT space, which is to be used by ISPs to assign end-users as a WAN IP Address.  This space was set up specifically for ISPs to use so that they could assign a NATted IP to end-users that would not conflict end-users' own NAT space (192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8).  Smartermail should not be using this IP space for their video chat because an end-user whose ISP assigns them an IP in that range will presumably not be able to connect.  Note that I have not done a packet capture myself, but I do know that video chat is not working for us at all.
0
Chris Replied
We found that removing Symantec Endpoint Protection on our server resolved our workspace issues, we were able to get 7 people to connect at all different locations successfully. Sometimes, a person cannot see another person, to fix it, they can simply stop the video and re-enable video and it works. Do you have any anti-virus or intrusion detection software system?
0
Kyle Kerst Replied
Employee Post Marked As Resolution
Quick update for you all on this one! I just finished a retest under our latest MAPI codebase and was able to successfully get multiple users on multiple device types and different networks connected to video chat successfully, and believe you too should be able to make this work once the new release is out. 

With that being said, there are some caveats. Once the new version is installed, you'll need to do/note the following: 

- STUN/TURN server will need to be implemented in server configuration. Google operates a few public STUN/TURN servers that I was able to use for these purposes and I recommend starting there. 

- Users will need to ensure they are not using the camera or microphone on any other applications/meetings, otherwise access to those devices will be blocked. 

- STUN/TURN server coordination will require specific ports be opened as outlined in this post here: https://docs.pexip.com/rp_turn/rpturn_ports.htm and these will need to be opened on the server firewall.
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Reply to Thread