I have MongooseIM server configured with docker-compose in an EC2 instance in AWS.
I intend to give access to some mobile clients with SSL through an ELB (AWS) on port 5222 (module ejabberd_c2s of mongooseim) in the following way:
SSL (Secure TCP) -> 5222 -> TCP -> 5222 (EC2 Instance Port)
In the ejabberd_c2s module configuration I have the following:
{ 5222, ejabberd_c2s, [
%%
%% If TLS is compiled in and you installed a SSL
%% certificate, specify the full path to the
%% file and uncomment this line:
%%
{certfile, "priv/ssl/fake_server.pem"}, starttls,
%%{zlib, 10000},
%% https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
%% {ciphers, "DEFAULT:!EXPORT:!LOW:!SSLv2"},
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536},
{protocol_options, ["no_sslv3"]}
]},
But customers can not connect, the only message I get on the server is this:
mongooseim_server_dev | 10:58:25.885 [info] (#Port<0.27608>) Accepted connection {{10,0,17,246},42571} -> {{172,18,0,2},5222}
mongooseim_server_dev | 10:58:25.885 [debug] Received XML on stream = "���yw�\��.ndEt�;�����fn�A>� n:�=5��</A
"ngooseim_server_dev | ��kj98����g#32ED�(#
mongooseim_server_dev | 10:58:25.885 [debug] Send XML on stream = <<"<?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='2B421BCD2D077161' from='localhost' version='1.0'>">>
mongooseim_server_dev | 10:58:25.886 [debug] Send XML on stream = <<"<stream:error><xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>">>
mongooseim_server_dev | 10:58:25.886 [debug] Send XML on stream = <<"</stream:stream>">>
The Mongoose documentation does not offer me any solution and I do not see anyone with this error.
Any help or clue?
From your description and MongooseIM log snippet I reckon that the client is starting an encrypted connection from the beginning - that's why the "Received XML" seems to be garbage.
In XMPP an initially plaintext connection is upgraded to a secure connection using STARTTLS. This should work fine with ELB with TCP forwarding and no TLS termination, you just have to make sure the client is not trying to use SSL/TLS from the get go, but uses STARTTLS. All popular XMPP libraries should have this option, it's part of core XMPP.
[...] it is easier to put an ELB TCP to TCP and encrypt by TLS once the connection is open?
Exactly.
I mainly use an ELB to avoid having to handle SSL by myself and if I can not get it, would it be better to directly expose the mongoose server to the Internet?
ELB can't be used for SSL termination for plain XMPP. The available options are:
ELB forwards plain TCP, MongooseIM plain XMPP listener is used - Client opens a TCP connection but upgrades it via STARTTLS, all EC2 instances require cert provisioning.
ELB is set up for HTTPS termination, MongooseIM uses BOSH listener - BOSH is XMPP over HTTP, so has some overhead, but the benefit of SSL/TLS offloading might be worth it, no headache with certs on EC2 instances.
Related
I coded a server/client application which i ran first locally and then over the internet. Therefore i configured my router that it accepts data on port xxxx and forward it to my machine where my server runs and where it accepts connections from client sockets. So everything runs fine and the clients can send there messages to each other. So now my question is, how is it possible that the server can send data to the clients in other networks where port forwarding isn´t activated but when i try it manually it doesn´t work.
I already tried searching about how the TCP saves IPs and ports and I also looked up how the concept of the Internet/TCP/UDP works but couldn´t find an answer to the question.
So first of all I wanted to know that before I implement my server without port forwarding and it would also be appreciated if you could give code examples for c++ on windows if you have any ideas so that i can establish such connections without port forwarding and extern serverhosts on the internet.
Clint -> NAT (router) -> ... -> NAT (router) -> server
When client sends a message (it can be a connection attempt in case of TCP or just a message if it's UDP), its NAT doesn't block it and remembers which local address:port it's coming from and to which address:port it's going to: [client address:port, server address:port]. When the message hits server's NAT, the NAT knows about your server because you configured "port forwarding" and passes the message to local network. Now, when server sends message back to client and it reaches client's NAT, the NAT checks its internal table, finds a record for this particular server address:port, retrieves client address:port part and passes the message to it. So everything works as expected.
It's why usually when you open your browser and go to some web link, you receive server response with web page without problems despite you are behind NAT.
It's a simplified explanation which omits local/global address:port details.
I'm working on a server, which is listening on the port 80
I would like to enable both native and websocket clients to connect to my server.
It works only, if websockify runs at a different port, and forwards the trafic to the socket server.
Unfortunately websockify isn't well documented, and there are no tutorials available.
Where should I start, if I would like to create a single server only, which is listening on only one port, and accepts both websocket and native TCP sockets?
If your server is listening for connections on port 80, is it talking http? Because if not, don't be listening on port 80: Port 80 is well established as carrying http traffic.
Next - an ipaddress and port together are the unique identifiers of an endpoint. If a remote client connects to your server on port 80, other than the destination ip and port there is no other information that the networking layer has to identify which application, listening on port 80, deserves the packet. Given that provisioning multiple ip addresses is quite hard - impossible over a NAT - the only information thats really available to route the packet to the correct listener is the port. So you just can not have two applications listening on the same port.
Lastly websockets behave like native sockets, AFTER an initial HTTP negotiation. This means that, instead of using websocksify, you could teach your native server application to detect an attempt to connect by a websocket client and optionally perform the initial negotiation before going into 'native' mode.
Writing Websocket Servers gives a brief breakdown of what your native server would need to implement.
If you take a look of WebSocket, you will see that it's a protocol over TCP layer. Thus, your server socket can bind only once to the port 80 and it's up to you either you will use plain TCP, WebSocket or your custom protocol. There is no magic which enables switching from WebSocket to TCP and vice versa.
I did a lot of research for following matter and I got a lot of helpful information but the matter still remains, so I'm going to write it with full details
I'm trying to run "Remote Server Administration" with VisualSVN Server (Enterprise Edition), the server is Windows Server 2008 connected to the internet via router with port forwarding to this server. The client is not at local network so I use a static IP for the server.
Also I did every things written at this URL: http://www.visualsvn.com/support/topic/00025/
but I still get the following error message Connot connect to WMI namespace "..." : the RPC server is unavalible (0x800706ba) when I'm trying to "connecting to another computer".
On the other-hand, I can browsing the "Repositories" content by any web-browser successfully.
How can I manage the Repositories at remote servers?
"...the RPC server is unavalible (0x800706ba)" error indicates a connectivity issue to the remote machine.
Accessing WMI remotely requires port 135 TCP/UDP and all TCP ports above 1024 (1024-65535) to be opened (and forwarded), by default. You can setup fixed port for WMI to simplify the port-forwarding / proxy setup task. In order to setup the fixed port, follow steps described in the article "Setting Up a Fixed Port for WMI". After you follow these steps you are required to setup port forwarding and proxy rewrites (if any) for 135 TCP/UDP and port 24158 TCP.
"...Access is denied (0x80070005)" error indicates insufficient permissions to access WMI remotely. Add your user account to the local group on the remote machine: "Distributed COM Users".
When facing below situation what debugging tools/skills can we use to solve the problem? See the flow, we use port forwarding in NAT2 whose type is Symmetric so that the client can communicate with Server. When session between client and server is established, the client can send files to the server via TCP connections. The upload bandwidth is around 2Mbit/s.
The issue is while the client is uploading files to server, we found at some point all the TCP connections will be blocked, the server can't receive any packets from those TCP connections anymore so that all the tcp connections will be dropped by server application because of timeouts. NAT2 is a SO simple router that we can't capture packets from it, to get rid of this issue what can we do?
Client ----- NAT1 ---Internet----- NAT2 ----- Linux Server
UPDATE
Problem also exists in below topology. In this topology, the NAT between client and Linux server is also the NAT2 other than a different one, because the client use DNS name to access Linux server, thus all packets from client will go through NAT2 to the internet, but will come back to NAT2 again and be sent to LINUX Server by Port Forwarding in NAT2.
Here is another question: if there is some application persisting in sending packets to the forwarding port (we set Port Forwarding in NAT2, and suppose the port Number is PortN), then can it cause all the tcp connections which receive packets via this PortN to be blocked or to receive no packets within 3-5 minutes?
Client ----- NAT2 ---Internet----- NAT2 ----- Linux Server
How do I detect if a remote client is running Remote Desktop Protocol? and it is also accepting remote desktop connections ??
Like Open an port to detect HTTP and send request, receive request headers and see in request headers information about HTTP so I will know the person is running HTTP weather if he changed the port e.g: running HTTP 6551.
Attempt and make a connection with something that is RDP-connection aware (RDP is not HTTP). Of course, failing to establish an initial handshake is not proof that a connection can not be established. It could be blocked by a firewall, listening on another port, etc.
The MS-RDPBCGR specification, page 16 talks about connecting which in turn defers to X.224, go figure.
It'd likely just be easiest to use Wireshark and observe in-the-wild behavior to develop a minimal detection case. I suspect only the very initial portion of the handshake needs to be generated/replayed in order to "decide" that it's a listening RDP server.
(Or, perhaps use an existing RDP client which has this "test connect" functionality or the ability to be scripted.)
A fast way is to pen a shell and type
telnet IPADDRESS 3389
If you get a connection, chances are good that an RDP server is on the other side. RDP can run on any port, but TCP Port 3389 is set per default.
Windows 7 requires some extra steps to enable the telnet Client.
You could do netstat -a in the command line and see if the default port for remote desktop connection is listening, ie. TCP:3389 but thats only if the client hasn't changed the ports for MSTSC