Hello.
How does excludedNetworkRules work? Can I setup such rules that allow me to catch everything except specified ports (AirDrop for example)?
I found that if my extension start with these rules:
[Extension ....]: provider set tunnel configuration to
tunnelRemoteAddress = <9-char-str>
includedNetworkRules = (
{
matchRemoteEndpoint = 0.0.0.0:80
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:81
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:8080
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:443
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:25
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:587
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:465
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
)
excludedNetworkRules = (
{
matchRemoteEndpoint = 0.0.0.0:8770
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
{
matchRemoteEndpoint = 0.0.0.0:8770
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
)
isFullyTransparent = YES
Note that rules contains wildcard rule:
{
matchRemotePrefix = 0
matchProtocol = <3-char-str>
matchDirection = <8-char-str>
appliesToLoopback = NO
},
Airdrop is not working.
I see in logs that connection is delivered to my extension, and it rejects it.:
(1899100530): New flow: NEFlow type = stream, app = com.apple.sharingd, name = 69e95d47-5e35-45d9-a0cf-252f226ec444.local, fe80:d::6c5b:6bff:fecc:e0a.0 <-> fe80::fc46:29ff:feaa:24ab.8770, filter_id = , interface = awdl0
(1899100530): Delivering to client
[Extension ....]: Calling handleNewFlow with TCP com.apple.sharingd[{length = 20, bytes = 0x890032e8aa2f6d927360921d19502b76ecd24700}] remote: fe80::fc46:29ff:feaa:24ab%awdl0.8770 interface awdl0
[Extension .....]: provider rejected new flow TCP com.apple.sharingd[{length = 20, bytes = 0x890032e8aa2f6d927360921d19502b76ecd24700}] remote: fe80::fc46:29ff:feaa:24ab%awdl0.8770 interface awdl0
(1899100530): Dropping the director
(1899100530): Destroying, client tx 0, client rx 0, kernel rx 0, kernel tx 0
If I specify exact ports to catch, Airdrop is working.
Could you help me, please?
This recently came up in another thread so I figured I should post an update…
As I mentioned above, DanilKorotenko and I investigated this issue in another context. The conclusion was that this looks like a bug (r. 98382363). You can create a trivial transparent proxy, one that returns false to all handle-new-flow requests, and that still breaks AirDrop. Sadly, I was unable to find any sort of workaround.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"