You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

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

May 25, 2016 10:20 AM in response to essandess

Thanks for the reply. Still struggling, the client now gets the 192.168.xx.6 LAN (so it is on the same subnet as the server), but still no access to the internet or LAN (I am trying to VNC into the server). Here are my findings/changes I've done now:


enable-vpn-forward-nat.sh

- yes, as suggested (this is the same as in the openpn server install)


pf.conf

- changed "vpn_net = "10.8.0/24"" into "vpn_net = "192.168/16"" and removed the # sign in front of this line

- removed the # sign in front of the "pass in..." line


sudo pfctl -si

- has been off

- turned it on now:

No ALTQ support in kernel

ALTQ related functions disabled

Status: Enabled for 0 days 01:44:30 Debug: Urgent

....


ifconfig -a

1) Yup, the server is on eth0

2) I also have this utun0:

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380

inet6 fe80::bc72:d1bb:6775:955%utun0 prefixlen 64 scopeid 0x7

inet6 fd84:3088:1863:5d4e:bc72:d1bb:6775:955 prefixlen 64

nd6 options=1<PERFORMNUD>


3) Once I start the Tunnelblick server, I also get utun1:

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

inet 192.168.xx.1 --> 192.168.xx.2 netmask 0xffffffff


server config.ovpn:

server 192.168.xx.0 255.255.255.0

route 192.168.xx.1 255.255.255.0

route 192.168.xx.0 255.255.255.0


(further down:)

push "route 192.168.xx.1 255.255.255.0"

push "route 192.168.xx.0 255.255.255.0"


EDIT:

Tunnelblick log errors/possible problems when starting the server (yellow/blue highlighted bits):

2016-05-25 19:13:03 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2016-05-25 19:13:03 WARNING: potential conflict between --local address [192.168.xx.89] and --ifconfig address pair [192.168.xx.1, 192.168.xx.2] -- this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)

2016-05-25 19:13:03 /sbin/ifconfig utun1 delete

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2016-05-25 19:13:03 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2016-05-25 19:13:03 /sbin/ifconfig utun1 192.168.xx.1 192.168.xx.2 mtu 1500 netmask 255.255.255.255 up

2016-05-25 19:13:03 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun1 1500 1542 192.168.xx.1 192.168.xx.2 init

**********************************************

Start of output from client.up.tunnelblick.sh

NOTE: No network configuration changes need to be made.

WARNING: Will NOT monitor for other network configuration changes.

WARNING: Will NOT disable IPv6 settings.

DNS servers '192.168.xx.1' were set manually

DNS servers '192.168.xx.1' will be used for DNS queries when the VPN is active

NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.

Flushed the DNS cache via dscacheutil

/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

Notified mDNSResponder that the DNS cache was flushed

End of output from client.up.tunnelblick.sh

**********************************************

May 28, 2016 8:09 AM in response to essandess

Hi again. Spent a couple of more hours on this today.


This time I added I moved the VPN clients onto the 192.168.100.xx subnet as suggested.


I propagated this change to config.ovpn (server 192.168.100.0 255.255.255.0 etc) and pf.conf like this:

# $vpn_net == utun0/24 when Tunnelblick creates utun0

vpn_net = "192.168/16"
# utun0 interface doesn't exist at boot time

...

int_if = "en0"

tun_if = "utun0"

no nat on ! $tun_if from $vpn_net to ($int_if)

nat on ! $tun_if from $vpn_net to ! ($int_if) -> ($int_if)

...

pass in quick on $tun_if reply-to $tun_if from $vpn_net to $int_if


enable-vpn-forward-nat.sh is enabled and the daemon is loaded.

pfctl is enabled

en0 is indeed where my ethernet cabled is plugged into the server. Verified through system report as well as Terminal (ifconfig -a).

The VPN service in OSX Server.app is disabled.


The server now starts without conflicts (as opposed to before) and I can connect to it from clients without any errors as well. Clients get 192.168.100.xx IP and I can ping my server successfully (ping 192.168.xx.89 - my server).


Internet still does not work (neither websites by name nor IP) and AFP/VNC to the server do not work either.


Any ideas as to what I could be doing wrong?


Thanks.

May 29, 2016 6:43 AM in response to essandess

Thanks for the reply. I do not think it is the DNS issue - internet websites do not open via their IP's either. I'm using Google DNS for both the server itself (Network preferences) and the server's vpn config. Excluding push "dhcp-option DNS 8.8.8.8" from the server config doesn't really change anything. FWIW, this is my vpn server config: http://pastebin.com/LEmNjSk7 very simple.


I am leaning towards a pf.conf issue. Here's what it looks like atm (edited out the comments and excluded lines for clarity's sake):

http://pastebin.com/7vj7cKhq


1.) Line 28 (pass in quick on $tun_if reply-to $tun_if from $vpn_net to $int_if) - should this be moved right after my line 15?

2.) Lines 61&62 - are these correct with $vpn_net in there as such? Should there perhaps be 4 lines - two with and two without $vpn_net?

3.) Am I missing anything else in it? Anything else wrong?

4.) Reading your (I assume) thread here: http://serverfault.com/questions/555594/troubleshoot-broken-tcp-from-openvpn-cli ent-to-server-but-ping-traceroute-work, should I be doing nat on en0 from { 10.8.0.0/24 10.0.1.0/24 } to any -> (en0) / pass all in my pf.conf?


Thanks.

May 30, 2016 6:24 AM in response to essandess

Further to my questions above, I may be onto something:


Running sudo tcpdump -n -e -ttt -i pktap,en0,utun0 udp port 443, I get the following after the client connects to the vpn:


00:00:00.124010 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

00:00:02.077416 <SERVER FIREWIRE MAC ADDRESS> > <<SERVER ETHERNET MAC ADDRESS>>, ethertype IPv4 (0x0800), length 95: <SERVER LOCAL IP>.443 > <CLIENT PUBLIC IP>.65442: UDP, length 53

00:00:00.805616 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

00:00:00.125637 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

00:00:08.891086 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

00:00:00.000338 <SERVER FIREWIRE MAC ADDRESS> > <<SERVER ETHERNET MAC ADDRESS>>, ethertype IPv4 (0x0800), length 95: <SERVER LOCAL IP>.443 > <CLIENT PUBLIC IP>.65442: UDP, length 53

00:00:00.128451 <SERVER ETHERNET MAC ADDRESS> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

00:00:10.008615 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 95: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 53

00:00:00.000224 <SERVER FIREWIRE MAC ADDRESS> > <<SERVER ETHERNET MAC ADDRESS>>, ethertype IPv4 (0x0800), length 95: <SERVER LOCAL IP>.443 > <CLIENT PUBLIC IP>.65442: UDP, length 53

00:00:10.001275 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 95: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 53

00:00:00.000210 <SERVER FIREWIRE MAC ADDRESS> > <<SERVER ETHERNET MAC ADDRESS>>, ethertype IPv4 (0x0800), length 95: <SERVER LOCAL IP>.443 > <CLIENT PUBLIC IP>.65442: UDP, length 53

00:00:06.919615 <<SERVER ETHERNET MAC ADDRESS>> > <SERVER FIREWIRE MAC ADDRESS>, ethertype IPv4 (0x0800), length 151: <CLIENT PUBLIC IP>.65442 > <SERVER LOCAL IP>.443: UDP, length 109

etc etc


Is there a reason to get the Server's Firewire involved into this? Wouldn't it be logical that my client's MAC address would appear in the above tcpdump? I am not using firewire on my mac mini at all.


I'm stuck at what to do next though. I did test the pf.conf rules with sudo pfctl -v -n -f /etc/pf.conf and they run just fine. I compared them with the original pf.conf on https://github.com/essandess/osx-openvpn-server/blob/master/pf.conf and the only difference is "vpn_net = "10.8.0/24"" changed to "vpn_net = "192.168.0/16"" line. I was also toying around with either included or excluded "pass in proto udp from { lo0 $vpn_net $int_if:network } to { lo0 $int_if } port $lan_udp_services" line and then various permutations of that with 'set nameserver' and 'do not set nameserver' in tunnelblick server, but no dice. Are there specific settings for Tunnelblick that should work?

Jun 2, 2016 8:20 AM in response to essandess

Ok, internet access fixed now 🙂. Thank you! It was a pf.conf issue indeed, specifically the 'block all' line. Once I commented that bit out, I could reach the internet over VPN. A quick IP check verifies that my location is the same as server's location, so all good on that front.


However, I do not have access to the server itself via VPN. VNC and AFP both fail over VPN (while they both work over SSH).


This is my pf.conf now (I've removed filtering rules to keep it as simple as possible/as I am not (yet) using osxfortress):


vpn_net = "192.168/16" # utun0 interface doesn't exist at boot time

scrub-anchor "com.apple/*"


int_if = "en0"

tun_if = "utun0"

no nat on ! $tun_if from $vpn_net to ($int_if)

nat on ! $tun_if from $vpn_net to ! ($int_if) -> ($int_if)


pass in quick on $tun_if reply-to $tun_if from $vpn_net to $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"


# OS X Server Adaptive Firewall

# Comment out for nonOS X Server instances

anchor "com.apple.server-firewall/*"

load anchor "com.apple.server-firewall" from "/etc/pf.anchors/com.apple.server-firewall"


Anything I'm missing in there?


Thank you.

Jun 6, 2016 10:08 AM in response to UrosR

Figured it out now, essandess. The solution was this:


Due to:


ifconfig -a

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380

inet6 fe80::bc72:d1bb:6775:955%utun0 prefixlen 64 scopeid 0x7

inet6 fd84:3088:1863:5d4e:bc72:d1bb:6775:955 prefixlen 64

nd6 options=1<PERFORMNUD>


And after starting the Tunnelblick server, getting utun1 as well:


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

inet 192.168.100.1 --> 192.168.100.2 netmask 0xffffffff


I had to change the following in pf.conf:


from tun_if = "utun0" into tun_if = "utun1"


Now remote clients have access to the services running on the server as well (VNC, AFP, SMB, etc.) 🙂.


I do wonder why this was required. Perhaps a change in Tunnelblick? Or a recent El Capitan change?

Jun 18, 2016 7:52 AM in response to essandess

Hi Guys, two very stupid question but cannot get out of it.

1. Is there a way to avoid continuously having the request for a password being prompted upon connection ? I expected to have it being saved on my keychain but cannot flag it ...

2. In my server config I added a log (or log-append) entry but nothing occours (I would like to keep a connection log history)

Thanks in advance

Jun 18, 2016 12:49 PM in response to tramax73

tramax73 wrote:


Hi Guys, two very stupid question but cannot get out of it.

1. Is there a way to avoid continuously having the request for a password being prompted upon connection ? I expected to have it being saved on my keychain but cannot flag it ...

2. In my server config I added a log (or log-append) entry but nothing occours (I would like to keep a connection log history)

Thanks in advance

I presume you added a password to the certificate when you created it with using OpenSSL. I wouldn't expect that the OpenVPN app would be granted access to the iOS keychain, so if the cert is password protected, you may need to enter the password every time. If you don't want to do that, remove the cert's password protection.

Jun 18, 2016 3:12 PM in response to essandess

Hi Essandess, thanks for replying. I express myself wrongly with the term "keychain". Everything is perfect with Tunnelblick. Connection and - so far - reliability. I meant that when I click con the connect button I'm requested the password as - for security reason - the cfg is shadowed. If I disconnect and re-connect, password prompted again. So if I restart as I have Tunnelblick to start at login. I need T/B to connect to my cfg without user intervention so that, in case of problems, I just reboot my server and I have my vpn up and running. With keychain I meant the osx credential storage granted as root.

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 Account.