Network administrators like to know exactly what ports your software will listen on, so that they can open only the required ports on the firewall defending their network from intrusion attacks. Protecting a network is all about knowing where an attack could come from. If your network, via its firewall, will never expect traffic on port 699, then if you ignore, discard or actively refuse all traffic requesting or transmitting on that port, an attacker can’t get in to do his dirty deeds dirt cheap.

Your dynamic port scheme leaves the selection of the port up to the OS. If the OS can choose any non-reserved port for your service, then your network admin must keep all of those ports open between any two network addresses that may be using your software to communicate.

A “trusted” network environment is a misnomer. Most things you “trust” in IT security are things that are simply infeasible to not trust, or for which the reasons for your trust extend beyond the boundaries of the digital world. You may, for instance, have been given a public key certificate “offline” (via thumb drive, etc) and told it belongs to a particular website. By installing said certificate, you tell your computer that you trust the assertions made by the person who gave it to you. The computer then trusts your own judgement, but verifies that the certificate presented by the website matches exactly the cert it was told to trust.

To the case in point; your heavily-firewalled LAN is “trusted” only because using TLS (based partially on the above certificates) for all traffic inside the LAN, based on a PKI that touches every client machine, and administering firewalls between subnets and VLANs inside this environment, is more work than the network admin is willing to take responsibility for. He instead directs his efforts towards building a solid outer wall and gatekeeper system, ensuring that anything attempting to cross the boundary from the outside in (or the inside out) is doing so with at least apparently valid purpose.

Now, in fact, your network admin may want to put firewalls up at key gateways between LAN subnets and across leased lines or VPNs. By having this program use any port it chooses, you force the network admin not to add this “defense in depth” as long as your program works this way. He’s not going to like that, and he’s going to push back, hard, on any attempt to tell him he can’t do his job the way he sees fit.

As far as the argument that dynamic ports are used all the time to connect, that’s true – for the client machine. The port your server computer listens on must be static. FTP was mentioned, so we’ll use that. FTP uses two ports, usually 20 and 21, for data transfer and command/control respectively. These ports are the ports the server computer will keep open and listen on, and which a firewall on the server side must allow all incoming requests to pass through.

FTP has two connection modes; “Active” and “Passive”, and the client machine chooses which. In “active mode”, the client will itself begin listening on a second dynamic port, and as part of the negotiation on port 21, will tell the FTP server which other port to SYN. When the client computer is not behind a firewall or other NAT layer, this is better for the server, as the server can now use a dynamic outbound port to “push” messages to the client instead of waiting for the client to send a request to which it can respond, and the server can also distinguish traffic on this port as being between itself and only one client. However, because the client can’t tell a firewall protecting the client’s network that it’s expecting a valid incoming connection on the dynamic port it chose, this scheme is incompatible with a client behind a firewall or other NAT layer, because the firewall will simply deny the incoming request from the server as being unexpected “inbound” traffic.

Instead, for clients that know or presume they are being firewalled/NATed, the client can request “passive” connection negotiation. When the server receives a “passive” request on port 21, it begins listening on a second one of its ports (port 20 is reserved for this purpose, for situations involving a firewall in front of the server as well) and sends this port identifier to the client, who can then make a second “outgoing” connection to the server on which the client’s firewall will then expect traffic. As virtually all clients are at least NATed in current times (home networks are ubiquitous), many FTP client programs don’t even bother trying an active connection, and FTP servers are built to take all the traffic they’ll get on just the two static ports.

In your model, from what you’ve said, you’re basically trying to use an “active” connection scheme, where your software begins listening on a dynamic port and ostensibly tells the remote computer this port to facilitate a return connection. This is, as described, incompatible with a firewall, and so as long as your software behaves this way and cannot behave in any other way, no firewall can exist between two computers using your software. This may be contrary to your network admin’s plans for his network.

You should use ssh tunnels instead of dynamically assigning ports. Usually network administrators are cool with SSH ports. Also you can use SCP for secure file transfer.