I'm troubleshooting an OpenVPN Server setup on OS X Mavericks. Prior to the 10.9 upgrade, this all worked, and I'm trying to isolate the problem to something fundamental or my server/client setup.
VPN clients are able to make TCP connections to the entire Internet and every box on the LAN except for the VPN server itself. Furthermore, VPN clients are able to successfully ping and traceroute the server, which is one hop away.
I'm at a loss and would appreciate any pointers.
My server is 10.0.1.3 on 10.0.1/24 interface en0. My VPN is on 10.8.0/24 on tun0. The firewall is disabled, but it is necessary to enable NAT on the pf-based firewall for client access to the Internet, which is done using the pfctl pf.conf lines,
nat on en0 from { 10.8.0.0/24 10.0.1.0/24 } to any -> (en0)
pass all
The broken TCP return link observed between the server and client exists whether or not the firewall is enabled, causing me to rule out the firewall as the cause. Packet forwarding is enabled with the BSD commands:
/usr/sbin/sysctl -w net.inet.ip.fw.enable=1
/usr/sbin/sysctl -w net.inet.ip.forwarding=1
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. Here's what I see on wireshark:
server [10.0.1.3]$ ssh [email protected] # 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 [email protected] # 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]
...
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?
Any pointers would be greatly appreciated.