Interface-bound sockets IP_BOUND_IF and required_interface and sandbox behaviour
Parent: macOS App Sandbox Networking and Entitlements · Published reference · snapshot 2026-10-02
↓ Facts as markdownall context files
Source-anchored research for Interface-bound sockets IP_BOUND_IF and required_interface and sandbox behaviour. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Binding to the physical interface's IP with bind() makes traffic bypass a NetworkExtension-based VPN tunnel; Apple said in 2017 this is not a vulnerability because NetworkExtension makes no guarantee about traffic flow. Always-On VPN is not affected. (medium confidence) (verified as of 2017-12-19) [source]
- Inside a NEPacketTunnelProvider, setsockopt IP_BOUND_IF to the tunnel does not work because NECP prevents VPN loops (the call can succeed but data takes the default interface). This is irrelevant to a plain sandboxed monitor app. (low confidence) (verified as of 2022-09-01) [source]
Problems, failure modes and limitations
- A VPN that sets includeAllNetworks can still send traffic over the VPN interface even when IP_BOUND_IF names another interface, so an interface-bound monitor probe cannot be assumed to leave via that interface on such hosts. (medium confidence) (verified as of 2024-01-01) [source]
Comparisons and alternatives
- IP_BOUND_IF (IPPROTO_IP) and IPV6_BOUND_IF (IPPROTO_IPV6) take an interface index from if_nametoindex() and limit transmission and reception to that interface; Apple's recommendation is to use them rather than bind() to an interface's IP address. (high confidence) [source]
- An Apple DTS test on macOS 13.5 showed IP_BOUND_IF forcing a connection through a VPN utun interface versus the default en0 route; DTS said it has worked this way for decades. (medium confidence) [source]
Facts and statements
- Do not hard-code BSD interface names such as pdp_ip0 or assume IPv4 is present; resolve the interface at runtime and use IPV6_BOUND_IF where only IPv6 exists. For TCP/UDP, Apple DTS prefers Network.framework requiredInterfaceType. (medium confidence) [source]
- NWParameters exposes requiredInterface, requiredInterfaceType, prohibitedInterfaces and prohibitedInterfaceTypes under 'Selecting Paths' for connections and listeners (and browsers for requiredInterface); this is the Network.framework counterpart of interface-bound sockets. Exact availability strings were not retrieved. (low confidence) [source]
- Sandbox behaviour: sources show only that network operations are denied without the network entitlements (sandbox log 'deny(1) network-bind*:0' on iOS, where App Sandbox entitlements do not apply). No source states that the IP_BOUND_IF setsockopt itself is sandbox-restricted or exempt; assume it is governed by the network.client/server entitlement on connect/bind and verify empirically. (low confidence) [source]
- IP_RECVIF only filters received packets and does not direct outbound traffic; for outbound or broadcast traffic on macOS use IP_BOUND_IF (DHCP library issue, 2020). (low confidence) [source]
Children
- No children recorded.