I was having the same problem, it was being caused by this iptables rule:
iptables -A FORWARD -j DROP
To fix it, I added these rules before the rule above:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t filter -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
Also, make sure to do this:
echo 1 > /proc/sys/net/ipv4/ip_forward
To resolve this issue you will need to set up both iptables and routing rules. The specific problem you're encountering is that outgoing SSH packets are being routed via your anonymous VPN tunnel interface instead of your Ethernet interface. This is happening because your VPN software set up a routing rule to send any and all unhandled traffic via the tunnel interface. Good for anonymizing your network traffic; bad for establishing SSH connections to your computer.
There are a few ways to fix this problem, but I will share with you the one which worked for me in an identical situation. Here's what we need to do:
- Create a new IP rule table to handle non-VPN traffic
- Add an IP rule to lookup our no-VPN table for any packets marked with a specific netfilter mask
- Add an IP route which directs all traffic in our no-VPN table to use your Ethernet interface instead of the tunnel
- Add an iptables rule to mark all SSH traffic with our designated netfilter mask
Note: I was working with Raspbian while doing the following, so you might need to adjust the commands a little to fit your distro.
Creating a new IP rule table
Begin by inspecting iproute2's table definition file. We want to make sure we don't use the name or number of any existing rule tables.
cat /etc/iproute2/rt_tables
You'll likely see something along these lines:
# reserved values
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
Pick an arbitrary number and name for your new rule table -- anything not used above. I will use number 201 and name novpn
for the remainder of this answer.
Append a definition directly to the definition file or edit it in the text editor of your choice:
echo "201 novpn" >> /etc/iproute2/rt_tables
Add a new IP rule to lookup the no-VPN table
Check for any existing ip rules that deal with netfilter masks:
ip rule show | grep fwmark
If grep turns up nothing, you're in the clear. If it does print some lines, take note of the hexadecimal number to the right of the word fwmark
in each line. You will need to pick a number that is not currently in use. Since I had no existing fwmark rules, I chose the number 65.
ip rule add fwmark 65 table novpn
What this does is cause any packets with netfilter mask 65 to lookup our new novpn
table for instructions on how to route the packets.
Direct all traffic in our new table to use the Ethernet interface
ip route add default via YOUR.GATEWAY.IP.HERE dev eth0 table novpn
The important thing to note here is dev eth0
. This forces all traffic that passes through the novpn
table to only use the hardware Ethernet interface, instead of the virtual tunnel interface that your VPN creates.
Now would be a good time to flush your iproute cache, to make sure your new rules and routes take immediate effect:
ip route flush cache
Instruct firewall rule to mark all SSH traffic with the designated netfilter mask
iptables -t mangle -A OUTPUT -p tcp --sport 22 -j MARK --set-mark 65
There are too many options here for me to explain in any great depth. I strongly encourage you to read the manual page for iptables to get a sense of what's going on here:
man iptables
In a nutshell: we are appending an output rule to the firewall's mangle table (for specialized packet handling) that instructs it to mark any TCP packets originating from source port 22 with our designated netfilter mask 65.
What next?
At this point, you should be ready to test SSH. If all goes well, you should be met with the happy "login as" prompt.
For security's sake, I recommend you instruct your firewall to drop any incoming SSH requests from the tunnel interface:
iptables -A INPUT -i tun0 -p tcp -m tcp --dport 22 -j DROP
Note that the all of the instructions above are transient (except for the creation of the rule table ID) -- they will clear the next time you restart your computer. Making them permanent is an exercise I leave to you.
Best Answer
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:
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:
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...
Finally pings were returned.