Theoretical question about ports and ip filtering

Hello,
I have an almost existential question about tcp ports.

If you have a tcp server program (for example a web server) listening on
a port (80, for example), and a client connects, in a multi-threaded
system, the server passes the session with this client to a new process
using a different, dynamic port.

My question is: why is it not necessary to open this new server-side port
in the firewall? Any packets sent from the client (browser) to the server
from this moment on will carry the new port, right? I'm confused.

Thanks in advance,
Remko

On Friday 12 September 2008 13:00, remko wrote:
[color=blue]
> Hello,
> I have an almost existential question about tcp ports.
>
> If you have a tcp server program (for example a web server) listening on
> a port (80, for example), and a client connects, in a multi-threaded
> system, the server passes the session with this client to a new process
> using a different, dynamic port.[/color]

No, it still uses port 80. The client must continue to see its connection as
being to port 80.

On Sep 12, 12:00*pm, remko <remko.dob...@ya.com> wrote:[color=blue]
> Hello,
> I have an almost existential question about tcp ports.
>
> If you have a tcp server program (for example a web server) listening on
> a port (80, for example), and a client connects, in a multi-threaded
> system, the server passes the session with this client to a new process
> using a different, dynamic port.
>
> My question is: why is it not necessary to open this new server-side port
> in the firewall? Any packets sent from the client (browser) to the server
> from this moment on will carry the new port, right? I'm confused.
>
> Thanks in advance,
> Remko[/color]

I think you are confusing port and socket...

remko wrote:
[color=blue]
> Hello,
> I have an almost existential question about tcp ports.[/color]
[color=blue]
> If you have a tcp server program (for example a web server) listening on
> a port (80, for example), and a client connects, in a multi-threaded
> system, the server passes the session with this client to a new process
> using a different, dynamic port.[/color]

Huh? The connection is still *TO* port 80. A multi-process server may
have two sockets, one referring to the listening on port 80 and one
referring to the accepted connection. But the connection is to port 80
and the server is listening on port 80.
[color=blue]
> My question is: why is it not necessary to open this new server-side port
> in the firewall?[/color]

What new server-side port? I thought the connection was to port 80.
This means that the server-side port is 80.
[color=blue]
> Any packets sent from the client (browser) to the server
> from this moment on will carry the new port, right? I'm confused.[/color]

Huh? The packets are, were and always will be *to* port 80 as far as
this machine is concerned. They will also carry a source port that
will not (usually) be 80. But the firewall triggers on the destination
port (or tracks each connection separately).

I'm not sure if you're confusing source ports and destination ports or
ports and sockets. Maybe a little of both.

1) Its ports on the wire and sockets on the computer. You may have a
socket that refers to the fact that you're listening to port 80. You
may have eight sockets for each of eight connections you've accepted
on that port.

2) Every TCP packet has both a source port and a destination port.
Typically, the destination port (as seen on the server) is the well-
known port the server listens on. Typically the source port (as seen
on the server) was 'randomly' chosen by the client.

DS