in reply to Re: Re: Re: Re: Re: Remote TCP Port Connection Monitoring
in thread Remote TCP Port Connection Monitoring

Here is how a TCP connection gets established. Lets use port 80 for example. Client connects to server on port 80. Server accept conn and responds saying let's talk on port 12345. This is required so that the server can get rid of the client on port 80 to allow it to accept other connections on port 80 while still talking to the client.

that is plain wrong. while some things do negotiate a new port to use for further communication, most do not. doing so makes it extreemly hard to get through firewalls. if a server is going to listen on 80 and then ask client to use 2000-3000 then thats alot of ports that have to be passed inbound by the firewall.

the unique identification of a TCP Session is based on a 4-tuple. (local-ip, local-port, remote-ip, remote-port) that in itself is enough to allow the server to easily talk to multiple clients over the same server side port.

192.168.0.230.22 192.168.0.230.46928 73620 0 65440 0 ES +TABLISHED 192.168.0.230.22 192.168.81.3.53022 63504 0 63720 0 ES +TABLISHED

these are two of my ssh sessions, the client end is random picked port, the server end is always 22. there is no reason to force an incoming client to go to a port other than 22.

now FTP is one of those programs that can use a port in addition to the regular ports, but it's not required. and using a third..nth extra ports is what makes FTP a pain to get across firewalls if you use that functionality.