I am trying to set up a VPN server environment to work with the test program provided by Apple called SimpleTunneler, which uses NETUnnelProviderManager introduced in iOS 9.0. For the server portion I am using the tunnel_server program which is part of that program.
The reason I have chosen to ask this question on this board as opposed to an Apple-specific one is that I feel the basic server and client components are working, with only a network configuration problem remaining.
To keep things simple, I am avoiding DNS and just trying to reach an external web server (using Yahoo address 98.139.183.24, port 80) from my iPhone once I have enabled the device-level VPN. I have configured the network extension on the device to route all IP packets to the tunnel.
When I try to access the site, I see the traffic going from the client (iPhone) to the server (tunnel_server on my mac book pro), initially coming in on the utun2 interface, which is a special interface created that is associated with the tunnel.
After that, I see the packets move to en0 on my server, and then go out to the network.
Initially, I never saw any response coming back, and determined that was because the source address of those packets was not being NATed properly. After a lot of experimentation, I finally got this NATing to work via the below pfctl rule:
nat on en0 inet from !(en0) to any -> (en0)
After adding this, I now see the packets being properly NATed going out, and even a response coming back in from the Yahoo server, onto the en0 interface of my server. However, I never see that response get forwarded to my server's utun2 interface. I am not sure if the problem is with NATing, routing, or something else.
If anyone has any triage or solution suggestions, please let me know.
Here is my setup info:
Server: 10.15.68.160/21 (internal company networking, using WiFi on en0)
Client: 10.15.68.199 (initially), but changes to 192.168.2.2/21 due to the configuration I have set for the server_tunnel program
One thing that seems strange about this setup is that both the server and the client are associated to 192.168.2.2. Actually, if I try to hit that address from the iPhone, I see it hit a web server running on my server, and can confirm everything is passing through the tunnel.
Here is my routing tables for IP4 (from netstat -nr):
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.15.64.1 UGSc 468 113 en0
10.15.64/21 link#5 UCS 4 0 en0
10.15.64.1/32 link#5 UCS 2 0 en0
10.15.64.1 0:8:e3:ff:fd:90 UHLWIir 470 180 en0 1078
10.15.68.160/32 link#5 UCS 1 0 en0
10.15.68.199 70:3e:ac:7b:ea:6a UHLWIi 2 1259 en0 837
10.15.71.141 c4:d9:87:7a:89:b0 UHLWIi 2 256 en0 744
10.15.71.255 link#5 UHLWbI 1 108 en0
127 127.0.0.1 UCS 2 159 lo0
127.0.0.1 127.0.0.1 UH 4 568903 lo0
127.0.53.53 127.0.0.1 UHWIi 1 1 lo0
169.254 link#5 UCS 1 0 en0
192.168.2 link#5 UC 3 0 en0
192.168.2.2 192.168.2.2 UH 2 0 utun2
192.168.2.3 60:3:8:9c:ea:6e UHLWIi 1 31 lo0
192.168.2.255 link#5 UHLWbI 1 108 en0
255.255.255.255/32 link#5 UCS 2 0 en0
255.255.255.255 link#5 UHLWbI 1 99 en0
[Note: I had originally posted this on Network Engineering, but I was told that it is off topic and I should try to repost on Server Fault]
UPDATE:
I worked with someone who is pretty familiar with this type of networking and we were able to get the configuration so that a ping will go out the client device, to the server, and to the endpoint, and then come back to the server. However, no matter what we did we could not get the ping to return to the client device (iPhone).
It seems that the issue could be with reverse-ARP here, and possibly be because the client and server seem to both be assigned the same address "192.168.2.2", but thats just a guess. However it seems unlikely that the apple sample program would not allow this type of use case since it is typical tunnel behavior.