essandess

Q: 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:51 AM

Close

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

  • All replies
  • Helpful answers

first Previous Page 5 of 5
  • by essandess,

    essandess essandess May 25, 2016 2:44 AM in response to UrosR
    Level 1 (28 points)
    Applications
    May 25, 2016 2:44 AM in response to UrosR

    Looks like either a sysctl/pf configuration issue, or possibly a subnet issue crossing between 192.168/16 and 10/8.

     

    You'll need to go through the setup step-by-step and troubleshoot.

     

    sysctl: /Library/Application Support/vpn/enable-vpn-forward-nat.sh

     

    Check that these flags are all set correctly:

     

    /usr/sbin/sysctl net.inet.ip.fw.enable

    net.inet.ip.fw.enable: 1

    /usr/sbin/sysctl net.inet.ip.forwarding

    net.inet.ip.forwarding: 1

    /usr/sbin/sysctl net.inet6.ip6.forwarding

    net.inet6.ip6.forwarding: 1

     

    If not, run the shell script and make sure the launch daemon is loaded.

     

    pf: /etc/pf.conf

     

    Enabled?

     

    sudo pfctl -si

     

    VPN rules correct?

     

    vpn_net = "10.8.0/24"   # 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

     

    Is en0 the correct interface on your box?

     

    ifconfig -a

     

    Debug with tcpdump, e.g.:

     

    sudo tcpdump -n -e -ttt -i pktap,en0,utun0 tcp port 80

     

    Try putting the VPN server on a 192.168/16 subnet with the server directive in config.ovpn:

     

    server 192.168.100.0 255.255.255.0

     

    You'll need to propagate this change to other config files like pf.conf.

  • by UrosR,

    UrosR UrosR May 25, 2016 10:20 AM in response to essandess
    Level 1 (4 points)
    Servers Enterprise
    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

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

  • by UrosR,

    UrosR UrosR May 28, 2016 8:09 AM in response to essandess
    Level 1 (4 points)
    Servers Enterprise
    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.

  • by essandess,

    essandess essandess May 28, 2016 7:28 PM in response to UrosR
    Level 1 (28 points)
    Applications
    May 28, 2016 7:28 PM in response to UrosR

    The most likely foul-up is DNS. Try hitting an external IP address directly without DNS lookup.

     

    If that fails, the next most like foul-up is some pf rule issue, including order of the rules. Compare with the working pf.conf line-by-line, and/or use tcpdump on the server to figure out where the blockage is.

  • by UrosR,

    UrosR UrosR May 29, 2016 6:43 AM in response to essandess
    Level 1 (4 points)
    Servers Enterprise
    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.

  • by UrosR,

    UrosR UrosR May 30, 2016 6:24 AM in response to essandess
    Level 1 (4 points)
    Servers Enterprise
    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?

  • by UrosR,

    UrosR UrosR Jun 2, 2016 8:20 AM in response to essandess
    Level 1 (4 points)
    Servers Enterprise
    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.

  • by UrosR,

    UrosR UrosR Jun 6, 2016 10:08 AM in response to UrosR
    Level 1 (4 points)
    Servers Enterprise
    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?

  • by tramax73,

    tramax73 tramax73 Jun 18, 2016 7:52 AM in response to essandess
    Level 1 (8 points)
    Mac OS X
    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

  • by essandess,

    essandess essandess Jun 18, 2016 12:44 PM in response to UrosR
    Level 1 (28 points)
    Applications
    Jun 18, 2016 12:44 PM in response to UrosR

    > tun_if="utun1"

     

    Best guess is that OS X remembers interface configurations and assigns new numbers in some circumstances, e.g. cloning onto a replacement box.

     

    There must be some way to clear this out. See man ifconfig, then something like:

     

    sudo ifconfig utun0 delete

  • by essandess,

    essandess essandess Jun 18, 2016 12:49 PM in response to tramax73
    Level 1 (28 points)
    Applications
    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.

  • by tramax73,

    tramax73 tramax73 Jun 18, 2016 3:12 PM in response to essandess
    Level 1 (8 points)
    Mac OS X
    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.

first Previous Page 5 of 5