MQTT work on TCP means it needs continuous connection, so how it works behind the firewall. is this keeps connection open all the time then how its safe for security purpose.
The MQTT client will open a persistent connection to the broker for the life time of the session.
Assuming the client is "behind" the firewall and the broker is "open" then this should work fine as long as the firewall allows outbound connections on port 1883.
Related
The goal is to make an http request from the client browser to my server. Simple stuff; however I'm hitting a wall with the networking portion. In order to expose my server to WAN I have used one of my public IPs and NAT to translate to the private ip of my server on inbound traffic and to my public IP on outbound traffic.
The issue is that I can't make a connection. Specifically I can't get the last part of the TCP handshake. Using a test setup with Wireshark on the client and server I can see that the client send the SYN -> the server receives the SYN -> the server sends a SYN/ACK -> the client receives a SYN/ACK -> the the client send an ACK -> the server DOES NOT receive the ACK. It waits for a moment then does a retransmission. Eventually resetting.
I have tried adding various firewall rules even though I don't think it could be the firewall because the first packets make a successful round trip.
I've turned windows firewall off(the server)
I've tried disabling TCP checksum offloading
I've looked for network anti virus settings on the server and on the sonic wall(the router)
I would expect the the tcp connection to complete. I can't for the life of me think of a reason why the ACK would consistently go missing.
That is another thing. The behavior is consistent.
pings also work just fine.
NOTE: The server is actually a VM and the physical server that manages it is in my network.
Any guidance on what to try and where to look would be very much appreciated. Thanks.
UPDATE: I can make connection using port 5000(It's another port I have opened on the firewall). Port 80 still doesn't work though.
In my case this was caused by COX not allowing inbound traffic to port 80. I'm not sure why the first portions of the tcp handshake were getting through. If anyone can explain that part leave a comment.
When we open a TCP Listening, we use a fixed port, like "9870".
But the clients which connect to this listening, use different ports like "1024, 1025" or other. I don't know what is the name of this port, "client port", "dynamic port" or "ephemeral port"... But I need to know if is possible to change this client port.
Because, like in the second image, it shows the error "Port numbers reused", and I think this is related to this port configuration.
I think if I could configure these ports, the connections of the equipments on my network will be stabilized.
TL;TR: there is usually no need to configure the clients source ports and you can definitely not set the clients source port at the server.
The client can bind to a address+port the same way the server can do and this port is then used as the source port for the connection. But usually this is not done and instead the socket is not specifically bound and a free source port is automatically assigned by the system. The client source port can only be set by the client itself and can not be changed by the server.
Usually it is not possible that a port number gets reused by the client since the OS will not let the client do this. But what you see can happen if the client crashes . After the restart the client is not aware of any connections which were established (and never closed) before the reboot so it will happily use the same source port again. In this case it gets a RST from the server since the new data do not match the old connection.
This can also happen if the client is connected with some router doing NAT and the router crashes. After restart the router is not aware of any previous connections and will thus create new translations which might conflict with old connections.
Ive build a local multiplayer game (multiplayer over wlan network). Now, I want to add an online multiplayer feature..
Currently, the network communications consist mostly of "signals" (tcp/udp packets sent from game-host peer to the game-client peers). I would like to use this mostly signal based communication for my online multiplayer (because of performance and efficiency ), too . But, since the host peer is now replaced by a server there will be a lot problems with sending signals (NAT, firewall,...).
So is there good solution to implement these signals?
regards
there will be a lot problems with sending signals (NAT, firewall,...)_
What problems exactly?
Normally, the clients establish a TCP connection to the server and the server uses this TCP connection to communicate with the clients.
For UDP-based communication the clients use Internet Gateway Device Protocol to forward ports on the router, so that the server can send UDP datagrams to the clients.
Assuming your server is in public internet, not behind any NAT. All the clients must initiate the connection. Otherwise the server can't know clients credential and can't connect. As the server has no NAT it will accept connection from client. And this connection client must keep alive. So when server needs to send some data there should be no problem.
This will work for both UDP and TCP.
I have around 20 clients communicating together with a central server in the same LAN. The clients can make transaction simultaneously with the server. The server forward each transaction to external appliance in the network. Sometimes it works, sometimes my application shows a "time out" message in a client screen (randomly)
I mirrored all traffic and found TCP Retransmission after TCP Reset packets for the first TCP Sequence. I immediately thought about packet loss but all my cables/NIC are fine, and I do not see DUP ACK in the capture.
It seems that RST packets may have different significations.
What causes those TCP Reset?
Where should I focus my investigation: network or application design ?
I would appreciate any help. Thanks in advance.
Judging by the capture, I assume your central server is 137.56.64.31. What's happening is the clients are initiating a connection to the server with a SYN packet and the server responds with a RST. This is typical if the server has no application listening on that particular port e.g. the webserver application isn't running and a client tries to connect to port 80.
The clients are all connecting to different ports on the server, which is unusual for an central server, but not unheard of. The destination ports the clients are connecting to on the server are: 11007, 11012, 11014, 11108, and 11115. Is that normal for the application? If not, the clients should be connecting to whatever port the application server is listening on.
The reason for the retransmits is that instead of giving up on the connection upon receiving a RST from the server, the client tries to initiate the connection again so Wireshark considers it a retransmission.
(I have not put code in this question since the actual code probably doesn't matter here. If you say it does though then I can edit the question later to put it in.)
I'm new to using winsock2 or any other networking API for that matter. I have a very simple server application and client application in which the server sends a string to the client and then disconnects.
The applications work fine when I use localhost or 127.0.0.1 as the inet_addr() argument, but when I use my "real" IP, the client application just gets WSAECONNREFUSED and the server doesn't see it. I made sure that the port was the same for both applications and that also the protocol was the same.
[Edit] I have come back to this issue after abandoning networking for a while. I think this may actually have something to with the fact I am using a router, and not something in my code.
WSAECONNREFUSED is an active refusal of the connection by the peer or by an intermediate firewall. If it was the peer who issued it, it means you got the IP address or the port wrong, or else you got it right but the server isn't actually running; anyway, nothing is listening at that IP:port. If it was the firewall, adjust it.
Did you use htons() on the port number?
inet_addr() only works with IP address strings, you have to use gethostbyname() or getaddrinfo() to resolve localhost or any other hostname string to an IP address.
WSACONNREFUSED means the connection was actively refused on the remote end that you are trying to connect to.
If the server machine is refusing, that means either there is no socket listening on the requested IP:Port, or that there is one but its queue of pending client connections is full so it cannot accept a new connection at that moment.
If a router is refusing, that usually means the router is not configured to forward inbound connections for the requested IP:Port to a machine on the router's network. If you have a server running behind a router and are trying to connect to it using the router's public IP address, then the router has to be setup for port forwarding.
If a firewall is refusing, that usually means the requested port is not open.
Either way, there is no way for the client to know in code why the connection was refused. All it can do is wait for a period of time and then try again.