How to decide addresses for NEIPv4Settings, NEIPv6Settings of NEPacketTunnelNetworkSettings

Hi,

This is how we create ipv4Settings, then we add includedRoutes, excludedRoutes.

let ipv4Settings = NEIPv4Settings(addresses: addresses, subnetMasks: subnetMask)

In my case, Packet Tunnel Provider reads the packet like this - packetFlow.readPacketObjects, sends packets to C++ module which takes care of sending it to wireguard tunnel, returns packet back to Packet Tunnel Provider for writing. C++ Module does everything related to wireguard tunnel.

As per my understanding, any unique private ipv4, ipv6 address should be fine for creating NEIPv4Settings, NEIPv6Settings. is that correct? or is there anything else i need to consider for setting Utun addresses

as of now i have harcoded it to 10.10.10.10/32 and 2001:db8::/128, will it cause any problem?

Accepted Reply

The one thing you have to be careful of is conflicts. The addresses you pass in here will be assigned to the VPN interface. If some other interface on the system happens to use the same address, things won’t work properly. If you use a private address, you can’t guarantee that won’t happen.

I’ve actually seen this happen with VPNs that use a 10.0.0.0/8 address, assuming that the user’s Wi-Fi will use something from 192.168.0.0/16, and then fail when the user is on a network run by an AirPort base station, which just happens to use a 10.0.0.0/8 address.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies

as of now i have harcoded it to 10.10.10.10/32 and 2001:db8::/128, will it cause any problem?

Its hard to say if this will cause an issue but the basic idea is that you want to claim packets by destination IP so that any packets destined for a certain IP will be routed through your tunnel.

The one thing you have to be careful of is conflicts. The addresses you pass in here will be assigned to the VPN interface. If some other interface on the system happens to use the same address, things won’t work properly. If you use a private address, you can’t guarantee that won’t happen.

I’ve actually seen this happen with VPNs that use a 10.0.0.0/8 address, assuming that the user’s Wi-Fi will use something from 192.168.0.0/16, and then fail when the user is on a network run by an AirPort base station, which just happens to use a 10.0.0.0/8 address.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi @eskimo @meaton One doubt here, lets say 10.0.0.0 address is already in use by other utun. Now new VPN Interface is getting created with address 10.0.0.0/8.

Will macOS assigns ip from the range 10.0.0.0/8 other than 10.0.0.0?

I have created an utun interface(utun5) with address 10.0.0.0, then we installed VPN with address 10.0.0.0/8.

I observed that new utun interface(utun4) created by VPN having the same address 10.0.0.0 only. What is the use of giving CIDR range instead of specific ip?

utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

inet 10.0.0.0 --> 10.0.0.1 netmask 0xff000000 

nd6 options=201<PERFORMNUD,DAD>

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300

options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>

inet6 fe80::bed0:74ff:fe37:92be%utun4 prefixlen 64 scopeid 0x1e 

inet 10.0.0.0 --> 10.0.0.0 netmask 0xff000000 

inet6 2001:db8:: prefixlen 120 

nd6 options=201<PERFORMNUD,DAD>

One doubt here, lets say 10.0.0.0 address is already in use by other utun.

It doesn’t have to be a virtual interface. That was kinda my point about AirPort base stations, where the embedded DHCP server defaults to handling 10.0.0.0/8 addresses when the AirPort is in NAT mode.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"