Hello,
We are implementing a Transparent Proxy using NETransparentProxyProvider and configuring NETransparentProxyNetworkSettings with NENetworkRule.
Currently, NENetworkRule requires:
NENetworkRule(
destinationHost: NWHostEndpoint(hostname: String, port: String),
protocol: .TCP / .UDP / .any
)
NWHostEndpoint.port accepts only a single port value (as a String) or an empty string for all ports.
At present, we are creating a separate NENetworkRule for each port in the range (ex for range 49152–65535 approximately 16,384 rules). After deploying this configuration, we observe the following behavior:
- nesessionmanager starts consuming very high CPU (near 100%)
- The system becomes unresponsive
- The device eventually hangs and restarts automatically
- The behavior resembles a kernel panic scenario
This strongly suggests that creating thousands of NENetworkRule entries may not be a supported or scalable approach.
Questions:
- Is there any officially supported way to specify a port range in NENetworkRule?
- Is creating thousands of rules (one per port) considered acceptable or supported?
- Is the recommended design to intercept broadly (e.g., port = "") and filter port ranges inside handleNewTCPFlow / handleNewUDPFlow instead?
- Are there documented system limits for the number of NENetworkRule entries allowed in NETransparentProxyNetworkSettings?
Is there any officially supported way to specify a port range in NENetworkRule?
I think you’ve answered this yourself (-:
If you’d like to see this change in the future, I encourage you to file an enhancement request describing your requirements. And please post your bug number, just for the record.
Oh, one more thing. The port range in your example coveres ephemeral ports, which I presume is not a coincidence. If so, consider focusing on that in your ER. The ephemeral port range has changed in the past and it wouldn’t surprise me if it changed again in the future.
OTOH, a general port range feature would be more flexible.
(One of the nice things about your filing your own ERs is that you get to explain your own requirements in your own words.)
Is creating thousands of rules (one per port) considered acceptable or supported?
Again, I think you’ve answered that for yourself. I mean, unless you consider kernel panics acceptable.
Is the recommended design to intercept broadly … and filter port ranges inside handleNewTCPFlow / handleNewUDPFlow instead?
I suspect not. In many cases the addresses and ports for a flow aren’t locked down until the flow starts transferring data, that is, after the handle-new-flow method returns. So you have to return true from the handle-new-flow method and, once you do that, you can’t opt out of proxying the flow.
I think that’ll be the case here as well, but I encourage you to test it for yourself. It’s been a while since I explored this.
Are there documented system limits for the number of NENetworkRule entries allowed in NETransparentProxyNetworkSettings?
No. But I’m not surprised that trying to create thousands of them causes problems.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"