netdev - Re: any way to let host act as TCP server OR client on same IP/port?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4E1F2887.4040307@genband.com>
Date:	Thu, 14 Jul 2011 11:33:59 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Rick Jones <rick.jones2@...com>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: any way to let host act as TCP server OR client on same IP/port?

>>> In our case we don't need to actually be connected, just be listening
>>> and ready to either accept() a connection or connect() to someone else.
>>
>> It turns out that the application people really do want the server side
>> to be able to listen() at the same time as calling connect() from the
>> same address/port, so Rick's testcase was accurate.
>
> So, we are left asking "Why do the application people want that?" Does
> the server connect() to pseudo-random places, or does it only ever
> connect back to clients which have already connected to it?

I'm not an expert in the application domain, but here's what I know. 
You can think of the situation as having a server, a gateway, and many 
clients.  The goal is to map each client to a single unique port on the 
server-facing side of the gateway, such that all traffic for that client 
goes through that port.

The complicating factor is that traffic may be initiated by either the 
client or the server.  With UDP this isn't a problem, but for TCP it's 
tricky.

For IPv4 the app team originally set it up so that the gateway listens 
on a single port on the server side of the gateway, and when the server 
opens a connection to a client's unique port (with an ephemeral port as 
the source port) it gets NAT'd to that single port.  (The unique ports 
on the server side ensure that there are no 4-tuple collisions.)  For 
traffic originating from the client, the gateway binds a socket to the 
client's unique port and uses it to open a connection to the server.

IPv6 doesn't support NAT (at least not in the stock kernel), so they're 
looking for alternatives.

> If the desire is to have the same well-known port number involved in all
> connections to/from the server (perhaps for simplistic firewall rules
> involving serverip.magicport?)

I suspect it's something like that.

> then if the connections are back to the
> clients, the clients could simply open listen endpoints bound to the
> magic port number and the firewall rule become "server IP is source or
> destination) AND (magic port is source or destination)" - assuming the
> clients aren't bind()ing to the magic port number before connect()ing to
> the server.

We don't control the server, only the gateway.  Ephemeral source ports 
are used for connections opened by the server, so a known port is needed 
on the gateway side.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@...band.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html