Add ability to "bind specific" most TCP/IP servers and clients

Rob, i am not sure about all the use cases...

a) you have multiple IPs in the same network - are they bound to the same *LIND (physical interface?) What is the use of this?
b) as mentioned by IBM, to select client outgoing IP addresses, you should use multiple IPs in different networks and select host routing for divided host/client connection pairs.
c) Packet Rules can be used for outgoing connections by denying and then allowing specific connections sets...

Can packet rules restrict clients coming out of the IBM i to a particular IP address?
For example if I use FTP from my IBM i to some outside service and the IBM i has the following interfaces: 208.x.x.1, 208.x.x.2, 208.x.x.3 can I ensure that the FTP client from my IBM i only uses 208.x.x.2?
I read the documentation provided and it seemed more intent on people trying to get IN to your IBM i than OUT of your IBM i.

IBM does not intend to provide a new solution to this request at this time, so it is being closed.

A Host route is the solution for client side.
IP Filtering is the solution for server side. IBM published an article entitled "Restricting IP interfaces used by servers" that describes how to use IP Filtering for this purpose.
https://www.ibm.com/support/pages/node/1283620

We need to keep in mind that this is when IBM i is acting as the client, not the server. For example, IBM i initiates communication to another device. A more detailed example is IBM i, in our DMZ, is using QNTC to communicate with several PC based file servers located in our internal network. Our firewall in between the DMZ and our internal network is expecting this traffic to originate off of IP address x.x.x.2 but QNTC randomly picks x.x.x.11 out of the list of interfaces supported by that lpar.

The CAAC has reviewed this requirement and views this as a high priority requirement that is important to be addressed.

Dawn May - CAAC Program Manager

It (IFS stream file) would be stored in human readable form, true? Yes, you would be editing this file directly with your favorite editor. The file will include commented out example(s) of valid records/lines.

IBM will use this request for server side support as input to planning but no commitment is made or implied. This request will be updated in the future if IBM implements it.

IBM will use other customers' votes and comments to help prioritize this request.

For client connections, if servicing a client with multiple functions on one LPAR where those functions are sharing the same server IP address, why is it desirable to use separate client addresses when connecting to those functions? If the LPAR has separate IP addresses for the different server functions, then host routes still work to select a different client address if that's desired.

Since it would be in an IFS stream file I suppose I could view it using DSPF or EDTF. It would be stored in human readable form, true?

Using strict routing rules to force TCP/IP clients out specific IP addresses will probably not work. Some people in the industry and I discussed this and it poses problems when servicing one client with multiple functions from one lpar. For example, Domino and ftp coming from the same lpar.

For server applications, does this basic solution satisfy the core requirement?
One IFS configuration file processed during STRTCP. ENDTCP/STRTCP required to activate a change to the file.
The configuration file contains TCP port number(s) and the IP address(es) that the ports are to be restricted to use.
No programmable way to observe the restrictions though manually observable using System Service Tools

For client applications, the issue described in the requirement can be addressed today using a more-specific subnet route or host route. That route can be bound to the specific interface that the client accepts and then all connections initiated from the system to that client will use the correct IP address.

Is the real issue for CIMOM that it isn't using the same certificate as Domino? Or that the certificate it uses doesn't have the right FQDN?
The issue is probably that the certificate doesn't have the right FQDN.
We use a generic *.domino.com certificate. This doesn't match the CIMOM certificate.
Here's another issue. At one time we did multihosting.
x.y.z.31 - Domino server pvccompounders.com
x.y.z.32 - Domino server fwpsg.org
x.y.z.33 - Domino server dekko.com
x.y.z.34 - oakfarmschool.org
x.y.z.35 - general IBM i kind of stuff
And all these addresses appeared on CFGTCP, 1. Work with TCP/IP interfaces

And some of these came into the same domino server but used different 'internet sites' documents.
So sharing a certificate between cimom and Domino may not always be feasible.

The restriction does not have to be dynamic. If I have to ENDTCPSVR *TELNET, make the change, STRTCPSVR *TELNET then that is acceptable.

I would really like to be able to see the currently restricted interfaces. How do envision that working?
- netstat *cnn?
- IBM Navigator for i version of netstat *cnn?
- 'assume' that any setting in a myriad of .properties files scattered throughout the system are what is currently in use?

We also have an issue when we issue (from our IBM i), an ftp script to download something to a particular client. The client only accepts from one IP address and when the ftp client picks one at random it causes us issues.

At times I can see the pros and cons of having telnet on one port and then on more than one port.
More than one port: When you are running in a HA environment (like Mimix) and your primary address is down but you need to access it using your Mimix back door IP address to fix an issue.
One port: Well, I'm probably confusing certificates with SSH here. But if I telnet to MyDominoServer via SSH is that going to be an issue?

In order to use this request as input to planning, additional details are required.

Please explain how you see the ability to restrict an outbound client connection's interface selection working.
- Host routes bound to a local interface do not work?

Is the real issue for CIMOM that it isn't using the same certificate as Domino? Or that the certificate it uses doesn't have the right FQDN?

If there was a system wide property stating only X, Y, and Z interfaces are allowed to be used by applications, what is the reason for having interfaces not part of XYZ started? Are you requesting two system wide properties, one for servers and one for clients?

Is the ability to see the currently restricted interfaces important/critical?

Is enablement of the interface restrictions at TCP/IP start time adequate? Or enablement must be dynamic?

Should this restrict clients/servers that don't bind to a specific interface address (i.e. INADDR_ANY or in6addr_any) or should it also block a client/server that explicitly binds to a specific interface address?

Does UDP traffic also need to be restricted?

This request breaks down into multiple sub-elements. Beyond the above questions, any additional information on the sub-elements would be appreciated. Please place the list in order of importance to you adding or changing list elements as needed.
- Restrict CIMOM with Telnet/FTP nice to be able to restrict too
- Restrict all servers to specific interfaces
- Restrict some servers to specific interfaces
- Restrict all clients to specific interfaces
- Restrict some clients to specific interfaces
- Change the certificate used by CIMOM to be the same as Domino
- Restrict UDP inbound
- Restrict UDP outbound

Creating a new RFE based on Community RFE #88068 in product IBM i.