2

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 [email protected]
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
Improve this question
5
  • First thing to do is to use proper private internet addresses (e.g. 10.1.1.1 instead of 1.1.1.1), and check the routing table (ip route) on both server and client.
    – dirkt
    Commented Aug 21, 2017 at 19:51
  • 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
    Commented Aug 22, 2017 at 7:23
  • 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?
    – user
    Commented Aug 22, 2017 at 7:28
  • Hi 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
    Commented Aug 22, 2017 at 7:54
  • Hm. Wild guess: Check versions of ssh and sshd, 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
    Commented Aug 22, 2017 at 8:14

1 Answer 1

Reset to default
1

The netmask you selected (255.255.255.255) leaves no room for hosts. Technically you have the network-address and broadcast-address on the same address (10.1.1.1). my recommendation is, to change the netmask to 255.255.255.252 if you want to add more hosts (as this netmask leaves only room for two hosts) then I recommend you to change to a lower subnetmask look on google for subnet-calculators for further examples.

Improve this answer
3
  • What is your rationale for saying that?  Please do not respond in comments; edit your answer to make it clearer and more complete.
    – G-Man Says 'Reinstate Monica'
    Commented Jun 18, 2018 at 17:26
  • Now that makes sense.
    – G-Man Says 'Reinstate Monica'
    Commented Jun 18, 2018 at 18:56
  • I was in a bit of a rush earlier, I was already planning to rewrite my comment. Thank you nonetheless
    – Nordlys Jeger
    Commented Jun 18, 2018 at 18:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .