Jump to content

Ports and incoming connecitons


Recommended Posts

Just a quick query.. hoping someone can enlighten me...

Services on a local server will be available through certain ports, but do the connecitons trying to be established from remote pcs use the same ports?

The reason I aski, is Ive been monitoring connecitons from my local pc to my server (on internal network), in order to customise some firewall rules.

I have created a rule to allow several ports access on both local and remote conneciton, yet the incoming connection is blocked due to the following and final rule which is to block all... obvoulsy. If I check the logs out, the remote pc is trying to connect using other ports, to the same port on the server...

For example, If I allow a connection using port 55000 on both local (this is the portt the service is running on) and remote, the conneciton is blocked as the remote pc may be trying to use different ports to establish the conneciton... So I may get the conneciton is blocked from remote pc ip, port 1020, so if I then add this port, it will than say it is blocked on port 1021, then 1022.. etc as if the remote pc is trying another of its ports, despite the fact it is only trying to connect to port 55000 on the server....

Does a conneciotn from a remote pc have to use the same port that is is trying to connect to?

Link to comment
Share on other sites


No, the client PC doesn't use the same source and destination port numbers when connecting to a service.

Let's pretend you were connecting to a web server, using plain old HTTP, to request a web page, on port 80 as usual. It would go something like this:

Your computer sends a SYN to destination port 80 of the server, but with a different source port (let's say 12345 -- it's as good as any other number really), and then you reuse those: the server sends it's SYN/ACK from port 80 to your port 12345, then your computer sends ACK (still src port 12345, dst 80). Now that the TCP handshake is done, your computer makes the HTTP GET or POST request itself (same ports yet again), and the answer from the web server (e.g. HTTP/1.0 200 OK) is just like its SYN/ACK packet (src 80, dst 12345). The client never actually receives data on port 80 at any point in the process.

I hope that helps.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...