Can't access SSH that is running on the VPN server

chris_burnham

I'm running an OpenVPN server on fresh install of Ubuntu Server 12.04. I setup the server certificate and am running the default server configuration. (Except I disabled client certificates in favor of client authentication).

I installed OpenVPN on a Windows 7 desktop and opened a connection. The connection seems to be working. I can ping the server at 10.8.0.1
I am also running OpenSSH on the Ubuntu Server. I would like to be able to access this, and other services on the machine through the VPN. However, trying to SSH to 10.8.0.1 does not work. The connection basically times out as if no server is running.

It seems to me that if I can ping the OpenVPN server, I should be able to access the other services on the machine. I don't believe that it is a firewall or routing problem. iptables comes back as blank, and ufw is still disabled. Am I misunderstanding how a VPN server works? Is SSH not listening for connections on the VPN interface?

JoshC

It seems to me that if I can ping the OpenVPN server, I should be able to access the other services on the machine. I don't believe that it is a firewall or routing problem. iptables comes back as blank, and ufw is still disabled. Am I misunderstanding how a VPN server works? Is SSH not listening for connections on the VPN interface?

How have you checked your firewall setup? The way to check your complete netfilter ("iptables") status is by showing your full ruleset with:

iptables-save

Next you should verify if the service you are trying to use (ssh in this case) is really listening on the address you're using to connect. Use the ss command for this (ss replaces netstat, which is deprecated.) Check that port 22 is listening on either the wildcard address (*:22) or the IP of your server:

ss -nl | grep ':22'

One of those should be your issue. In rare cases a client-side firewall is blocking the traffic.

You can also use the tcpdump tool (Wireshark or the CLI tshark.exe tool on Windows) to monitor the traffic to a particular port over an interface. For example, to watch TCP port 22 traffic on tun0, you can do:

tcpdump -pni tun0 tcp port 22

and watch the traffic in realtime. If you don't get any packets printed on the screen, there is no matching traffic. Note that tcpdump (at least under Unix-alike systems) will show you firewalled traffic that is dropped before it reaches the application.

chris_burnham

iptables-save returns:

# Generated by iptables-save v1.4.12 on Sat Aug 17 16:52:51 2013
*filter
:INPUT ACCEPT [3421:349998]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1973:252581]
COMMIT
# Completed on Sat Aug 17 16:52:51 2013

I think that means that I haven't configured any rules.

ss -nl | grep ':22'
LISTEN     0      128                      :::22                      :::*
LISTEN     0      128                       *:22                       *:*

That means that it is listening on any interface, correct?

Finally, my tcpdump does report traffic when I attempt a connection:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
16:54:48.135858 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [S], seq 829882624, win 8192, options [mss 1368,nop,nop,sackOK], length 0
16:54:48.135888 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [S.], seq 4183062055, ack 829882625, win 14600, options [mss 1460,nop,nop,sackOK], length 0
16:54:48.224021 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [.], ack 1, win 16616, length 0
16:54:48.237765 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [P.], seq 1:42, ack 1, win 14600, length 41
16:54:48.300320 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [P.], seq 1:29, ack 42, win 16575, length 28
16:54:48.300375 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [.], ack 29, win 14600, length 0
16:54:48.300613 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [P.], seq 29:541, ack 42, win 16575, length 512
16:54:48.300637 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [.], ack 541, win 15544, length 0
16:54:48.300693 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [P.], seq 541:669, ack 42, win 16575, length 128
16:54:48.300707 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [.], ack 669, win 16616, length 0
16:54:48.301892 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [P.], seq 42:1026, ack 669, win 16616, length 984
16:54:48.395232 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [P.], seq 669:685, ack 1026, win 15591, length 16
16:54:48.399737 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [P.], seq 1026:1562, ack 685, win 16616, length 536
16:54:48.574383 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [.], ack 1562, win 16616, length 0
16:54:48.653394 IP 172.24.0.6.33514 > 172.24.0.1.22: Flags [P.], seq 1197:1213, ack 1562, win 16616, length 16
16:54:48.653413 IP 172.24.0.1.22 > 172.24.0.6.33514: Flags [.], ack 685, win 16616, options [nop,nop,sack 1 {1197:1213}], length 0

Those ip addresses seem to be correct. I changed the OpenVPN network to be 172.24.0.0 with net mask 255.255.255.0 because it conflicted with the 10.0.0.0 used on my work network. ifconfig reports those as the ip addresses on those machines. I can ping back and forth. (Though I did need to turn off the Windows Firewall before my server could ping my Windows machine).

Additionally, I have the following log form my Windows machine attempting SSH:

2013-08-17 16:58:43	Looking up host "172.24.0.1"
2013-08-17 16:58:43	Connecting to 172.24.0.1 port 22
2013-08-17 16:58:43	Server version: SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
2013-08-17 16:58:43	Using SSH protocol version 2
2013-08-17 16:58:43	We claim version: SSH-2.0-PuTTY_Release_0.62
2013-08-17 16:58:43	Doing Diffie-Hellman group exchange
2013-08-17 16:58:43	Doing Diffie-Hellman key exchange with hash SHA-256
2013-08-17 16:59:02	Network error: Software caused connection abort

The says to me that packets are being sent back. I can connect to SSH if I do so directly, without the VPN. (I'm doing so now on my private LAN, and I can do so if I forward port 22 on my public IP address). I'm going to check SSH logs to see if I can figure out what is going on.