Transport protocol agnostic way to multiplex ports and forward metainfo?

--hQiwHBbRI9kgIhsi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

Word of caution: I reference netfilter in this email, please bear with=20
me.

I would like to create a network service that is available on multiple=20
ports on multiple transport protocols.
Since opening a lot of ports on the application layer is inefficient, I
would prefer to multiplex on the network layer, like this:

                       +----- pf
                       V

--> TCP port 1001 -->--+
                       |
--> TCP port 1002 -->--+--> TCP port 1001
                       |
--> TCP port 1003 -->--+

                       +----- pf
                       V

--> UDP port 2001 -->--+
                       |
--> UDP port 2002 -->--+--> UDP port 2001
                       |
--> UDP port 2003 -->--+

[Same possibly for SCTP, DCCP, ...]

Additionally I would like to be able to know in the application on which=20
port the connection reached the system originally.

I am aware of the following mechanisms that allow what I want to do in=20
netfilter on linux:

For TCP: Using a REDIRECT rule with a port range and getsockopt with
         SO_ORIGINAL_DST.

For UDP: Using a TPROXY rule with a port range and recvmsg, then consume
         ancillary message that is provided

For SCTP, DCCP, others: I don't know a way to do that in netfilter.

With pf, I don't know what the options are that I have.

So, my question is: In pf, is there a transport protocol agnostic way to
multiplex ports to an application, enabling the application to know on
which port the connection came in?

Any advise appreciated.

Kind regards,
-Alex



--hQiwHBbRI9kgIhsi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJa6JNVAAoJEMs95f4AHXa3i5sP/2IzcK0DnXrGcrZOX8pnxGBR
3wtOpx6U/cDovwnMY+SpPhmsXaoJHAfAM/yhVKZw6qRQEhQYLGL8AOXhzPm33/+E
f0OyCBZyqxTyJMROwNvKUtohdHb+sPV9CNO4T235BoKJM+K8hW4RNfYxNrrACc3k
SlBwCYSysAEHeaXWMm9CFYz5X979Ry4jmXuSD/dOt1BR9dG+E6ngIhtk3z+Heqxu
WgD64cUQMcNgG3n8zF01TQ6DgB2Xb7/KWXkLX2uMSaqMgabKn9W1C8fw19tseagJ
M9low6KPPgeHyi7j0jcIWNxqZ7yZuzQv9CsZP1C7cKzXfvW3aioL7ik8JjBkicvL
QOBPhsDoLyuHtmR+hMjmMEKkcXZHLOEwxwbx3+/nwwm7EBJrdN4AtuwUBEIr2Nbj
JlNgfLA8RH6vyogo53W+usHb0MEZx18M3vpnLMj291HOjjsWVC+Qgb0mDfhOtZhg
ar3JWDSdo0zYPliSGKRrU1NZmeaQZvVd3eiBkDkDEJb/w+gNH3zWH5ERX3AvbS87
C3eddWyPHsvRSPBI1BbgDrugC2pL+qOt0FHDnE22IQSso0PxnySttk7Jy7jS1261
8eLO3Fl29xTohYzozIcFciBFaJ0IgihCX1CdI1Qq3FGFZzz+GsQ7/jHg8yitMCxI
GRj1qXD/WkN63biN7e0k
=7LDn
-----END PGP SIGNATURE-----

--hQiwHBbRI9kgIhsi--