2
1
I am trying to setup SSH based VPN between 2 devices, following the instructions from the website here in a lab environment.
The 2 devices are Kali Linux 2017.1 (client), and Ubuntu Linux Mint 18.2 (server). The IP addresses of the devices are:
- Kali Linux (client) - 192.168.56.103, VPN endpoint IP: 1.1.1.2
- Linux Mint (server) - 192.168.56.102, VPN endpoint IP: 1.1.1.1.
I have performed the following steps on each device.
On client,
sudo ssh -w 0:0 root@192.168.56.102
ip link set tun0 up
ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0
On server,
service ssh start
ip link set tun0 up
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0
The output from client is shown below:
$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 1.1.1.2 netmask 255.255.255.255 destination 1.1.1.1
inet6 fe80::73bc:5f32:6ba2:9419 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 597 bytes 50040 (48.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 602 bytes 50280 (49.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The output from server is shown below:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:1.1.1.1 P-t-P:1.1.1.2 Mask:255.255.255.255
inet6 addr: fe80::d0f:d97a:3bc0:c1ad/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:56256 (56.2 KB)
While the tunnel IPs are setup, I am unable to communicate icmp pings between the 2 IPs - 1.1.1.1, 1.1.1.2
If I start ping from server to client, I can see that the client is receiving the pings from the server and responding, but the server is not receiving the replies.
So on server, I have started the pings and monitor tcpdump response.
$ ping 1.1.1.2
$ sudo tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:07:01.494334 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 810, length 64
03:07:02.517661 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 811, length 64
03:07:03.541852 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 812, length 64
On client, I see the following responses being sent by client in tcpdump, but these are not registered by the server
$ tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:09:48.485679 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1125, length 64
03:09:48.485711 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1125, length 64
03:09:49.510028 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1126, length 64
03:09:49.510052 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1126, length 64
Can anyone spot why I am not able to communicate between the client and server? I am not able to successfully send any network protocol (not just icmp) between the client and server.
I have tried the following already:
On server side, I have made sure that PermitTunnel is enabled and root user is used as per the requirements stated in the documentation.
I have removed all iptables firewall rules and checked that default policy is ACCEPT.
iptables -t nat -F iptables -t filter -F iptables -t mangle -F
I have disabled and removed ufw for testing by:
sudo ufw disable sudo apt-get remove ufw
Tried looking for other instructions here and here, but they didn't give me any clues on what the issue could be.
Here is my sshd_config file from the server.
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
#PermitRootLogin prohibit-password
PermitRootLogin yes
PermitTunnel yes
StrictModes yes
GatewayPorts yes
AllowTcpForwarding yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
UPDATE: As per feedback from dirkt, I have now used internal IP addresses. 10.1.1.1 instead of 1.1.1.1, 10.1.1.2 instead of 1.1.1.2. However, the issue still persists.
On Client,
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.1.1.1 netmask 255.255.255.255 destination 10.1.1.2
inet6 fe80::23ca:f7ce:e4c7:24c8 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 316 bytes 26436 (25.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 320 bytes 26628 (26.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
On Server,
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.1.2 P-t-P:10.1.1.1 Mask:255.255.255.255
inet6 addr: fe80::e633:5f17:9b14:ae06/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:15936 (15.9 KB)
Also, here is the routing table from ip route commands:
On Client,
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
10.1.1.2 dev tun0 proto kernel scope link src 10.1.1.1
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103 metric 100
On Server,
default via 10.0.2.2 dev enp0s3 proto static metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
10.1.1.1 dev tun0 proto kernel scope link src 10.1.1.2
169.254.0.0/16 dev enp0s3 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-56e99b53b1be proto kernel scope link src 172.18.0.1 linkdown
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.102 metric 100
UPDATE On running telnet, it is clear that traffic is being forwarded from Kali Linux (client) to Linux Mint (server), but not the other way around. Even after port 12345 is opened on client, SynAck packets are not being registered by the client at all.
On server, we run following:
telnet 10.1.1.1 12345
Trying 10.1.1.1....
On server, we see syn packets to client
tcpdump -ni tun0
root@linuxmint-VirtualBox /home/linuxmint # tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:47:28.869970 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598500 ecr 0,nop,wscale 7], length 0
17:47:29.874205 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598752 ecr 0,nop,wscale 7], length 0
17:47:31.890376 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2599256 ecr 0,nop,wscale 7], length 0
On client, we see the reset responses going back but telnet just sits there.
tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:47:18.918860 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605333 ecr 0,nop,wscale 7], length 0
17:47:18.918899 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 3064866771, win 0, length 0
17:47:19.921367 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605584 ecr 0,nop,wscale 7], length 0
17:47:19.921412 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 1, win 0, length 0
First thing to do is to use proper private internet addresses (e.g.
– dirkt – 2017-08-21T19:51:15.58010.1.1.1
instead of1.1.1.1
), and check the routing table (ip route
) on both server and client.Thanks dirkt - good point, I should use private IPs. I have now updated the tunnel IPs from 10.1.1.1 to 1.1.1.1, and copied routing table above. However, the issue still persists. It is strange that the client is receiving the pings as seen from tcpdump, and responding but the server is not receiving these ping replies. =( – John – 2017-08-22T07:23:33.827
Can the tunnel pass traffic? For example, what happens if you try e.g.
telnet 10.1.1.1 12345
(or any other port not in use)? Does it just sit there for a while and ultimately time out, or does it respond promptly with a "connection refused"? What if you try a port that is in use and open on the remote system, does it connect? – a CVn – 2017-08-22T07:28:59.427Hi Michael, the tunnel is forwarding traffic from LinuxMint (server) to Kali (client), but no traffic from client to server. If I telnet 10.1.1.1 (client) 12345 from the server - the tunnel just sits there. But if I run tcpdump on both server and client, I can see that the tcp syn packets reach the client and the client responds with reset packet. But the tcpdump on server is not displaying the inbound reset packets.
If I open port on client side e.g. nc -nvvl -p 12345, I can see syn packets being sent instead of reset from client, but they are not displaying in tcpdump on server. – John – 2017-08-22T07:54:58.730
Hm. Wild guess: Check versions of
ssh
andsshd
, if they differ, see if you can install different versions. Also, use verbose/debug options-v
and-d
(see man pages) to get debug output, and see if anything looks fishy. – dirkt – 2017-08-22T08:14:08.653