By comparing two different clients I was able to identify and fix 2 problems.
Problem 1: routing
For some reason (and I'm not sure I've solved this), the server's routing table kept forgetting the route to/from its LAN (10.67.5.0/24). This was causing all outbound LAN traffic to go through its main gateway, which will not route to the OpenVPN LAN (10.67.15.0/24). This was causing traffic from the OpenVPN network destined for the LAN to fail at the main gateway; thus pings were being sent, but the reply was dropped.
Edit: Unfortunately I do not know what was causing this route to be dropped; as you can see it was in the routing table above. I tried adding a route command into /etc/network/interfaces, but then I ended up with two duplicate, identical routes, so I took it out again. It was my fwbuilder config that was causing this route to be dropped: when setting up the eth1 adapter I had given a /32 netmask (i.e. a host) instead of /24 (for the LAN).
By testing a Debian client, I was able to figure this one out, after this, it worked, but the Windows 7 client did not.
Problem 2: Windows 7 firewall/config
There were two problems with the Windows set up.
Windows must have the "Work" private profile set for the TAP adapter
Credit for this section goes to kalwi
Update as of 2020-06-11
You can change an interface to private using the following two powershell commands:
# this first one will let you see the available connections,
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private
In the "Network and Sharing Center" you should see (at least) 2 "active networks". I had the wireless network and then an "Unidentified Network". The latter is the OpenVPN TAP device, and it had a park bench icon, meaning it was treated as public, untrusted. In order to be able to change this, you need to add a default gateway for the adapter.
Start a DOS/Cygwin terminal as administrator. (Start Orb > search for CMD > right-click it > run as administrator).
Then do route print -4. You'll see an Interface List. Each line begins with a number and on the right you'll see the name. Identify the interface number for the TAP-Win32 Adapter. Mine was 17.
Now add the route:
route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17
Where 1.2.3.4 needs to be the IP of your OpenVPN gateway (revealed in the Gateway column in the output of the earlier command) and 17 needs to be your TAP interface number. The -p option makes the route permanent. I did it without this first, to test. This does assume that the client's OpenVPN gateway IP is not going to change between connections.
Once you've done that a dialogue box should pop up and ask you to classify the new network. Choose Work.
At this point, I was able to send traffic from my company LAN to the client (tested using netcat), however pings were still going unanswered.
Tell Windows to allow pings (ICMPv4)
Start Orb > Windows Firewall with Advanced Security Then go to Inbound Rules, and New Rule...
- Custom Rule
- All programs
- Protocol: ICMPv4
- Allow the connection
- Apply to Private profile
- Name it.
Finally pings were returned.
