Google Compute Engine websocket - asp.net-core

I have a Google Compute Engine Instance and have an ASP.NET Core application deployed to it. Within that application, I run
WebSocketServer server = new WebSocketServer("ws://0.0.0.0:2001");
To start a websocket server on port 2001. However, when I try and start a websocket connection to this port (m.y.i.p:2001), it times out. I don't understand why since the VM is tagged with the same network tag for ingress and egress that I created allowing access to all ports. If not the firewall, where else could I investigate?

For anyone else that seems to encounter a similar issue with opening a port on a VM running Windows Server (I was using the 2016 edition), I fixed it by remote desktoping into the machine and disabling its firewall. I had to do this even though I had made Compute Engine firewall exceptions. If anyone wants to clarify, I am assuming it's better to handle all firewall related things in GCP rather than having the internal firewall of the VM itself as well since there is likely to be conflict?

Related

WebRTC call between two networks connected to the same server

I currently have the following network setup and would like to be able to make WebRTC calls between the two clients in different networks.
I enabled IPv4 forwarding on the openSuse Leap 15.2 server and both devices have either 192.168.2.1 or 192.168.4.1 as their default gateway. The web application as well as the signaling service are both hosted on this server as well.
With the Firewall disabled the call works as suspected, but with the Firewall on the call no longer works. I thought about hosting a Coturn STUN/TURN server on this server, as I've read that you should provision one, if you run into troubles with a firewall.
Is a setup like this doable with lets say Coturn and what would the configuration look like for a scenario like this?
I ended up solving it as I describe in my GitHub issue for this matter.

Issues with WebRTC based application

I have developed a WebRTC based application along with Kurento-Media-Server.
Problems with this application is:
It works but only on open network (i.e. if run on a network without firewall).
When in firewall it runs sometimes (once out of 10 attempts).
I have tried several things with the firewall, I have disabled all kind of incoming/outgoing traffic. I have created a port-forwarding for my application as well as Kurento-media server.
I am not sure how much useful this information might be but I am deploying my
application on the same physical box along with Kurento-Media-Server. I have configured google's STUN server on my client.js, I have also configured same STUN servers on kurento using code. I haven't configured TURN server.
Just confirming this, signaling server can be behind firewall along with rest of the application, correct?
I am not sure what to look for now, any help in this area would be great.
EDIT-1
From this link I learned that my current network on which my isn't working it has issues with plain websocket connection, it doesn't allow it, it only allows secure Websocket connections.
EDIT-2
Image of netscan:
In my phone network where my app works fine I see all greens in Websocket's "plain" column.
EDIT-3 Solved
Finally found the problem, We were using a router for testing and development and I found that the router had issues, I used LAN cable on the same router and everything worked fine. Calls from application were working just fine. Firewall related details help in configuring the firewall later on.
Based on your problem description it seems all the UDP traffic is not open in your firewall. WebRTC media run on UDP ports.As you mentioned it works one out of 10 times whch means only few UDP ports are open in your firewall.You are lucky when traffic comes via tose ports.You can open port-range in your firewall and configure the same in kurento-media-server config.Your job should be done.
Even if you configure TURN server you need to open certain ports for outgoing and incoming UDP traffic.For TURN server default port is 3478 or 8443 for sending data towards it but for incoming traffic you need to configure port-range on your TURN server and open those ports in your firewall. Always remember TURN server is assured way to connect but it's always costly.

Setting up ubuntu VM on Azure with apache

In Azure, I created a virtual network and then associated an Ubuntu Server virtual machine, created with Azure Resource Manager Deployment method, with the network. I then updated the associated Network Security Group and added an inbound security rule for port 80 (Source:Any, Destination:Any, Service:TCP/80). After installing Apache on the VM, I tried to access the server from my browser, but have run into a wall. I can SSH into the VM just fine, but web is a no-go, and I cannot figure out why. Any help would be appreciated.
It sometimes happen to me too because I forgot to RESTART the VM, yes just restart it. At least this works for me. and also dont forget to add outbound rule too
It worked for me with this inbound rule.
Note that when a VM is created from the portal (in ARM model), it gets automatically associated to a virtual network (vnet), a specific subnet within the vnet and a network security group.
When creating the inbound security rule, make sure to:
identify the correct network security group associated to the VM
use a priority number lower than 65500
set the source port range as *
You also need open port 80 on the VM to allow web access.
I dont think that creating your Network Security Group opens the desired port on the VM automatically.
By default in Azure Resource Manager (ARM), all ports are open; there is no need to make Network Security Groups (NSGs) to open ports, only to close them. Here is an example of an ARM template that deploys an ubuntu VM with apache:
https://github.com/Azure/azure-quickstart-templates/tree/master/apache2-on-ubuntu-vm
Alternatively, if you want an auto-scaling LAP stack using VM Scale Sets (in public preview), you can find the ARM template for that here:
https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-lapstack-autoscale
Hope this helps! :)

TeamViewer type of service for headless servers

So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.

SSAS 2012 Non-Standard Port & Create Global Cube Command

The hosting environment where the SSAS 2012 instance is located refuses to open the default port number (2383), and insists on using port 443. Almost all SSAS functions and connections work just fine when running over port 443.
However, the CREATE GLOBAL CUBE command query returns an error.
Either a connection cannot be made to the [SERVER NAME] server, or
Analysis Services is not running on the computer specified.
When I switch the SSAS port back to the default 2383, the CREATE GLOBAL CUBE command works perfectly.
Why does this happen, and is there any way to work around this? I suspect it's possibly a limitation in the OLEDB provider, but don't have any proof or definite leads.
I'm happy to use this issue as ammunition to have the host open up port 2383, but this is a battle I've lost multiple times in the name of "security", and time for an end-to-end working solution is running out. (The hosting environment is a department of a corporation, not a 3rd party.)
UPDATE:
This has been confirmed as a bug in the SSAS connection/connection string handling by Microsoft.
You can setup Analysis Services to be accessed via http and https. Actually, this is using a DLL which is part of Analysis Services. This DLL is hosted in IIS and acts as a kind of proxy between the client and the Analysis Services server. See http://msdn.microsoft.com/en-us/library/gg492140.aspx for details of the installation. You can then configure security settings like https or different authentication modes in the IIS configuration.
The SSAS dev team reports that currently for this command to work, either the SSAS default port must be used, or the SQL Browser default port must be available so that the browser service can direct requests to the non-default port. If neither service's default port is available, it is impossible to run this command from a remote connection.
Microsoft are currently working on a patch.