Web Server to Local CasparCG Server

config
server

#1

Connecting an Azure or Amazon Web Server to CasparCG

I will apologize in advance for me lack of networking knowledge but, would someone be able to recommend the best way to connect a web server running Express & the Caspar Connection package on an Azure or AWS web server to a local CasparCG Server?
Currently the web server and the Caspar server are running on the same computer so I can set the host to the local IP (127.0.0.1). Would I need to open a local web server and send all the commands to it? Could I use SSH to I don’t need to change any router settings?

Thank you in advance!!


#2

I think the easiest way of doing that is expose the AMCP LAN port to a set WAN port and connect directly to it from your server. Eg. forward 5250 to 52500 and connect to the public IP through that port.
I tested it many times using a dyndns solution and works seamlessly. Be aware of the security issues surrounding that.


#3

Here is where that lack of networking knowledge comes in. Do you have any good starting references for exposing ports? Also, I would need to be able to access the router to make the port forwarding possible correct?

Long term, the goal is to be able to startup a Capsar server anywhere with internet and connect to the web-server which is a client that provides the graphics. No router configuration required. That is where the SSH idea came from.


#4

Yes, unfortunately. Unless you have UPnP enabled in the router and an app that maps the port for you.

I think you would need an intermediary or tunnel (that both ends would connect to) for that as the server is in a LAN and the client in WAN, not the other way around. Somebody please correct me if I’m wrong.

I was thinking lately about adding to the launcher app a little DynDNS client and a UPnP mapper to achieve what you are trying to do.


#5

I think you would need an intermediary or tunnel (that both ends would connect to) for that as the server is in a LAN and the client in WAN

Agreed! Granted I know nothing about how to achieve this. I would be 100% involved in backing UPnP (Universal Plug & Play for those who need to look it up like I did :wink:) mapper. This is something that would need to be written in some variation of a C language right? Then would it run on top of Caspar? Maybe before as a launcher?


#6

Not necessarily, It’s a standard protocol like any other. It talks to the router and asks nicely if a port can be mapped. That’s all.

It could be run in any other process even as a service. I thought it could be added to this launcher or maybe add a separate windows service to watch out for the launcher’s health and provide the port mapping and DNS.


#7

I think that is the solution right there. Add it to that launcher since it already has lot of functionality.


#8

You still need to enable UPnP in the router and if the router is connected to a modem with router built in, you also need to set that up.


#9

The concept of opening up the CasparCG TCP control port to the internet is inherently flawed because the connection is insecure and can therefore be listened to and hijacked.

I would suggest to investigate the idea of tunneling further. It doesn’t have to be SSH necessarily, can also be done by piping AMCP over websockets or perhaps WebRTC data channels for a faster p2p connection.


#10

I agree with Balte, since no security is implemented in AMCP (there is no need for it in studio environments) exposing AMCP port on local router is a bad idea.

If you really want this functionality, you can bring up another server inside your secure environment, expose it’s API securely to internet, and than route the received commands to CCG server, but this requires some work.


#11

You can try https://ngrok.com/


#12

That may be a quick and easy solution. Let me look into it and get back to you :grin:


#13

Presumably you are more comfortable with node than networking, given the use case. So have you thought of a little node daemon app on the CasparCG box that opens a socket (TCP, or WS) to your Azure/AWS web server - a proxy?

If you used a websocket you could easily reuse your auth scheme in your express app. That keeps your CasparCG box secure because the connection is outward to the webserver. Into the bargain you can see on the webserver that Casparcg is alive, save yourself dynamic DNS, NAT traversal, & security workarounds,

Comments?


#14

@Yoostin, spot on observation. I am definitely much more comfortable with node but my knowledge still falls flat with Node Networking (Especailly ASW configuration).

So, I use Socket-IO for my websocket communications now. Would I just connect to the socket io instance on the remote server from the local nodejs sevrer? Similar to how a client connects?


#15

For clarity - I’ll refer to CasparCG as being local and your webserver as being Remote.

Close - you’d have the local node app running on CasparCG box open a socket connection to your remote webserver - exactly like it is a client. That local proxy app also opens a TCP connection to CasparCG localhost and pipes everything between the TCP & WS. I’m sure you’ll find loads of examples on github to get started.

On the webserver, remote, side it’s up to you how you integrate with Caspar-Control and plumb the websocket - either cutting out caspar-control’s TCP socket & using the websocket native. Or by implementing the same proxy idea on the server where Caspar-Control opens its usual TCP connection but instead of to a CasparCG instance it’s to a TCP socket block running within your webserver’s node app & pipe WS & TCP together just as you did on the client.

Caveats: Be sure to only allow localhost connections on your TCP sockets on either end. On the server your websocket should only accept a connection with an auth token from the client - just throw a hashed secret in a header & check for it on the server.

Bonus: Once you’ve set up the TCP over WS proxy it would be trivial to add in OSC proxying.

This is all a bit cludgey & all things that a quick SSH tunnel or even a VPN would fix - but we’re staying out of networking land. :wink:

Still a neat little trick to add to your repertoire of hackery though. It has loads of uses.