Tunnelblick on Mavericks With pfctl, ipfw

[ss]

My tunnelblick ipfw setup no longer works with Mavericks, though it worked fine on Mountain Lion. I used ipfw to divert all natd packets. allowing VPN LAN IPs on, say 10.2.1.0/24 to 10.0.1.0/24. Now VPN no longer works, and if I run this ipfw script, it breaks my servers internet and LAN access as well!

It looks like ipfw and natd are obsolete on OS X, and it's finally time to learn how to implement divert using pfctl.

Has anyone used pfctl with tunnelblick? What are the command to obtain a divert, as done below with natd/ipfw?

#!/bin/bash
#
# Reference: 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/natd -interface en0
/sbin/ipfw add divert natd ip from any to any via en0

The natd command throws the error on Mavericks:

natd: Unable to bind divert socket.: Address already in use

[László Sándor]

Hey ss,

I am not sure how closely my problem is related, but in any case, I am not sure I can do anything with pfctl on Mavericks. Don't you get an error of "No ALTQ support in kernel / ALTQ related functions disabled" Or you already meant the Server version? Do we need to buy Server.app for simple IP forwarding?

I have a write-up of my problem elsewhere: http://superuser.com/questions/670513/forwarding-a-vms-traffic-to-a-vpn-on-a-mac-possible-only-with-buying-server-a

Please let me know if you're any wise now.

Thanks,

Laszlo

[ss]

I read The Boof of PF and figured it out. 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

and you have to do a lot of trial-and-error to make sure you don't break your access while integrating these rules into OS X Server's basic rule set. A description of the complete setup with the following pf.conf is here.

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

[László Sándor]

Thanks, Steve!

IceFloor sounds useful for these purposes, no?

http://www.hanynet.com/icefloor/index.html

--
You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/nsRZGp37RAM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[ss]

I've discovered that a default block all policy breaks too many services on OS X Server, and the pass rules above are inadequate, so I've reverted to this bare-bones, much more permissive firewall, which still accomplishes NAT for OpenVPN.

# References for modifications:

pass all

 

If someone knows how to get a reliable "block all" default firewall, please post the pf.conf. You can see the blocked packets using the commands

sudo ifconfig pflog0 create
sudo tcpdump -n -e -ttt -i pflog0

To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsub...@googlegroups.com.

[ss]

Still some issues getting packets between VPN clients and services on the VPN Server. Any pointers would be appreciated. IceFloor is a really nice GUI, but also has this issue, so this approach is missing some basic ingredient.

For example, hitting a VNC server while running tcpdump 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.

More details for those who'd be able to suggest a fix:

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

Is anyone able to suggest pfctl or other fixes that allow VPN clients on tun0 to access services on the same VPN server available on interface en0?

Here's the dump of tun0 showing packets going to the VNC service on tun0. The dump above shows them leaving the VNC service on interface en0. Are they supposed to be routed back to tun0 somehow? How?

I can ping my server from VPN clients, but nmap fails, and VNC clients fail to hit 10.0.1.3:5900. Yet tcpdump shows traffic on port 5900 associated with the VPN client. All this stuff works fine when not on VPN and sitting on the LAN.

ping from VPN:

iPad$ ping -c 3 10.0.1.3
PING 10.0.1.3 (10.0.1.3): 56 data bytes
64 bytes from 10.0.1.3: icmp_seq=0 ttl=64 time=38.303 ms
64 bytes from 10.0.1.3: icmp_seq=1 ttl=64 time=37.200 ms
64 bytes from 10.0.1.3: icmp_seq=2 ttl=64 time=36.507 ms
--- 10.0.1.98 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 36.507/37.337/38.303/0.740 ms

nmap from VPN client:

iPad$ nmap -p 5900 10.0.1.3
Starting Nmap 5.00 ( http://nmap.org ) at 2013-11-10 11:00 EST
Note: Host seems down. If it is really up, but blocking our ping probes , try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.28 seconds

tcpdump on server interfaces en0 and tun0 during VPN client access:

server$ sudo tcpdump -n -e -ttt -i en0 port 5900
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 c4:2f:03:0b:01:9d > b8:37:5d:de:dc:24, ethertype IPv4 (0x0800), length 78: 10.0.1.3.5900 > 10.8.0.10.52892: Flags [S.], seq 500616894, ack 2287587651, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 922913452 ecr 546523456,sackOK,eol], length 0
00:00:05.881495 c4:2f:03:0b:01:9d > b8:37:5d:de:dc:24, ethertype IPv4 (0x0800), length 78: 10.0.1.3.5900 > 10.8.0.10.52892: Flags [S.], seq 500616894, ack 2287587651, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 922918265 ecr 546523456,sackOK,eol], length 0 00:00:04.620650 c4:2c:03:0b:51:9d > b8:c7:5d:d0:dc:14, ethertype

server$ sudo tcpdump -n -e -ttt -i tun0 port 5900

00:00:00.142140 AF IPv4 (2), length 68: 10.8.0.10.53295 > 10.0.1.3.5900: Flags [S], seq 2223347580, win 65535, options [mss 1368,nop,wscale 4,nop,nop,TS val 566298513 ecr 0,sackOK,eol], length 0

[Randy Witlicki]

  Hello Mr. Smith,

  How do the routing tables look on the server and the client (with and without the VPN connection up)?

  e.g.  from the netstat -rn  command (that is r followed n in the command)

  xxxxx out an sensitive network information if you post any output.

  This seems to be an OpenVPN issue more than a tunnelblick issue, so maybe a search of the OpenVPN forum archives might help.

  Randy

--

[ss]

Hi Randy -- thanks. I suspect this is some simple issue with adding the correct route command at bootup or a redirirect in pfctl, but I'm not sure where to start. I'd appreciate any pointers, even if it's suggesting the right questions to ask over at OpenVPN.

Here's what I've got:

With VPN server up and running:

sudo netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.0.1.1           UGSc          134        0     en0
10                 link#4             UCS             7        0     en0
10.0.1.1           xx:xx:xx:xx:xx:xx  UHLWIir       138     3870     en0   1006
10.0.1.2           xx:xx:xx:xx:xx:xx   UHLWI           0   494245     en0     86
10.0.1.5           xx:xx:xx:xx:xx:xx    UHLWI           0        2     en0   1046
10.0.1.98          127.0.0.1          UHS            33   204457     lo0
10.0.1.112         xx:xx:xx:xx:xx:xx   UHLWI           0       24     en0    988
10.0.1.113         xx:xx:xx:xx:xx:xx  UHLWI           0     6218     en0    482
10.0.1.114         xx:xx:xx:xx:xx:xx  UHLWI           0     4892     en0    956
10.8/24            10.8.0.2           UGSc            0        0    tun0
10.8.0.2           10.8.0.1           UH              1        0    tun0
10.255.255.255     xx:xx:xx:xx:xx:xx  UHLWbI          0       25     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             44   716073     lo0
169.254            link#4             UCS             1        0     en0
169.254.102.138    xx:xx:xx:xx:xx:xx   UHLSW           0        6     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::xxxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx                UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx                 UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWIi          en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx                UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx                 UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0


With VPN server down and all OpenVPN processes shut down:

sudo netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.0.1.1           UGSc          114        0     en0
10                 link#4             UCS             7        0     en0
10.0.1.1           xx:xx:xx:xx:xx:xx  UHLWIir       119     3815     en0    881
10.0.1.2           xx:xx:xx:xx:xx:xx  UHLWI           0   494245     en0    623
10.0.1.3           127.0.0.1          UHS            29   203620     lo0
10.0.1.5           xx:xx:xx:xx:xx     UHLWI           0        2     en0    437
10.0.1.112         xx:xx:xx:xx:xx:xx  UHLWI           0       20     en0    623
10.0.1.113         xx:xx:xx:xx:xx:xx  UHLWI           0     6218     en0   1019
10.0.1.114         xx:xx:xx:xx:xx:xx  UHLWI           0     4887     en0    883
10.255.255.255     xx:xx:xx:xx:xx:xx  UHLWbI          0       47     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             35   713714     lo0
169.254            link#4             UCS             1        0     en0
169.254.102.138    xx:xx:xx:xx:xx:xx  UHLSW           0        6     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWIi          en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0

--
You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/nsRZGp37RAM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to tunnelblick-dis...@googlegroups.com.

Visit this group at http://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[Randy Witlicki]

   Hi,

   It looks like the local network on en0 is all of the 10. net (I see a 10.255.255.255 net mask).

   I don't think you can push part of the 10. network over the OpenVPN tun0 network.

   Look in the server logs then the OpenVPN server starts for routing problems when it tries to create tun0

   Maybe try pushing one of the other reserved private networks over the VPN connection:

   RFC 1918 specifies the reserved private networks to be:

     10.0.0.0 to 10.255.255.255

     172.16.0.0 to 172.31.255.255.255    and;

     192.168.0.0 to 192.168.255.255  

   So, maybe try to push 172.16.0.0 with a 0.255.255.255 net mask

  Randy

   

On Nov 11, 2013, at 12:27 PM, ss <steve....@gmail.com> wrote:

Hi Randy -- thanks. I suspect this is some simple issue with adding the correct route command at bootup or a redirirect in pfctl, but I'm not sure where to start. I'd appreciate any pointers, even if it's suggesting the right questions to ask over at OpenVPN.

Here's what I've got:

With VPN server up and running:

sudo netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire

default            10.0.1.1           UGSc          141        0     en0

10                 link#4             UCS             7        0     en0

10.0.1.1           xx:xx:xx:xx:xx:xx  UHLWIir       145     3452     en0    527
10.0.1.2           x:xx:xx:xx:xx:xx   UHLWI           0   494243     en0    741
10.0.1.3           127.0.0.1          UHS            27    83892     lo0
10.0.1.101         xx:xx:xx:xx:xx:xx  UHLWI           0        1     en0    827
10.0.1.112         xx:xx:xx:xx:xx:xx  UHLWI           0        9     en0    460
10.0.1.113         xx:xx:xx:xx:xx:xx  UHLWIi          3     1265     en0    705
10.0.1.114         xx:xx:xx:xx:xx:xx  UHLWIi          1     4877     en0    529
10.255.255.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        4     en0

127                127.0.0.1          UCS             0        0     lo0

127.0.0.1          127.0.0.1          UH             39   709196     lo0

169.254            link#4             UCS             1        0     en0
169.254.102.138    xx:xx:xx:xx:xx:xx  UHLSW           0        6     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0

fe80::xxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx               UHLWI           en0
fe80::xxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx                  UHLWI           en0
fe80::xxx:xxxx:xxxx:xxxx%en0            xx:xx:xx:xx:xx:xx               UHLWI           en0

fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWIi          en0
fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWIi          en0

fe80::xxxx:xxxx:xxxx:xxxx%en0           x:xx:xx:xx:xx:xx                UHLWI           en0

fe80::xxxx:xxxx:xxxx:xxxx%en0           xx:xx:xx:xx:xx:xx               UHLWI           en0

fe80::xxxx:xxxx:xxxx:xxx%en0            xx:xx:xx:xx:xx                  UHLI            lo0

ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0


With VPN server down and all OpenVPN processes shut down:

sudo netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.0.1.1           UGSc          114        0     en0
10                 link#4             UCS             7        0     en0
10.0.1.1           xx:xx:xx:xx:xx:xx  UHLWIir       119     3815     en0    881
10.0.1.2           xx:xx:xx:xx:xx:xx  UHLWI           0   494245     en0    623

10.0.1.5           xx:xx:xx:xx:xx     UHLWI           0        2     en0    437

10.0.1.98          127.0.0.1          UHS            29   203620     lo0

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.

[ss]

I believe that I've ruled out pf as the problem, which means that either OpenVPN or Tunnelblick on Mavericks is the problem.

(BTW, sorry for my original cut-and-paste error -- tun0 appears in my routing table in the corrected post above, and I've set the netmask on en0 to 10.0.1/24.)

First, completely disable pf with pfctl -d.

I am able to ssh FROM the server TO my VPN client, but I am not able FROM the VPN client TO the server. It appears that the VPN is not returning [SYN,ACK] packets correctly from the server to the VPN client over tun0. What would prevent packets from VPN clients reaching the LAN through the tun0 interface? Packets to the VPN client are being returned on en0, not tun0, and this is breaking the connection. This illustrated with this example below using wireshark to capture port 22 packets on tun0 and en0.

Would you please suggest additional troubleshooting to localize the problem? My OpenVPN server configuration? (This worked fine prior to Mavericks.) Tunnelblick? OpenVPN?


server [10.0.1.3]$ ssh mob...@10.8.0.10   # Successful

tun0:

10.8.0.1 -> 10.8.0.10 ssh [SYN]
10.8.0.10 ssh -> 10.8.0.1 [SYN,ACK]
10.8.0.1 -> 10.8.0.10 ssh [ACK]
...

en0:

<No packets>


iPhone [10.8.0.10]$ ssh us...@10.0.1.3   # Unsuccessful

tun0:

10.8.0.10 -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
10.8.0.10 [TCP Retransmission] -> 10.0.1.3 ssh [SYN]
...

en0:

10.0.1.3 ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
10.0.1.3 [TCP Retransmission] ssh -> 10.8.0.10 [SYN,ACK]
...

[ss]

P.S. I don't see a gateway for 10.8.0.1 == tun0 in the routing table from 'netstat -rn' above -- could this be the issue? ifconfig says this:

server$ ifconfig tun0
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 10.8.0.1 --> 10.8.0.2 netmask 0xffffffff
    open (pid 43667)

[ss]

I'm working through the book Network Troubleshooting Tools trying to track this down. Its first example using netstat shows a routing table that looks like this, with explicit resolution for the 172.16.2.1 and 172.16.2.255 addresses.

bsd1# netstat -rn
Routing tables
Internet:
Destination
…
172.16.1/24 172.16.2.1 xl1
172.16.2/24 link#2 xl1
172.16.2.1 0:10:7b:66:f7:62 xl1
172.16.2.255 ff:ff:ff:ff:ff:ff xl1


But my actual routing table for tun0 looks like this:

server$ netstat -rn
default 10.0.1.1 UGSc 157 21721 en0
…
10.8/24 10.8.0.2 UGSc 1 6 tun0
10.8.0.2 10.8.0.1 UH 2 0 tun0


There's nothing explicit for 10.8.0.1 or 10.8.0.255 on the tun0 interface—should there be? If so, how do add I this route? Could this be why return packets from the server are being sent back on the default en0 interface?

[ss]

Thanks to this thread, <http://serverfault.com/questions/478058/routing-traffic-from-vpn-to-different-network-device>, I'm closer to a solution. The server's TCP services ARE all available via the OpenVPN Server's IP, e.g. "ssh us...@10.8.0.1" works, as does hitting http://10.8.0.1/, and every other TCP service.

The remaining trick is to set up the routing tables (somewhere—client? server? both?) so that TCP access like "ssh us...@10.0.1.3" will just work.

I'd be grateful to any network guru's opinion on the way to do this for OpenVPN clients.