1

I am trying to create an ssh VPN (through port 443) to bypass NAT and filtering. I am using this tutorial. The OS is Debian testing on both sides.

The tunnel devices are created on both sides, and addresses are assigned.

ssh command (as root on machine B): ssh -w 0:0 MACHINE_A_PUBLIC_IP -p 443

a shell opens for root

On the server (machine A), PermitTunnel is set to yes, and cat /proc/sys/net/ipv4/ip_forward returns 1

machine A:

ip link set tun0 up
ip addr add 10.0.0.100/32 peer 10.0.0.200 dev tun0

machine B:

ip link set tun0 up
ip addr add 10.0.0.200/32 peer 10.0.0.100 dev tun0

result:

machine A:

36: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 10.0.0.100 peer 10.0.0.200/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::9210:8322:2382:e696/64 scope link flags 800 
       valid_lft forever preferred_lft forever

machine B:

32: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 10.0.0.200 peer 10.0.0.100/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::bd70:5f4d:c8f5:aa2c/64 scope link flags 800 
       valid_lft forever preferred_lft forever

Why can I not send pings?

Am I missing an obvious troubleshooting step?

Could it somehow be the filter that I am behind?

edit:

on machine A (server) ip route:

default via 192.168.1.1 dev eth1 proto static metric 100 
10.0.0.200 dev tun0 proto kernel scope link src 10.0.0.100 
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.126 metric 100 
192.168.100.0/24 dev virbr1 proto kernel scope link src 192.168.100.1 linkdown 
192.168.105.0/24 dev virbr4 proto kernel scope link src 192.168.105.1 linkdown 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 
239.0.0.0/8 dev lo scope link 

on machine B (client) ip route:

default via 192.168.1.1 dev wlp3s0 proto static metric 600 
10.0.0.100 dev tun0 proto kernel scope link src 10.0.0.200 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.136 metric 600

on machine B (client) ping 10.0.0.100:

PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
^C
--- 10.0.0.100 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9000ms

the output of ping is the same on the server they can each ping their own interfaces (machine B can ping 10.0.0.200), (machine A can ping 10.0.0.100)

bumped to the homepage by Community 7 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • 1
    Please post results of ip route and your attempted ping command. – TNW Nov 9 '16 at 0:19
  • Sorry about that, the post has been edited. – user254095 Nov 9 '16 at 0:32
  • No worries. This is a bit strange, to say the least - I've been able to create a working tunnel without any problem, following those instructions. Maybe you could try running tcpdump -i tun0 on another root terminal on both sides, while running ping? Then you could maybe see something interesting that you can share. – TNW Nov 9 '16 at 0:47
  • Ahhh, this is interesting. tcpdump -i tun0 is showing the IMCP request as going to 10-0-0-100-static.midco.net (midco is my isp) So the traffic must be going through the tunnel then to the internet? "Passing" the 10.0.0.100 machine? – user254095 Nov 9 '16 at 0:57
  • I think that 10-0-0-100-static.midco.net is an artifact of reverse DNS resolution and not useful - you can add -n flag to tcpdump to see plain IPs. The real question is whether packets go from A to B and can't find the way back for some reason, or they don't even reach B at all; to know that you need to run tcpdump on both sides. Also, try to ping the other way round. EDIT: output from iptables -L on both sides can also shed some light on this issue – TNW Nov 9 '16 at 1:06
0

In client ssh_config:

Tunnel point-to-point

In server sshd_config:

PermitTunnel point-to-point

Then establish the connection with one line on the client:

ssh \
  -o PermitLocalCommand=yes \
  -o LocalCommand="sudo ifconfig tun5 192.168.42.2 pointopoint 192.168.42.1 netmask 255.255.255.0" \
  -o ServerAliveInterval=60 \
  -w 5:5 root@192.168.1.109 \
  'sudo ifconfig tun5 192.168.42.1 pointopoint 192.168.42.2 netmask 255.255.255.0; echo tun5 ready'

You can terminate with ctr-c.

  • Sorry, I am unable to ping 192.168.42.1 from 192.168.42.2. – user254095 Nov 9 '16 at 2:17
  • then try another protocol, e.g. telnet 192.168.42.1 443 – Ipor Sircer Nov 9 '16 at 2:21
  • Nope, I also tried netcat and I tried scanning with nmap (192.168.1.42 has services running on it.). – user254095 Nov 9 '16 at 2:34
  • 1
    yep, I downgraded my kernel to 3.16.0-4 and it worked right away, re upgrading to 4.7.0-1 made the problem occur again. – user254095 Nov 9 '16 at 3:34
  • 1
    I recommend to fill a bugreport for debian kernel developers. They might know why this occurs. – Ipor Sircer Nov 9 '16 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.