i'm confused about TCP connection through firewall.
Source Port(client) is 12345 and dest port(server) is 1433.
At the begining, client successfully sends the request to server from 12345 to 1433. When server sending back, does the client require to open port 12345 in Firewall?
If yes, it's hard to configure all ports since source port is dynamic.
Best Regards,
Tom
When server sending back, does the client require to open port 12345 in Firewall?
No. If the client's firewall permitted the outbound connection, it will permit the return traffic.
If yes, it's hard to configure all ports since source port is dynamic.
Impossible, actually.
Of course there are always ways to mis-configure firewalls ...
Related
Consider a server socket and a client socket.
The server socket endpoint is identified by the pair (IP/ Ws.Xs.Ys.Zs, TCP port/ Ps).
When the client socket initiates a connection with the server socket, the client endpoint gets associated with the pair (IP/ Wc.Xc.Yc.Zc, TCP Port/ Pc).
The client socket is a "Winsock".
On the client machine, outbound traffic for port Ps is NOT blocked.
At connection time, Pc is automatically chosen in the pool of ephemeral/dynamic ports of the client machine.
The client socket sends a message Mc to the server socket.
The server socket responds and sends a message Ms back to the client socket.
This message will be addressed to the endpoint identified by (IP/ Wc.Xc.Yc.Zc, TCP Port/ Pc).
Is there a way I can block this message Ms by setting up a firewall rule in the "Inbound" section of the firewall on the client machine?
I have tried to set up such a rule but it seems not to block anything:
In the Windows firewall, in the "Inbound" rules section:
- "New Rule..." -> "Port"
- TCP
- Specific local ports: 49152-65535
(This is the dynamic ports range on the client machine (given by the command "netsh int ipv4 show dynamicport tcp")).
- Block the connection
- When does this rule apply? I checked: "Domain", "Private" and "Public".
Why is it not working? Why is Ms not rejected by the firewall?
Is it because of the socket implementation? Something like: if the client socket could actually send its message to the server socket then the response from the server has to be accepted on (IP/ Wc.Xc.Yc.Zc, TCP Port/ Pc) even if there is a blocking rule in the firewall?
Or maybe, the rule I'm setting above is not actually blocking what I think it is blocking...
Thank you for helping.
Best regards.
A firewall blocks connection attempts, not individual packets. An outbound filter prevents an outbound connection to a remote server, an inbound filter prevents an inbound connection to a local server.
Besides that, a "message" may require more than one packet be transmitted, or may be grouped with other "messages" in a single packet.
So no, once a connection has been successfully established, a firewall cannot block specific "messages" being transmitted over that connection. The connection has already been trusted, the firewall does not analyze and filter the connection's content.
Usually a web server is listening to any incoming connection through port 80. So, my question is that shouldn't it be that in general concept of socket programming is that port 80 is for listen for incoming connection. But then after the server accepted the connection, it will use another port e.g port 12345 to communicate with the client. But, when I look into the wireshark, the server is always using port 80 during the communication. I am confused here.
So what if https://www.facebook.com:443, it has hundreds of thousands of connection to the it at a second. Is it possible for a single port to handle such a large amount of traffic?
A particular socket is uniquely identified by a 5-tuple (i.e. a list of 5 particular properties.) Those properties are:
Source IP Address
Destination IP Address
Source Port Number
Destination Port Number
Transport Protocol (usually TCP or UDP)
These parameters must be unique for sockets that are open at the same time. Where you're probably getting confused here is what happens on the client side vs. what happens on the server side in TCP. Regardless of the application protocol in question (HTTP, FTP, SMTP, whatever,) TCP behaves the same way.
When you open a socket on the client side, it will select a random high-number port for the new outgoing connection. This is required, otherwise you would be unable to open two separate sockets on the same computer to the same server. Since it's entirely reasonable to want to do that (and it's very common in the case of web servers, such as having stackoverflow.com open in two separate tabs) and the 5-tuple for each socket must be unique, a random high-number port is used as the source port. However, each of those sockets will connect to port 80 at stackoverflow.com's webserver.
On the server side of things, stackoverflow.com can already distinguish between those two different sockets from your client, again, because they already have different client-side port numbers. When it sees an incoming request packet from your browser, it knows which of the sockets it has open with you to respond to because of the different source port number. Similarly, when it wants to send a response packet to you, it can send it to the correct endpoint on your side by setting the destination port number to the client-side port number it got the request from.
The bottom line is that it's unnecessary for each client connection to have a separate port number on the server's side because the server can already uniquely identify each client connection by its client IP address and client-side port number. This is the way TCP (and UDP) sockets work regardless of application-layer protocol.
shouldn't it be that in general concept of socket programming is that port 80 is for listen for incoming connection. But then after the server accepted the connection, it will use another port e.g port 12345 to communicate with the client.
No.
But, when I look into the wireshark, the server is always using port 80 during the communication.
Yes.
I am confused here.
Only because your 'general concept' isn't correct. An accepted socket uses the same local port as the listening socket.
So what if https://www.facebook.com:443, it has hundreds of thousands of connection to the it at a second. Is it possible for a single port to handle such a large amount of traffic?
A port is only a number. It isn't a physical thing. It isn't handling anything. TCP is identifying connections based on the tuple {source IP, source port, target IP, target port}. There's no problem as long as the entire tuple is unique.
Ports are a virtual concept, not a hardware ressource, it's no harder to handle 10 000 connection on 1 port than 1 connection each on 10 000 port (it's probably much faster even)
Not all servers are web servers listening on port 80, nor do all servers maintain lasting connections. Web servers in particular are stateless.
Your suggestion to open a new port for further communication is exactly what happens when using the FTP protocol, but as you have seen this is not necessary.
Ports are not a physical concept, they exist in a standardised form to allow multiple servers to be reachable on the same host without specialised multiplexing software. Such software does still exist, but for entirely different reasons (see: sshttp). What you see as a response from the server on port 80, the server sees as a reply to you on a not-so-random port the OS assigned your connection.
When a server listening socket accepts a TCP request in the first time ,the function such as Socket java.net.ServerSocket.accept() will return a new communication socket whoes port number is the same as the port from java.net.ServerSocket.ServerSocket(int port).
Here are the screen shots.
I'll be using JavaPNS to implement my server side of things of the push notification service. I don't have control over what ports are open on the server, but assuming that all ports are open for outbound connections, do I have to also open port 2195 for inbound connections? Correct me if I'm wrong, but my understanding of TCP is that when I make the connection with the Apple server, a source port is randomly assigned to any port not being used and when the Apple server responds (the inbound connection), it will come through that source port. So, my theory is that port 2195 does not need to be open for inbound connections. Is that right?
Also, if the response comes through the random port, doesn't that mean that that port needs to be open to inbound connections? How does the firewall manage this since only a few ports will be indefinitely open for inbound connections? Does it leave the random port open only temporarily for this specific request-response session?
You only need port 2195 to be open for outbound connections (and also port 2196 for the Feedback Service).
You don't have to open any port for inbound connections, since Apple doesn't initiate the connection to your server - your server initiates the connection to Apple.
I need to accept only connections from particular client ip address at server side. Should not use acl. With help of socket strict bind at server side can i do?
Example:
client ip address: 1.1.1.1
server ip address: 1.1.1.2
At server side:
1. Open a socket
2. Bind socket with 1.1.1.1(client ip address) with port no.
Will i be allow to do the second step at server side? Any special options are there to do?
Please let me know.
Thanks,
Boobesh
You can only bind the server port to an ip address to specify the interface to use.
For example your server has two network interfaces, one connected to the internet and one to a configuration network. The webserver should maybe only listen on the internet interface and a management tool only listen on the configuration network.
For your purpose you can accept the connection, compare the ip address and if it is not in the list of allowed clients close the connection immediately (or after sending an error message).
The other solution would be to use a firewall that is configured to allow only connections from the specified clients to the server port.
I agree with the friend above, u can only manage the ip and port in you server, but not client. u should compare the coming socket with the one u store in your server.
After many hours, I have discovered that the given udp server needs the following steps for a successful communication:
1- Send "Start Message" on a given port
2- Wait to receive from server on any port
3- Then the port dedicated to you to send further data to the server equals the port you have received on it + 1
So I am asking if this kind is a known protocol/handshaking, or it is only special to this server??
PS: All above communication were in udp sockets in C#
PS: Related to a previous question: About C# UDP Sockets
Thanks
There's no special "handshake" for UDP -- each UDP service, if it needs one, specifies its own. Usually, though, a server doesn't expect the client to be able to listen on all of its ports simultaneously. If you mean that the client expects a message from any port on the server, to the port the client sent the start message from, then that makes a lot more sense -- and is very close to how TFTP works. (The only difference i'm seeing so far, is that TFTP doesn't do the "+ 1".)
The server is, effectively, listening on a 'well known port' and then switching subsequent communications to a dedicated port per client. Requiring the client to send to the port + 1 is a little strange
Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 5050
Client 192.168.0.1 - port 12121 <------------------------ Server 192.168.0.2 - port 23232
Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 23232 + 1
<------------------------ Server 192.168.0.2 - port 23232
------------------------> Server 192.168.0.2 - port 23232 + 1
The server probably does this so that it doesn't have to demultiplex the inbound client data based on the client's address/port. Doing it this way is a little more efficient (generally) and also has some advantages, depending on the design of the server, as on the server there's a 'dedicated' socket for you which means that if they're doing overlapped I/O then the socket stays the same for the whole period of communications with you which can make it easier and more efficient to associate data with the socket (this way they can probably avoid any lookups or locking to process each datagram). Anyway, enough of that (see here, if you want to know why I do it that way).
From your point of view as a client (and I'm assuming async sockets here) you need to first Bind() your local socket (just use INADDR_ANY and 0 to allow the OS to pick the port for you) then issue a RecvFrom() on the socket (so there's no race between you sending data to the server on this socket and it sending you data back before you issue a recv). Then issue a SendTo() to the 'well known port' of the server. The server will then send you back some data and your RecvFrom() will return you the data and the address that the server sent to you from. You can then take that address, add one to the port, store that address and from then on issue SendTo()s to that new sending address whilst continuing to issue RecvFrom()s for reading the server's data; or you could do something clever with Connect() to bind the remote end of the socket to the server's 'send to address' and simply use Write() and RecvFrom() from then on.