Scopia For IP Office disconnects using xt desktop client from outside

[shadow181]

Hi,

XT5000 on 8.3 with XT desktop running on IPO 9.0

When we try to connect from off prem we get the web interface but when we try to connect we get booted. We have things working internally using an FQDN, I read in another post that we may require a second different FQDN for outside calls? Why would that be? Also it should only need to resolve to the XT Desktop and not the MCU correct?

Thanks

 

[holdmusic34]

The fqdn should resolve to an A record (public ip address).
Within the router you do your port forwarding. Some to the mcu. Some to the xt desktop server.
Internally, you have a dns entry that resolves the fqdn to the xt desktop. I'll post the port forwarding in a few hours.
Use the same FQDN.


There's no point going anywhere. You'll always be here. Try it and see.

 

[IPOfficeGuru]

Assuming your using the XT5000 built-in MCU9 with the SMB9 license?
Does your XT Desktop Server PC have 2 LAN interfaces?
If so, the public DNS is forwarding port 80 & 443 through the firewall to XT Desktop Ethernet0 in a DMZ.
The XT Desktop PC Ethernet1 should reside on the same production network as the Scopia XT5000?

UDP Ports are also required to be forwarded to the XT Desktop server Ethernet0 for streaming.
Those ports are defined by you in the Scopia XT Desktop Amin - under the Client tab on the right.

"You can limit the UDP port range that clients negotiate with SCOPIA XT Desktop to send audio and video. You must use a limited scope between 2326 and 65535."
Lowest Multimedia Port XXXXX
Highest Multimedia Port XXXXX

"Never fear billing a client for services rendered, or they will think your time is worthless"

 

[holdmusic34]

tcp XT Desktpop 4000-4200
udp XT Desktop4000-4200
tcp XT DEsktop443
tcp MCU 1720
tcp XT Desktop 80
Don't forget the firewall on the XT Desktop. Turn it off for testing.

There's no point going anywhere. You'll always be here. Try it and see.

 

[derfloh]

Having the XT Desktop server connects with one interface in DMZ and with the other in the production network is not what a DMZ is meant for!

The goal of a DMZ is to prevent hacker to access your productive network if he gets control over a public available server. That will not work if the hacked server is also part of the productive network!

 

[IPOfficeGuru]

Let me clarify; I meant DMZ as a generic term for a firewalled network zone away from the production network. Believe me, there is some knucklehead out there attaching the XT Desktop Server directly to the production network or directly to the internet with a public static IP.


"Never fear billing a client for services rendered, or they will think your time is worthless"