1

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.

0

You must log in to answer this question.

Browse other questions tagged .