AppProxy causes socket listen() to fail

Right, using a NENetworkRule like this and then opening a listening socket, for example with netcat, will cause an issue. I was able to reproduce this on Catalina and Big Sur Beta 8. I believe the team is already aware of this, but you can open a bug report to raise more awareness on this topic.

As a side note, you can use a NENetworkRule like the following to work around this:

Code Block swift
let includedTCPNetworks = [("0.0.0.0", 0), ("::", 0)].map { addr, prefix -> NENetworkRule in
    let endpoint = NWHostEndpoint(hostname: addr, port: "443")
    return NENetworkRule(destinationNetwork: endpoint, prefix: prefix, protocol: .TCP)
}
settings.includedNetworkRules = includedTCPNetworks

If you open a bug report, please responde back with the Feedback ID.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thanks for looking into this.

I have submitted Feedback ID FB8742532.

As for the work around,
It can work only for isolated cases. If we need to serv all ports, we cannot create so many rules.

Thank you for opening the bug report. I see it internally and have copied myself on it for more information.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Update: It seems that the mentioned issues were already reported to your teams: proxifier.com/download/bigsur

2nd Update: I just found out that the Proxifier team created this feedback and it seems that the issue wasn't resolved yet.

Hello Matt,

was this issue resolved with the public release of macOS Big Sur 11.0.1?

We are having similar issues (as far as I can tell) when using the Proxifier application: Proxifier v3 uses the new Network Extension API in macOS Big Sur - in case the Proxifier application is running I'm not able to establish other internet-based connections in tools like Cisco WebEx or fetching information from Git repositories using SSH.

I was in discussion with the Proxifier support team and they assume that the Network Extension API could be the cause here - it seems that two applications are not able to use the Network Extension API at the same time.

Is the team aware of those issues or do you need further information to investigate?

Thanks,
Manuel

@Manuel136

was this issue resolved with the public release of macOS Big Sur 11.0.1?

The author's feedback does looks like it's outstanding.

We are having similar issues (as far as I can tell) when using the Proxifier application: Proxifier v3 uses the new Network Extension API in macOS Big Sur - in case the Proxifier application is running I'm not able to establish other internet-based connections in tools like Cisco WebEx or fetching information from Git repositories using SSH.

This may not be exactly the same issue as SSH at least runs over a different listening port than the author has described.

To test this out, I setup a test case with NETransparentProxyProvider on macOS Big Sur 11.0.1 (20B28) using:

Code Block swift
final class TransparentProxyProvider: NETransparentProxyProvider {
   ...
}
/* Filter TCP connections on port 8080 */
NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "8080"),
                          remotePrefix: 0,
                          localNetwork: nil,
                          localPrefix: 0,
                          protocol:.TCP,
                          direction: .outbound)

And was able to start up the proxy and then start up netcat listening on port 8080. From there I was able to hit the Big Sur work station from another local machine and see netcat receive the HTTP request.

Code Block text
% nc -vv -l 8080
GET / HTTP/1.1
Host: 192.168.x.x:8080
User-Agent: curl/7.58.0
Accept: */*

What listening ports are you not seeing working when NETransparentProxyProvider is up and running on Big Sur?


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hello @meaton,

thanks for your response and sorry for the confusion - I mixed up some things here:

The issue I mentioned with the Proxifier application is another one - the Proxifier team opened up a new thread for that: https://developer.apple.com/forums/thread/666894

What listening ports are you not seeing working when NETransparentProxyProvider is up and running on Big Sur?

I think I'm not missing any listening ports on my side but I'm trying to provide you some feedback here.

Best regards,
Manuel

@Manuel136

Thank you for the follow up. Yes, the reason I suggested opening a TSI for this is because it looked like the issue was between NETransparentProxyProvider and NEFilterDataProvider running at the same time. Which is a test that is reasonable to run on Big Sur. If there were a packet tunnel involved that would be different story. Knowing that I would need additional research time to investigate this further outside the context of the Developer Forums.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton - for that workaround you mention, is there a way to specify a wildcard for the port (instead of port 443)?

I can verify that upgrading to 11.1 beta 2 addresses this same issue I had as well.

@Toonetown

To a degree yes; you can use nil on the remoteNetwork and localNetwork to match any hostname on either side and this should theoretically act like a wildcard, but you should test this further:

Code Block swift
NENetworkRule(remoteNetwork:nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .outbound)

I was able to run this today with NETransparentProxyProvider and a listening netcat socket on port 8080 and see the response from another local HTTP request on the network through netcat. I would encourage you to test further though.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com