Need clarifications regarding some properties of NEPacketTunnelNetworkSettings

Hello, I am working on a NEPacketTunnelProvider and I am not exactly sure if I correctly understand the NEPacketTunnelNetworkSettings.

For example the ipv4Settings according to docs:


This property contains the IPv4 routes specifying what IPv4 traffic to route to the tunnel, as well as the IPv4 address and netmask to assign to the TUN interface.

So this seems like unless I set all the possible routes here, the tunnel should not work for all the traffic?

Currently I have this:

Code Block swift
let ipv4Settings: NEIPv4Settings = NEIPv4Settings(
addresses: ["192.169.89.1"],
subnetMasks: ["255.255.255.255"]
)


Which seems to work pretty well, both for WiFi and cellular. In the past I tried various other addresses, even manually including all the IPV4 routes but I never noticed any effect regarding the tunnel.

Then there is the includedRoutes property.


The routes that specify what IPv4 network traffic will be routed to the TUN interface.

So this is basically another way to set the address like in the constructor for NEIPv4Settings?

This seems to work best when I don't set anything. I tried setting all the routes but that did not change things a bit. The only difference is when I set includedRoutes to NEIPv4Route.default(). Then some apps stop working when the tunnel is active.

This is strange, because even setting all the available routes + default one doesn't fix this "issue".

What is the relation between these properties? It is best to not set includedRoutes if the tunnel works fine?


And lastly. What about dnsSettings? This looks like another optional property. Does it make sense to manually specify DNS to point maybe to 1.1.1.1?


When using NEIPv4Settings you are setting up your inet, or IPv4 addresses, on your virtual interface. When you are using includedRoutes you are declaring that you want to claim these specific routes for your virtual interface. So, in this case, it sounds like you are claiming the default route as a backstop and not the Wi-Fi or Cellular route for your virtual interface.

What is the relation between these properties? It is best to not set includedRoutes if the tunnel works fine?

This is all based on what you are looking to do; I know from a previous post that your goal was then to capture all traffic on the system, so it would be up to you to evaluate your system and provide the available routes to your virtual interface.

For NEDNSSettings, this is meant to be a SMALL subset of DNS traffic that passes through your tunnel. This is meant to be used for a small list of business case domains that you need to handle DNS for. This is NOT meant to be a list of all possible DNS traffic. You will run into endless edge cases trying to handle this.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks for the clarifications. I am more than happy to not touch DNS..

I tried using this crazy code to get all the routes:

Code Block swift
class func getIFAddresses() -> [NetInfo] {
var addresses = [NetInfo]()
var ifaddr : UnsafeMutablePointer<ifaddrs>? = nil
if getifaddrs(&ifaddr) == 0 {
var ptr = ifaddr;
while ptr != nil {
let flags = Int32((ptr?.pointee.ifa_flags)!)
var addr = ptr?.pointee.ifa_addr.pointee
if (flags & (IFF_UP|IFF_RUNNING|IFF_LOOPBACK)) == (IFF_UP|IFF_RUNNING) {
if addr?.sa_family == UInt8(AF_INET) || addr?.sa_family == UInt8(AF_INET6) {
var hostname = [CChar](repeating: 0, count: Int(NI_MAXHOST))
if (getnameinfo(&addr!, socklen_t((addr?.sa_len)!), &hostname, socklen_t(hostname.count),
nil, socklen_t(0), NI_NUMERICHOST) == 0) {
if let address = String.init(validatingUTF8:hostname) {
var net = ptr?.pointee.ifa_netmask.pointee
var netmaskName = [CChar](repeating: 0, count: Int(NI_MAXHOST))
getnameinfo(&net!, socklen_t((net?.sa_len)!), &netmaskName, socklen_t(netmaskName.count),
nil, socklen_t(0), NI_NUMERICHOST)
if let netmask = String.init(validatingUTF8:netmaskName) {
addresses.append(NetInfo(ip: address, netmask: netmask))
}
}
}
}
}
ptr = ptr?.pointee.ifa_next
}
freeifaddrs(ifaddr)
}
return addresses
}


Which seemed to work.

Does the ordering of includedRoutes matter? Since I tried to claim all routes the above code returned (for IPV4 anyway) and then also the default() route which seemed to broke a few apps.

Does the ordering of includedRoutes matter? Since I tried to claim all routes the above code returned (for IPV4 anyway) and then also the default() route which seemed to broke a few apps.

The routes you include here will be added in the order that you add them.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Need clarifications regarding some properties of NEPacketTunnelNetworkSettings
 
 
Q