Lifesize Server, SfB/Lync and Tunnel Gateway IP Address List

Document created by michaelt

on Apr 19, 2016•Last modified by michaelt

on May 18, 2017

Like • Show 17 Likes17
Comment • 10
View in full screen mode

Customers with firewall policies in place that are restricted to the node addresses used in Lifesize Cloud, must ensure their firewall rules whitelist all of the IP addresses outlined below. Failure to do so may result in loss of access to the service in the event of a fault or failure condition.

Location	Front-End Server	SfB/Lync Gateway	Desktop Tunnel Gateway	Web App Tunnel Gateway
Amsterdam, Netherlands	5.153.63.162	5.153.63.168	5.153.63.167	159.8.41.131
Chennai, India	169.38.84.49		169.38.84.47	169.38.76.194
Dallas, TX, USA	23.246.195.8	23.246.195.6	23.246.195.2	158.85.140.178
Dallas, TX, USA	184.173.213.195		184.173.213.201	50.22.103.178
Frankfurt, Germany	159.122.100.42		159.122.100.57	159.50.10.10
Hong Kong	119.81.134.226	119.81.134.228	119.81.134.231	119.81.152.130
London, England	5.10.105.200		5.10.105.201	159.8.144.180
Melbourne, Australia	168.1.68.251		168.1.68.228	168.1.73.132
Mexico City, Mexico	169.57.7.200		169.57.7.202	169.57.1.68
Milan, Italy	159.122.152.111		159.122.152.119	159.122.153.194
San Jose, CA, USA	192.155.215.197		23.246.216.98	192.155.217.58
San Jose, CA, USA	169.45.75.100		169.45.75.102	169.45.78.148
Sau Paulo, Brazil	169.57.160.228		169.57.160.227	169.57.134.146
Toronto, Canada	169.53.184.72		169.53.184.77	158.85.97.148
Washington DC, USA	50.97.60.166		173.192.205.195	50.97.33.58
Washington DC, USA	169.55.87.188		169.55.87.173	169.55.101.52

This complete list of Lifesize Cloud front-end server addresses is always current and available under Advanced Settings on the Lifesize Cloud Admin Console.

Lifesize also announces new server locations and node addresses via the Lifesize Cloud Status Page located at status.lifesizecloud.com. Please subscribe so you’re always in the know.

rev.05.18.2017 to update London Web App Gateway.

25 people found this helpful

Attachments

Outcomes

rmaloney

Jun 10, 2016 8:27 AM

Hi Michael,

I would like to expand your list of IP addresses to support the Web App firewall traversal methodologies. Web App uses a different method for traversing a firewall than the desktop app does.

In some situations it might be necessary for the Web App to traverse over a single secure port (443 TCP), in these events the call will hand off to a new set of servers / IP addresses to accommodate the traversal method. These IP addresses are listed below.

Cloud Nodes	Tunnel Gateways for Desktop Only	Turn Servers for Web App Only
119.81.134.226	119.81.134.231	119.81.152.130
159.122.100.42	159.122.100.57	158.85.140.178
159.122.152.111	159.122.152.119	158.85.97.148
168.1.68.251	168.1.68.228	159.122.153.194
169.45.75.100	169.45.75.102	159.8.144.180
169.53.184.72	169.53.184.77	159.8.41.131
169.55.87.188	169.55.87.173	168.1.73.132
169.57.7.200	169.57.7.202	169.45.78.148
184.173.213.195	173.192.205.195	169.50.10.10
192.155.215.197	184.173.213.201	169.55.101.52
23.246.195.8	23.246.195.2	169.57.1.68
5.10.105.200	23.246.216.98	192.155.217.58
5.153.63.162	5.10.105.201	50.22.103.178
50.97.60.166	5.153.63.167	50.97.33.58

- Robert

8 people found this helpful

Actions

mkluge

@ rmaloney on Jun 14, 2016 8:50 AM

Hi Robert,

will all traffic of Web App use automatically these gateways via TCP port 443 or are there additional ports/IP's necessary, e.g. Front-End cloud servers for authentication and signaling? What about chat?

I'm also interested in, if this will work in a browser via proxy or do we have to allow traffic to this gateways directly?

Is there a different behavior between IE and Chrome Web App?

Actions

rmaloney

@ mkluge on Jun 14, 2016 10:27 AM

Hi Martin,

Today Chrome and IE have a variation on how TCP443 tunneling works. Chrome is the easy one since it natively supports the WebRTC technology, anytime the Web App makes a call it will try to determine the best route for traversing a firewall, the final attempt will be pushing signaling and media over port 443 using TCP.

With the same scenario we found that in some instances the IE11 plug-in is only tunneling the signaling and sending the media directly to the node servers, if the node servers are blocked this will results in a temporary connection for ~60 seconds, black screen, then disconnect. We are in the process of analyzing this behavior and should know more soon.

For the time being, the recommended design is to allow the Node Server and TURN Server IP addresses via 443 if you are running into issues with the IE11 Web App.

7 people found this helpful

Actions

support@qconferencing.nl

Jun 16, 2016 7:18 AM

Over here you showing 3 columns off IP's for different purposes, in the Cloud admin console where you are pointing at underneath the picture only the Node IP addresses are mentioned, isn't it helpful to show this diagram in total at the admin portal also?

Uunderneath an image how it is shown in the cloud admin console.

Patrick

Actions

support@qconferencing.nl

@ support@qconferencing.nl on Jun 16, 2016 7:23 AM

Also useful would be to tell where this IP's are located so you can look if there are nodes near by. Is it possible to share the information where the new IP's / Nodes are located?

Actions

mtran

Jun 16, 2016 10:32 AM

Hi, I am a little confused. Isn't the cloud web app and the cloud client using the same firewall ports? Just wanted to clarify so that I have a better understanding of how and if these lists of IPs are needed to be added to the firewall. Thanks.

Actions

kpinkham

@ mtran on Jun 21, 2016 11:47 AM

MT, yes the thick client and web app do use the same network ports but if they are blocked they will use different tunneling mechanisms which require separate servers with different IP addresses. If all of the required ports are open the tunnel servers are not needed.

2 people found this helpful

Actions

aurelien

Jul 19, 2016 6:55 AM

Hello,

We blocked the following ports to force the application to tunneling but it does not work.

- Tcp 35060/35061

- Udp 10000-28000

The bandwidth remains free.

Actions

kpinkham

@ aurelien on Jul 19, 2016 7:12 AM

The tunnel will be created over web ports TCP 80/443. Is there a proxy or other device inspecting web traffic? Are you able to log into the client at all?

Actions

aurelien

@ kpinkham on Jul 20, 2016 3:51 PM

I have make this post too fast without reviewing.

I think that we succeeded the tunneling but the bandwidth exceeds the 320Kbits which we put on manage.lifesizecloud.com. It is possible?

It would be more easy for our small customer if as in the client Clearsea we had the possibility of restraining the brandwidth in the application.

@Kevin : I don't know for a device inspecting web traffic.

Yes, the client connects.

1 person found this helpful

Actions

10 Comments

Cloud Nodes	Tunnel Gateways for Desktop Only	Turn Servers for Web App Only
119.81.134.226	119.81.134.231	119.81.152.130
159.122.100.42	159.122.100.57	158.85.140.178
159.122.152.111	159.122.152.119	158.85.97.148
168.1.68.251	168.1.68.228	159.122.153.194
169.45.75.100	169.45.75.102	159.8.144.180
169.53.184.72	169.53.184.77	159.8.41.131
169.55.87.188	169.55.87.173	168.1.73.132
169.57.7.200	169.57.7.202	169.45.78.148
184.173.213.195	173.192.205.195	169.50.10.10
192.155.215.197	184.173.213.201	169.55.101.52
23.246.195.8	23.246.195.2	169.57.1.68
5.10.105.200	23.246.216.98	192.155.217.58
5.153.63.162	5.10.105.201	50.22.103.178
50.97.60.166	5.153.63.167	50.97.33.58

mkluge @ rmaloney on Jun 14, 2016 8:50 AM
Hi Robert,
will all traffic of Web App use automatically these gateways via TCP port 443 or are there additional ports/IP's necessary, e.g. Front-End cloud servers for authentication and signaling? What about chat?
I'm also interested in, if this will work in a browser via proxy or do we have to allow traffic to this gateways directly?
Is there a different behavior between IE and Chrome Web App?
Like • Show 1 Like1
Actions
- rmaloney @ mkluge on Jun 14, 2016 10:27 AM
  Hi Martin,
  
  Today Chrome and IE have a variation on how TCP443 tunneling works. Chrome is the easy one since it natively supports the WebRTC technology, anytime the Web App makes a call it will try to determine the best route for traversing a firewall, the final attempt will be pushing signaling and media over port 443 using TCP.
  
  With the same scenario we found that in some instances the IE11 plug-in is only tunneling the signaling and sending the media directly to the node servers, if the node servers are blocked this will results in a temporary connection for ~60 seconds, black screen, then disconnect. We are in the process of analyzing this behavior and should know more soon.
  
  For the time being, the recommended design is to allow the Node Server and TURN Server IP addresses via 443 if you are running into issues with the IE11 Web App.
  7 people found this helpful
  Like • Show 1 Like1
  Actions

support@qconferencing.nl Jun 16, 2016 7:18 AM
Over here you showing 3 columns off IP's for different purposes, in the Cloud admin console where you are pointing at underneath the picture only the Node IP addresses are mentioned, isn't it helpful to show this diagram in total at the admin portal also?
Uunderneath an image how it is shown in the cloud admin console.
Patrick
Like • Show 1 Like1
Actions
- support@qconferencing.nl @ support@qconferencing.nl on Jun 16, 2016 7:23 AM
  Also useful would be to tell where this IP's are located so you can look if there are nodes near by. Is it possible to share the information where the new IP's / Nodes are located?
  Like • Show 1 Like1
  Actions
mtran Jun 16, 2016 10:32 AM
Hi, I am a little confused. Isn't the cloud web app and the cloud client using the same firewall ports? Just wanted to clarify so that I have a better understanding of how and if these lists of IPs are needed to be added to the firewall. Thanks.
Like • Show 1 Like1
Actions
- kpinkham @ mtran on Jun 21, 2016 11:47 AM
  MT, yes the thick client and web app do use the same network ports but if they are blocked they will use different tunneling mechanisms which require separate servers with different IP addresses. If all of the required ports are open the tunnel servers are not needed.
  2 people found this helpful
  Like • Show 1 Like1
  Actions
aurelien Jul 19, 2016 6:55 AM
Hello,

We blocked the following ports to force the application to tunneling but it does not work.
- Tcp 35060/35061
- Udp 10000-28000
The bandwidth remains free.
Like • Show 1 Like1
Actions
- kpinkham @ aurelien on Jul 19, 2016 7:12 AM
  The tunnel will be created over web ports TCP 80/443. Is there a proxy or other device inspecting web traffic? Are you able to log into the client at all?
  Like • Show 1 Like1
  Actions
  - aurelien @ kpinkham on Jul 20, 2016 3:51 PM
    I have make this post too fast without reviewing.
    I think that we succeeded the tunneling but the bandwidth exceeds the 320Kbits which we put on manage.lifesizecloud.com. It is possible?
    It would be more easy for our small customer if as in the client Clearsea we had the possibility of restraining the brandwidth in the application.
    @Kevin : I don't know for a device inspecting web traffic.
    Yes, the client connects.
    1 person found this helpful
    Like • Show 1 Like1
    Actions

Lifesize Server, SfB/Lync and Tunnel Gateway IP Address List

Attachments

Outcomes

Related Content

Recommended Content

Incoming Links