My first thought is that putting all of your instances on the same cluster may not be a good idea. It sounds like you have one database that you need accessible by the outside world and another database that is used only internally. If that is the case, then I would separate these. I typically work where we have 3 "zones" in our network. There is the zone that is accessible by the general public. Our external web server would be placed there, for example. Then there is the zone that is accessible only internally in our company. Then there is the middle zone that is restricted to some external entities and not globally accessible. I call this middle zone the DMZ. I would place the database that is accessed by clients through the firewall in the DMZ. If your clients have access to this database server, then their systems do and if they have a security breach they could potentially be allowing access to the database server that has the instance you don't want them to be able to access.
That being said, you could set up 2 listeners and allow them access to only the listener on the other port. You may also want to have this listener configured with valid node checkign. See Note 462933.1 for details.
There are a number of considerations.
The TNS connection string requests a connection to a service. That service can have multiple endpoints (supported by a number of instances, and registered with the listener by these instances).
You can thus connect to server1 public static IP, on port 1521, and request a connection to service dbname1. But as dbname1 has been registered by all RAC servers, and as the Listener also has port 1527 as tcp listener endpoint, and as a number of static and virtual IP addresses are used - your client could very well be redirected by the listener to database instance 5 on server5, via a virtual IP, and on port 1527.
So a connection request by the client on port 1521 to server1, does not mean that this is where the actual Oracle client-server session is going to terminate.
If you expect the tcp port to be static, the listener should only be listening on a single port. I have seen listeners configure for multiple ports (e.g. 1521 and 1527), with only one port opened via a firewall, resulting in intermittent connectivity - as every other connection will get a redirect to the other port.
The listener also hands out hostnames (assuming a proper listener.ora and network config) when redirecting a client connection. E.g. you connecting to hostname server1 and getting a redirect to server5.
If server1 is the only IP accessible via the current network (firewall, etc.), then one can address the redirect on the client - by resolving all hostnames passed by the listener to the IP that works. E.g. local client hosts file resolves server1 to server5, and server1-vip to server5-vip, to that single working IP address.
If you want a client to be able to select a specific RAC instance to connect to (or force connections to a single specific instance), you can use the SERVICE_NAMES parameter. This is by default set to db-name and db-domain across RAC instances. This means all RAC instances register the same service with the listeners. Enabling a client connection for that service to be handled by any RAC instance (high availability etc).
You can also add, per RAC instance, a unique service only for that RAC instance. This service will thus be registered by a single RAC instance, and client connections requesting that particular service (connecting via SCAN or other RAC listeners), will always be redirected to that instance.
In the scenario you described, I would not use a secondary listener. I would use a unique service name to restrict those client connections to a single specific RAC instance and server hostname/IP. I would not use multiple tcp ports as listener endpoints. And then request that IP and port to be opened on the firewall, and providing that service name to clients connecting via the firewall.