Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

OpenVPN VPN Server on OS X Server with Mavericks, pfctl, and Tunnelblick

Here are notes on how to build an OpenVPN VPN server on OS X Server with Mavericks, pfctl, and Tunnelblick. Previous OpenVPN server configurations on OS X Server rely upon using the now deprecated natd and ipfw to route VPN traffic, and this solution no longer works. This post describes a replacement using the now preferred pfctl OpenBSD packet filter, which comes with its own NAT. This setup will provide a TLS-based VPN server using 4096-bit certificates and UDP port 443, accessible by any OpenVPN client, especially iOS with the OpenVPN app.


Why would you want to build your own VPN server when OS X server already comes with a VPN service? First, the latest Server.app version 3 breaks VPN to mobile devices. This problem is known and will undoubtedly be fixed soon; however, the VPN technology used by OS X Server is broken and should be avoided altogether (Microsoft’s PPTP: ("PPTP traffic should be considered unencrypted"), or is under a cloud (L2TP/Ipsec with pre-shared keys and MS-CHAPv2 authentication: "IPSEC-PSK is arguably worse than PPTP ever was for a dictionary-based attack vector"). So if you’re going to use OS X Server’s native VPN service, make sure that you use a really long *random* PSK. If you want secure certificate-based VPN between OS X Server and iOS, OpenVPN is the only option.


Furthermore, OS X Server has its firewall turned off by default, assuming that the server lives behind the router's firewall and NAT. Integrating OpenVPN access within a working OS X Server firewall provides greater security than OS X Server's default configuration.


Here’s how to build a VPN Server on OS X Mavericks:


Step 1. Get OpenVPN on OSX and configure it.


1A. I like Macports, so assuming that you've downloaded and installed Xcode from the App Store, installed Macports, run:


sudo port selfupdate

sudo port install openvpn


Step 2. Get Tunnelblick on OS X and configure it.


2A. <http://code.google.com/p/tunnelblick/>


2B. Create your certificates with Easy-RSA


mkdir -p ~/Backups/OpenVPN/easy-rsa-tunnelblick

sudo rsync -va /Applications/Tunnelblick.app/Contents/Resources/easy-rsa-tunnelblick/ ~/Backups/OpenVPN/easy-rsa-tunnelblick

cd ~/Backups/OpenVPN/easy-rsa-tunnelblick

su root

# edit script defaults like KEY_CN == Common Name

vi ./vars


export KEY_SIZE=4096

export KEY_EMAIL="admin@domainname.com"

export KEY_CN=Domainname


mkdir -m go-rwx ./keys

touch ./keys/index.txt

echo 1 > ./keys/serial

. ./vars

./clean-all

./build-ca --pass

./build-key-server server-domainname

# choose a unique Common Name (CN) for each client

./build-key client-domainname

./build-dh

openvpn2 --genkey --secret ./keys/ta.key


# Notes:

# Use the domain name "domainname.com" for the common name

# Contact email "admin@domainname.com" must match name in CA;

# otherwise, there will be some X509 error.


# For the server-domainname cert, use the default common name

# "server-domainname".This must also match the client configuration

# setting:

# tls-remote domainname.com


# Unnecessary if you already signed with ./build-key[-server]

# ./sign-req server-domainname

# ./sign-req client-domainname


cd keys

openssl verify -CAfile ca.crt ca.crt

openssl verify -CAfile ca.crt server-domainname.crt

openssl verify -CAfile ca.crt client-domainname.crt

exit # root


2C. Create a .tblk directory for your VPN server with all the necessary files. I'll demo a tun setup. The LAN here looks like a router on 10.0.1.1 and a OS X Server on 10.0.1.3.


mkdir ~/Desktop/Domainname_tun.tblk

cd ~/Backups/OpenVPN/easy-rsa-tunnelblick/keys

sudo cp -p ca.crt dh4096.pem server-domainname.crt server-domainname.key ta.key ~/Desktop/Domainname_tun.tblk

sudo chown -R username ~/Desktop/Domainname_tun.tblk

cd ~/Desktop/Domainname_tun.tblk

vi config.ovpn


local 10.0.1.3

port 443

proto udp


dev tun

;dev tap


ca ca.crt

cert server-domainname.crt

key server-domainname.key


tls-auth ta.key 0


dh dh4096.pem


server 10.2.0.0 255.255.255.0


;server-bridge 10.0.1.3 255.255.255.0 10.0.1.50 10.0.1.90


;topology subnet


# Push routes to the client to allow it

# to reach other private subnets behind

# the server. Remember that these

# private subnets will also need

# to know to route the OpenVPN client

# address pool (10.2.0.0/255.255.255.0)

# back to the OpenVPN server.

;push "route 10.0.1.0/255.255.255.0"


push "redirect-gateway def1"

push "dhcp-option DNS 8.8.8.8"

;push "dhcp-option DNS 10.0.1.3”

;push "dhcp-option DOMAIN domainname.com."


client-to-client


keepalive 10 120


;cipher BF-CBC


comp-lzo


max-clients 10


user nobody

group nobody


persist-key

persist-tun


ifconfig-pool-persist ipp.txt


verb 3



2D. Forward UDP port 443 from your router to you server at 10.0.1.3. (You may also wish to forward the default OpenVPN port 1194 as well to test other configurations.)


2E. Doubleclick on ~/Desktop/Domainname_tun.tblk within Finder, which should start Tunnelblick and import your configuration. Then,


Tunnelblick>VPN Details ... >Configuration>Settings>Set Nameserver (3.1)


You may also wish to launch this service at boot.


Hit connect and Tunnelblick should launch your OpenVPN server on UDP port 443.


2F. Get OpenVPN from the iOS App store and securely transfer a client.ovpn file to it:


client.ovpn:


####

## Domain Mac UDP client configuration version 2.0

####

client

dev tun

proto udp

remote server.domainname.com 443

redirect-gateway def1

resolv-retry infinite

nobind

;user nobody

;group nobody

persist-key

persist-tun

;ca ca.crt

;cert iPad-domainname.crt

;key iPad-domainname.key

<ca>

-----BEGIN CERTIFICATE-----

MY CERT from ca.crt

-----END CERTIFICATE-----

</ca>

ns-cert-type server

;tls-auth ta.key 1

key-direction 1

<tls-auth>

#

# 4096 bit OpenVPN static key

#

-----BEGIN OpenVPN Static key V1-----

MY CERT from ta.key

-----END OpenVPN Static key V1-----

</tls-auth>

;auth-user-pass

;tls-remote server-domainname

tls-ciphe

r DHE-RSA-AES256-SHA

;cipher BF-CBC

;client-http-proxy 10.0.1.3 3128

comp-lzo

verb 3



Step 3. Configure pfctl on OS X to route your VPN packets correctly.


3.A. Set up sysctl variables at boot:


sudo mkdir -p /Library/Application\ Support/vpn

sudo vi /Library/Application\ Support/vpn/enable-vpn-forward-nat.sh


#!/bin/bash

#

# References: The Book of PF, p. 21; https://forums.openvpn.net/topic11401.html

#

# Sleep is necessary cause network has to be up at the time of following commands

# Otherwise the network will not work at all

#

sleep 15

#

/usr/sbin/sysctl -w net.inet.ip.fw.enable=1

/usr/sbin/sysctl -w net.inet.ip.forwarding=1

/usr/sbin/sysctl -w net.inet6.ip6.forwarding=1


# natd and ipfw are DEPRECATED. Use pfctl(8) instead with nat, e.g.

# nat on en0 from 10.0.0.0/8 to any -> (en0)

###/usr/sbin/natd -interface en0

###/sbin/ipfw add divert natd ip from any to any via en0


sudo vi /Library/LaunchDaemons/net.openvpn.enable-vpn-forward-nat.plist


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd >

<plist version="1.0">

<dict>

<key>Label</key>

<string>net.openvpn.enable-vpn-forward-nat</string>

<key>ProgramArguments</key>

<array>

<string>/Library/Application Support/vpn/enable-vpn-forward-nat.sh</string>

</array>

<key>RunAtLoad</key>

<true/>

</dict>

</plist>


sudo launchctl load -w /Library/LaunchDaemons/net.openvpn.enable-vpn-forward-nat.plist


3.B. Integrate a NAT within the existing OS X Server pfctl rules in /etc/pf.conf and set up a launch daemon for pf. The essential pfctl NAT and filter rules are


nat on en0 from 10.0.0.0/8 to any -> (en0)

pass from { lo0, 10.0.0.0/8 } to any keep state


sudo vi /etc/pf.conf


# References for modifications:

# The Book of PF by Peter N.M. Hansteen

# http://hints.macworld.com/article.php?story=20121011004626997

# http://blog.scottlowe.org/2013/05/15/using-pf-on-os-x-mountain-lion/

# http://krypted.com/mac-security/a-cheat-sheet-for-using-pf-in-os-x-lion-and-up/


# Options

set block-policy drop

set fingerprints "/etc/pf.os"

set ruleset-optimization basic

set skip on lo0


# Normalization

# Scrub incoming packets

scrub in all no-df


#

# com.apple anchor point

#

scrub-anchor "com.apple/*"


# Queueing


# Translation


# OpenVPN Server NAT

#

# The Book of PF, p. 21

int_if = "en0" # macro for internal interface

localnet = "10.0.0.0/8"

nat on $int_if from $localnet to any -> ($int_if)


nat-anchor "com.apple/*"

rdr-anchor "com.apple/*"

dummynet-anchor "com.apple/*"

anchor "com.apple/*"

load anchor "com.apple" from "/etc/pf.anchors/com.apple"


# Filtering

lan_server = 10.0.1.3


# Antispoof

antispoof log quick for { lo0 en0 }


# Block by default

block in log


# Allow outgoing traffic from NAT'd { lo0, $localnet }

# The Book of PF, p. 21

pass from { lo0, $localnet } to any keep state


# Block to/from illegal destinations or sources

block in log quick from no-route to any


# Allow critical system traffic

pass in quick inet proto udp from any port 67 to any port 68


# Allow ICMP from home LAN

pass in log proto icmp from $lan_server:network


# Allow outgoing traffic

pass out inet proto tcp from any to any keep state

pass out inet proto udp from any to any keep state


# Internet services

internet_udp_services = "{ https, 500, 1194, 1701, 4500, 5060, 5190, 5297, 5298, 5678, 16384 }"

internet_tcp_services = "{ ssh, smtp, https, 143, 587, 993, 995, 1640, 2170, 2195, 2196, 4190,\

5218, 5223, 5190, 5220, 5222, 5298, 8008, 8443, 8800, 8843 }"

pass in quick inet proto tcp from any to { lo0, $lan_server } port $internet_tcp_services

pass in quick inet proto udp from any to { lo0, $lan_server } port $internet_udp_services


# LAN services: block access, except from localnet

lan_udp_services = "{ 5001 }"

lan_tcp_services = "{ domain, auth, nntp, www, 311, 3128, 5001, 5900:5909, 8118, 8123 }"

pass in quick inet proto tcp from { lo0, $localnet } to { lo0, $lan_server } port $lan_tcp_services

pass in quick inet proto udp from { lo0, $localnet } to { lo0, $lan_server } port $lan_udp_services


sudo vi /Library/LaunchDaemons/net.openbsd.pf.plist


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Label</key>

<string>net.openbsd.pf.plist</string>

<key>Program</key>

<string>/sbin/pfctl</string>

<key>ProgramArguments</key>

<array>

<string>/sbin/pfctl</string>

<string>-e</string>

<string>-f</string>

<string>/etc/pf.conf</string>

</array>

<key>RunAtLoad</key>

<true/>

<key>ServiceDescription</key>

<string>OpenBSD Packet Filter (pf)</string>

<key>StandardErrorPath</key>

<string>/var/log/pf.log</string>

<key>StandardOutPath</key>

<string>/var/log/pf.log</string>

</dict>

</plist>


sudo launchctl load -w /Library/LaunchDaemons/net.openbsd.pf.plist


3.C. Finally, turn on OS X Server’s adaptive firewall if you like:


sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serverctl enable service=com.apple.afctl

sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -f

Mac mini Server (Mid 2010), OS X Mountain Lion (10.8.2), OS X Server, EyeTV HD, Turbo.264 HD

Posted on Nov 8, 2013 6:44 AM

Reply
71 replies

Nov 13, 2014 3:25 AM in response to amolteni

A few comments:


  • Apple did away with natd in Mavericks—the nat command in pf.conf must be used in OS X 10.9 and up.
  • AFAIK, there is no OS X kernel support for tap interfaces, either natively or from Tunnelblick or elsewhere. The tun interface must be used on OS X.
  • The problem with OpenVPN clients being unable to hit ports on the OpenVPN server LAN, e.g. 10.0.1.3:80 is unresolved. See earlier in this thread for detailed analysis with tcpdump <OpenVPN VPN Server on OS X Server with Mavericks, pfctl, and Tunnelblick>. Any help or pointers fixing this one remaining issue would be greatly appreciated.

Nov 13, 2014 3:52 AM in response to essandess

@essandess


- Natd was working on Mavericks, but anyway, the best way is to start playing with pfctl and the new nat methods.

- Didn't know that about tap support in the kernel, thanks.

- I'm able to connect to any port to my VPN server (It's a linux box) and it is able to connect to any port to my VPN Client (My macbook).


To test this I've enabled the remote management on my MacBook (Settings -- Sharing -- Remote management), just to test the port 5900.


As you can see my VPN Server is able to connect to that port, obviously using the vpn client address (in this case my macbook was 1.1.1.6)


-----------------------------------------------------

root@raidserver:~# telnet 1.1.1.6 5900

Trying 1.1.1.6...

Connected to 1.1.1.6.

Escape character is '^]'.

RFB 003.889


telnet> cl

root@raidserver:~#

-----------------------------------------------------



My MacBook is able to connect to the VPN Server ports too (VPN server ip is 1.1.1.1). This is a connection to a web port (Apache, port 80)


-----------------------------------------------------

raidbook:~ amolteni$ telnet 1.1.1.1 80

Trying 1.1.1.1...

Connected to 1.1.1.1.

Escape character is '^]'.

-----------------------------------------------------


Can you check if the port 5900 is opened on all the IP addresses on the VPN Client?


Please check that with the command:


# netstat -an |grep LIST |grep 5900


On my Macbook:


raidbook:~ amolteni$ netstat -an |grep LIST

tcp4 0 0 *.88 *.* LISTEN

tcp6 0 0 *.88 *.* LISTEN

tcp6 0 0 *.5900 *.* LISTEN

tcp4 0 0 *.5900 *.* LISTEN

[CUT]



BR,

Alessio.

Nov 13, 2014 4:09 AM in response to essandess

@essandess:


(First, thanks for this thread.)


As the Tunnelblick developer, I would like to comment on your statement about tap and tun support:


  • OS X does not include kernel support for either tun or tap interfaces.
  • OS X 10.6.8 and higher includes a kernel "utun" interface which functions as a "tun" interface.
  • Tunnelblick and OpenVPN both support tap interfaces and tun devices, and some versions of OpenVPN support utun devices.
  • Tunnelblick includes several versions of tun and tap kexts from the Tuntaposx project.
  • For tun configurations, OpenVPN 2.3 and higher will use utun if it is available unless the "dev-node tun" option is included in the OpenVPN configuration file, in which case OpenVPN will use tun.
  • Tunnelblick includes several versions of both tun and tap kexts. By default, they are loaded as follows:
    • For tap connections, Tunnelblick loads a tap kext appropriate to the OS version.
    • For tun connections, Tunnelblick either loads a tun kext appropriate for the version of OS X, or does not load any kext and lets OpenVPN use the "utun" interface. The tun kext is loaded if running on OS X 10.6.7 or lower, or using OpenVPN versions lower than 2.3.3 (which do not support utun), except that if there is a "dev-node tun" option in the OpenVPN configuration, then Tunnelblick will load the tun kext.
  • This automatic loading of kexts may be overridden on a per-configuration basis on Tunnelblick's "Advanced" setup window.

Nov 13, 2014 5:51 AM in response to amolteni

Thanks for the notes about hitting ports on the OpenVPN server. Unfortunately, I don't believe this addresses the issue because the example appears to hit these ports in the same IP as the OpenVPN server. In this case, I believe the OpenVPN client routes these packets directly to the server, not through the VPN tunnel. For example, if you run a VNC server (say on port 5900) on the same server as the OpenVPN server, you'll be able to hit both ports at say 1.1.1.1:5900 tcp and 1.1.1.1:443 udp.


But now say you want to block access to 5900 from the internet and require an encrypted VNC connection. So you turn off port forwarding at your router (say public ip 1.1.1.1) to the server's LAN ip at say 10.0.1.3. Port 5900 remains open on the secure LAN at 10.0.1.3, but is inaccessible from the internet at 1.1.1.1.


One SHOULD be able to VPN into the server at 1.1.1.1:443 udp, then be able to access restricted LAN ports like10.0.1.3:5900. But that doesn't work with the OpenVPN client–server setup described in this thread. It DOES work for other restricted LAN ports on other LAN IPs like 10.0.1.200:5900, but not ports on the same LAN IP as the OpenVPN server. The workaround is to hit these LAN ports via the utun IP at say 10.8.0.1—that works. But it involves duplicating client configurations that depend whether or not you're using OpenVPN, which is awkward and breaky.


If anyone has any insight into fixing this issue, please post it.

Nov 13, 2014 5:58 AM in response to jkbull

@jkbull And thank you for all your work on Tunnelblick, and for correcting my comment.


I once tried to use the tap if with this client–server configuration, without success. Perhaps kext upgrades makes this possible now, or I was just doing it wrong. If anyone has a working tap client–server configuration, please post it.

Nov 13, 2014 7:01 AM in response to essandess

@essandess


I think you just have a routing problem.


Your VPN client should act as a router, the VPN server should know the routes to reach the secure LAN behind the VPN client (client + router).

My VPN main server is a Virtual Server hosted by an internet provider, it's recheable from the internet. Of course the VPN addresses are private and different from the server main address (public). At home I have a DD-WRT router that connects to the VPN server as a client, but it also act as a router for the internal LAN.

If I connect to the VPN Server, using a VPN client from any device I have, I mean iPhone, iPad, Mac and so on... I'm able to reach my secure lan at home.

I've played a lot with the routing tables, but what really solved my problems was the iroute option in the client configuration file (located on the VPN server).

Please have a look at this document: https://community.openvpn.net/openvpn/wiki/RoutedLans

The VPN Server could have a profile file for each client, normally located in the "/etc/openvpn/ccd" directory. In the openvpn server configuration you should put this option: "client-config-dir ccd"


The file for the DD-WRT router at home looks like this:

root@raidserver:/etc/openvpn/ccd# cat linksys

ifconfig-push 1.1.10.10 1.1.10.11

iroute 192.168.1.0 255.255.255.0

root@raidserver:/etc/openvpn/ccd#


The iroute option tell to the VPN Server that behind this client exist a secure lan and the main ip address of this client is also part of this secure lan.

Consider also that my home lan is not routed through my Open VPN server public address, I need to be connected to the VPN reach my home devices, for security reasons.

Probably it's a little bit difficult to find a detailed solution to your routing problem, but this could be a starting point.

Br,

Alessio.

Nov 13, 2014 6:13 PM in response to amolteni

I think you just have a routing problem. ...


It is just a routing problem, but I don't know how to fix it, as AFAIK the routing tables and configuration are correct. The iroute directive isn't appropriate for mobile clients because iPhones don't control their own LAN. And I'm using all the correct route commands in the server.ovpn config:


server 10.8.0.0 255.255.255.0

route 10.0.1.0 255.255.255.0

route 10.8.0.0 255.255.255.0

push "route 10.0.1.0 255.255.255.0"

push "route 10.8.0.0 255.255.255.0"


A tcpdump here <Re: OpenVPN VPN Server on OS X Server with Mavericks, pfctl, and Tunnelblick> shows VNC packets going to the server on interface tun0, and leaving the VNC server on interface en0. I'm not sure if packets are correctly crossing over between tun0 and en0 -- the result is that services are not available to VPN clients. However, other LAN services not on the OpenVPN server are available.


So the routing problem occurs on the server, not the client. I'm not sure whether to point the finger at OpenVPN, Tunnelblick, inadequate routing tables, inadequate configuration, or something else. It's a puzzle.

Nov 14, 2014 1:14 AM in response to amolteni

As I say, accessing server services does work using the OpenVPN IP. This involves duplication of numerous client configurations that depend upon whether or not OpenVPN is being used. It would be much easier to push the server's DNS service and simply use the server domain name to configure clients, as is possible with L2TP. Imagine all the steps necessary to replicate DNS or a proxy filter services that depend on OpenVPN clients with special OpenVPN IPs. It is a major hassle to not be able to resolve the server's domain name to its IP and access services at that domain name.

Nov 14, 2014 1:38 AM in response to essandess

@essandess


Understood, sorry, I thought it was just a test.


Could be something involved in the NAT?


I've seen that you are natting a wide network on the OpenVPN Server: 10.0.0.0/8

Can you try to nat just the local lan and not the VPN clients network? For instance 10.0.1.0/24

I mean, you natting all the VPN clients to the server en0 interface, but that's not needed to reach the server LAN IP, as you are directly connected to it and routed over the VPN.


If you can post your network diagram would be great.


BR,

Alessio.

Nov 14, 2014 11:12 AM in response to amolteni

My network is pretty basic and looks like this:


[mobile client, OVPN IP 10.8.0.6] <--- (internet) ---> [Router, Public IP, NAT to 10.0.1/24] <--- LAN ---> [Server LAN IP 10.0.1.3, OVPN Server IP 10.8.0.1]


The server has a static wired interface "en0" (it's OS X) and a dynamic OpenVPN interface "tun0", established by Tunnelblick with a server.conf specified above.


In the opinion of others, what is the correct nat rule in pf.conf that will allow OpenVPN clients to access both the internet and the LAN behind the router on 10.0.1/24, including the server at 10.0.1.3? What is the brief explanation for what the recommended nat rule accomplishes?

Nov 15, 2014 6:15 PM in response to essandess

Hi,


I think i am having the same issue as you are, and just wanted to compare notes.


My setup is - a Mac Mini on Yosemite running OpenVPN Server listening on en0 192.168.0.17 on 8443 which is nat'ed on my router and reachable/


My routing part in the server config is like


push "route 192.168.1.0 255.255.255.0"

push "route 194.168.4.0 255.255.255.0"

server 10.2.0.0 255.255.255.0

;server-bridge 10.0.1.3 255.255.255.0 10.0.1.50 10.0.1.90

;topology subnet

push "redirect-gateway def1"

push "dhcp-option DNS 192.168.0.17"

;push "route 10.0.1.0/255.255.255.0"


I can connect from my iPhone to the openvpn server, and i can access addresses on my local network, 192.168.0.x. But i cannot route out to the internet.


There are some guides on how to set up ipfw to do some routing, and i have tried these but look like ipfw and nat hase been removed from yosemite.


Can you advise on if and how i can use PF to forward the traffic?


thanks

Indy

Nov 16, 2014 5:54 PM in response to inderjeetfromwolverhampton

Routing guide, lol.


See above and related posts for a secure pf.conf setup, but the following will get you started. Add these directives to pf.conf:


vpn_net = "10.8.0/24" # utun0 interface doesn't exist at boot time

int_if = "en0"

nat on $int_if inet from $vpn_net to any -> $int_if


# Pass by default

pass all


Then turn on the packet filter:


sudo pfctl -ef /etc/pf.conf


That will get you internet and LAN access, but as we've been discussing, there's still some issue accessing the server from the server's own IP. When I find some free time I'll log and follow a tcpdump stream and see if there's some modification to this nat command that will allow server access.


If anyone has another recommended nat command, please make one.

Nov 17, 2014 1:45 AM in response to essandess

@essandess


I've tested my configurations a bit and I never have any problem in reaching the services on my openvpn server. Unfortunately it's a linux box so I can't test your setup completely (it uses iptables instead of PF).


But, on my MacBook, where I always forward my iPhone connected "ad-hoc" on the VPN I'm using the PF nat, the macbook services are always available.


This is my pf.conf file (on the macbook, comments removed):

-----------------------

localnet = "192.168.10.0/24"

nat on $int_if from $localnet to any -> ($int_if)



nat-anchor "com.apple/*"

rdr-anchor "com.apple/*"

dummynet-anchor "com.apple/*"

anchor "com.apple/*"

load anchor "com.apple" from "/etc/pf.anchors/com.apple"



pass all

-----------------------


The "localnet" is the the ad-hoc network between my iPhone and my MacBook and I can forward packets to my MacBook private LAN IP (something like 10.x.x.x/24). The VNC Viewer (RealVNC) on my iPhone also sees the Bonjour services and I can connect to my MacBook on its LAN interface.

So I guess it's not something related to the PF configuration, because I can browse the internet from my iPhone (through the VPN) and connect to the macbook LAN at the same time.


BR,

Alessio.

OpenVPN VPN Server on OS X Server with Mavericks, pfctl, and Tunnelblick

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.