I am creating a TCP tunnel application for RDP connections, On Server-side: Redirecting RDP connections to tunnel-server, Then sending those data to Client-side which receives the data successfully. But what happens after that? I don't know!
I know it is easier if traffic was HTTP/HTTPS because you can parse the header to address and content then send back the result. You don't even need TCP or sockets but forwarding RDP is unclear for me.
How can i forward those traffics from client-side then sending the results back to server and mstsc (windows default RDP client)? My problem is with the concept, Should i send those RDP data to client then from client machine to port 3389? And this app is considered some sort of Socks Proxy i guess.
This is the structure of what i have done at the moment:
Similar threads that aren't answer to my issue:
RDP through TCP Proxy
How to create a simple proxy in C#?
C# Proxy using Sockets, how should I do this?
P.S. The type of programming language doesn't matter for me (Currently working with c# and python but newer languages are OK too), I just want to learn how it works conceptually with a simple pseudo-code or sample, All kind of explanations or examples are appreciated.
Related
In short we have two separate servers for our web app. The first one is the main server that uses Websockets for handling "chat rooms", and the second server only handles WebRTC audio chat rooms via Websocket. Both servers use Express to create a HTTPS server, use secure Websocket and the port 443.
I recently encountered a problem where a corporate client's firewall blocked the wss-connection to only the WebRTC server. The error logged in the user's browser was "ERR_CONNECTION_TIMED_OUT", which means the user never connects via Websocket. This has not happened with any other clients.
The Websocket connection works normally between the user and the main server, and no rules have been added to their firewall to use our app.
Has anyone encountered something similar? What kind of a firewall setting might cause this? Could this be a cors problem, since the servers are on their own sub-domains?
The main server could be restricting the type of data sent on port 443, which will use SSL to secure that transmitted data.
Refer to this page for information on the "Well-know port numbers".
The WebRTC audio data may need to be transmitted on its own dedicated port number that has been configured on the main server for this.
The problem was that the main server WebSocket used TCP and the WebRTC server used UDP, and UDP was blocked by corporate firewall on default.
WebRTC should use TCP as a backup, but I'm assuming UDP is still needed for the handshake.
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.
If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?
And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose
of using existing web/HTTP infrastructures? And I think it no longer
fits the name WebSocket on non-80 ports.
You can run a webSocket server on any port that your host OS allows and that your client will be allowed to connect to.
However, there are a number of advantages to running it on port 80 (or 443).
Networking infrastructure is generally already deployed and open on port 80 for outbound connections from the places that clients live (like desktop computers, mobile devices, etc...) to the places that servers live (like data centers). So, new holes in the firewall or router configurations, etc... are usually not required in order to deploy a webSocket app on port 80. Configuration changes may be required to run on different ports. For example, many large corporate networks are very picky about what ports outbound connections can be made on and are configured only for certain standard and expected behaviors. Picking a non-standard port for a webSocket connection may not be allowed from some corporate networks. This is the BIG reason to use port 80 (maximum interoperability from private networks that have locked down configurations).
Many webSocket apps running from the browser wish to leverage existing security/login/auth infrastructure already being used on port 80 for the host web page. Using that exact same infrastructure to check authentication of a webSocket connection may be simpler if everything is on the same port.
Some server infrastructures for webSockets (such as socket.io in node.js) use a combined server infrastructure (single process, one listener) to support both HTTP requests and webSockets. This is simpler if both are on the same port.
If I use WebSocket over other ports, why not just use TCP directly? Or
is there any special benefits in the WebSocket protocol itself?
The webSocket protocol was originally defined to work from a browser to a server. There is no generic TCP access from a browser so if you want a persistent socket without custom browser add-ons, then a webSocket is what is offered. As compared to a plain TCP connection, the webSocket protocol offers the ability to leverage HTTP authentication and cookies, a standard way of doing app-level and end-to-end keep-alive ping/pong (TCP offers hop-level keep-alive, but not end-to-end), a built in framing protocol (you'd have to design your own packet formats in TCP) and a lot of libraries that support these higher level features. Basically, webSocket works at a higher level than TCP (using TCP under the covers) and offers more built-in features that most people find useful. For example, if using TCP, one of the first things you have to do is get or design a protocol (a means of expressing your data). This is already built-in with webSocket.
And since current WebSocket handshake is in the form of a HTTP UPGRADE
request, does it mean I have to enable HTTP protocol on the port so
that WebSocket handshake can be accomplished?
You MUST have an HTTP server running on the port that you wish to use webSocket on because all webSocket requests start with an HTTP request. It wouldn't have to be heavily featured HTTP server, but it does have to handle the initial HTTP request.
Yes - Use 443 (ie, the HTTPS port) instead.
There's little reason these days to use port 80 (HTTP) for anything other than a redirection to port 443 (HTTPS), as certification (via services like LetsEncrypt) are easy and free to set up.
The only possible exceptions to this rule are local development, and non-internet facing services.
Should I use a non-standard port?
I suspect this is the intent of your question. To this, I'd argue that doing so adds an unnecessary layer of complication with no obvious benefits. It doesn't add security, and it doesn't make anything easier.
But it does mean that specific firewall exceptions need to be made to host and connect to your websocket server. This means that people accessing your services from a corporate/school/locked down environment are probably not going to be able to use it, unless they can somehow convince management that it is mandatory. I doubt there are many good reasons to exclude your userbase in this way.
But there's nothing stopping you from doing it either...
In my opinion, yes you can. 80 is the default port, but you can change it to any as you like.
This may not be the correct place for this question as it's part networking, but here goes.
I am wanting to put together a WebApi (using the ASP.NET MVC WebApi framework) to be consumed by client machines external to our network. However the client machines resolve web traffic through a proxy server for which our software does not have authentication. We have noticed that outgoing FTP connections are possible though.
So I am wondering whether we can host the webapi and have client machines connect out through Port 21? Does that even make sense? Sorry if it's a stupid question.
I managed to find some answers and thought I would share for anyone that might be interested.
Binding WebApi to ports other than 80
This is possible, but tricky. When you publish the Api project onto IIS (or wherever you are hosting it) you just bind it to an alternative port. You then also make sure you forward that port in your router. Then, clients of the API just specify the host using your custom port to access the endpoint through that port: http://myhostname.com:21/api/values or whatever.
Complications
Testing the endpoints can be tricky as Chrome blocks HTTP traffic being sent via some ports - port 21 is one such port. So to test it you need to write a client exe that can hit the endpoints to make sure they are working (like a console application).
Despite figuring all of this out, I still could not connect out through the firewall. I suspect that some configuration is blocking the traffic because even though it is going out through an open port (21), it is not FTP traffic: it's HTTP traffic.
A Solution
It occurred to me that SOAP operates through a range of protocols (FTP, SMTP, HTTP, to name a few) and formats its messages as XML. So in this scenario it would make more sense to use a SOAP service via Port 21 rather than REST which is strictly HTTP.
Please consider the following scenario:
VNC Client try to connect with a VNC Server which is behind a NAT.
I have written a port forwarder in java which help me achieving above task, and it works fine.
Now I need to, somehow, add a connection brokering functionality within this forwarder so that I can also intercept the communication between VNC Client – Server, and authenticate the VNC Client within the forwarding utility as well.
You may have guessed that actually I am using the password received from VNC Client for some authentication in my app. As the RFB Server can be implemented at application layer, I guess this interception is possible... VNCAuthentication (DES encryption/decryption) is used in all above communication. Upon successful authentication within the forwarding utility I shall just let the forwarding continue for that respective client, else I can close it (stop forwarding).
I have tried some implementation, also tried customizing a java implementation of rfb server... but still not able to get there. It will take some time, I know, but need to confirm if I am thinking straight.
Please let me know if the implementation of above scenario is ambiguous, not possible, or illegitimate and if this is possible, let me have some guild lines...
This seems like a good implementation. Think of it like a VNC proxy, just like an HTTP(S) proxy. There are also HTTP authenticating proxies. You're implementing part of the VNC protocol to create an authenticating VNC proxy.
Maybe you can get some inspiration from VNCProxy, an existing Java VNC proxy.
I am working on a dropbox like system and I am wondering how the client gets notified when the files change on the server side. It is my impression that both dropbox and ubuntu one operate over HTTP ports and work as follows:
1. if files change on client machine, inotify detects it and preforms a push from the client to the server. (I get this part)
2. if files change on the server a simple unsolicited notification (just a message saying "time to sync") is sent from the server to the client. Then the client initiates a sync to the server.
I dont really care which language I do this in. I am just wondering how the client gets contacted. Specifically, what if a client is behind a firewall with its own local IP addresses. How does the server locate it?
Also, what kind of messaging protocols would be used to do something like this? I was planning on doing this over HTTP or SSH, but I have no attachment do that.
I'm not sure what Dropbox is using, but it could be websockets (unlikely, it's a pretty new and not widely deployed thing) or more likely a pending Ajax request from the client to the server -- to which the server only responds when it has new stuff for the client. The latter is the common way to implement (well, OK -- "hack";-) some form of "server push" with HTTP.
It took a little research into networking to see how this would work, but it is far more trivial then I expected. I am now using standard Java sockets for this. Start up the server process which listens for a socket connection. Then start up the client which connects to the server.
Once the connection is made, messages can be sent back and fourth. This works through NAT (network address translation) which is standard method for routing packets on private networks behind a firewall.