Captive portal screen is not appearing when first time connecting to wifi with System Extension

Hello,

Captive portal screen is not appearing when we are connecting to wifi for the first time. This is happening only when System Extension is enabled. We are using NETransparentProxyProvider System Extension. These are the details-

OS version- Big sur 11.6.3

System Extension- NETransparentProxyProvider

Internet provider- ACT internet

Ruleset-

NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "80"), remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol:.TCP, direction: .outbound),
                       NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol:.TCP, direction: .outbound),
                       NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "80"), remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol:.UDP, direction: .outbound),
                       NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol:.UDP, direction: .outbound)

Replies

Captive portal screen is not appearing when we are connecting to wifi for the first time. This is happening only when System Extension is enabled.

Okay, what is the result of this? Are users not able to join the network or does it allow anyone to join? Either way, are you able to see anything in the system logs when this takes place?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hello Matt,

Here is our inline response of your queries-

what is the result of this?

By default we get the captive portal web page if System extension is disabled, but with System extension, captive portal web page is not coming up.

Are users not able to join the network or does it allow anyone to join?

User is not able to access internet if the user is not logged in, which has to be done with captive portal web page. So, user can't browse anything through safari.

are you able to see anything in the system logs when this takes place?

We were able to gather some logs for the same, we are attaching the logs.

We are getting- 'kernel: (2944957949): failed to get a local IPv4 address: 51'

Hi sourabMIC,

Looking at your rules you allow all outgoing traffic to port 80 & 443. Please note however that some captive portals might use 8443 or any other port - there are plenty of implementation variants.

I'm not sure if you want to avoid some traffic but please note that macOS Captive Portal Assistant usually kicks in using captive.apple.com host check. This might help you adjusting the NENetworkRule at least temporarily to allow other ports.

2022-04-04 13:28:45.012181+0530 0x53059 Info 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:connection] nw_resolver_create_dns_getaddrinfo_locked_block_invoke [C18] Got 2 DNS results

2022-04-04 13:28:45.014014+0530 0x5511f Default 0x0 209 0 mDNSResponder: [com.apple.mdns:resolver] [Q20210] Received acceptable 99-byte response from IPv4:BBpEtiGV over UDP via en0/4 -- id: 0x481A (18458), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/0/1/0, BBuFlLer IN HTTPS?, 259 IN SOA BBXOAPqs BBhnycUH 1648765553 1800 300 60480 300

2022-04-04 13:28:45.014231+0530 0x4a9 Default 0x0 209 0 mDNSResponder: [com.apple.mDNSResponder:Default] [R8907->Q20210] getaddrinfo result -- event: add, ifindex: 0, name: <mask.hash: 'VB8JpysPXrh/mLTzqAL0Dg=='>, type: HTTPS, rdata: (mortal)

2022-04-04 13:28:45.014991+0530 0x5511f Default 0x0 209 0 mDNSResponder: [com.apple.mDNSResponder:Default] [R8907] getaddrinfo stop -- hostname: <mask.hash: 'IG6uhD5lmuYUXZayZ4w6AA=='>, client pid: 327 (captiveagent)

2022-04-04 13:28:45.016064+0530 0x552a3 Error 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:connection] nw_socket_connect [C18.1:1] connectx(5, [srcif=4, srcaddr=, dstaddr=], SAE_ASSOCID_ANY, 0, NULL, 0, NULL, SAE_CONNID_ANY) failed: [51: Network is unreachable] 2022-04-04 13:28:45.016074+0530 0x552a3 Error 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:connection] nw_socket_connect connectx failed (fd 5) [51: Network is unreachable] 2022-04-04 13:28:45.016075+0530 0x552a3 Error 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:] nw_socket_connect connectx failed [51: Network is unreachable] 2022-04-04 13:28:45.016089+0530 0x552a3 Info 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:connection] nw_flow_error [C18.1 IPv4#253d0d97:80 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns, flow divert agg: 1)] Output protocol (socket) sent error: Network is unreachable

2022-04-04 13:28:45.017934+0530 0x552a3 Info 0x0 327 0 captiveagent: (libnetwork.dylib) [com.apple.network:connection] nw_endpoint_resolver_start_next_child [C18 Hostname#1a93c599:80 failed resolver (satisfied (Path is satisfied), interface: en0, scoped, ipv4, dns)] starting next child endpoint in 250ms 2022-04-04 13:28:45.017937+0530 0x53059 Default 0x0 327 0 captiveagent: (CFNetwork) TCP Conn 0x7fba0ff30620 event 3. err: 51

Looking at your logs I can see that you are doing DNS, receiving an address and trying to connect to that address but it's failing because the Network is unreachable. To rule out any sort of bad response or network related issues, try opening up things up and returning false in handleNewFlow` to let the OS handle these requests. If it still fails then you should open a bug report on this. If it succeeds then try dialing in your rules a bit until you get to the point in which you have narrowed down what is making this fail.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hello Matt,

Thank you for your suggestions and observations.

some captive portals might use 8443 or any other port

In my testing I am intercepting the 80 and 443 traffics only and other port traffics are handled by OS itself. So, other ports (like 8443 or any other ports) are open for captive portal to use. Still we are getting ‘Network is unreachable’.

try opening up things up and returning false in handleNewFlow` to let the OS handle these requests

For testing purpose, I have already tried returning 'false' from handleNewFlow(), but in this scenario also we are not getting the Captive Portal default page.

We already reported a bug for the same- FB9973407.

This issue is impacting many users and have escalated to highest level. Will appreciate if this can be taken up soon.

  • Thank you for the follow up and for opening the bug report here.

Add a Comment