# Interface-bound sockets IP_BOUND_IF and required_interface and sandbox behaviour > Source-anchored research for Interface-bound sockets IP_BOUND_IF and required_interface and sandbox behaviour. Run status: COMPLETED. Parent: [macOS App Sandbox Networking and Entitlements](https://llms-explorer.com/tree/macos-app-sandbox-networking/) · 4 facets · 9 facts · page: https://llms-explorer.com/tree/interface-bound-sockets-ip-bound-if-and-required-interface-and-sandbox-behaviour/ ## 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](https://www.security.com/threat-intelligence/security-vpn-ios-macos) - 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](https://developer.apple.com/forums/thread/714370) ## 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](https://developer.apple.com/forums/thread/744044) ## 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](https://developer.apple.com/forums/thread/736083) - 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](https://developer.apple.com/forums/thread/736083) ## 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](https://developer.apple.com/forums/thread/718164) - 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](https://developer.apple.com/forums/thread/718164) - 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](https://developer.apple.com/forums/thread/718164) - 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](https://github.com/insomniacslk/dhcp/issues/378)