Summary Of The Problem

Here is a routing table on a linux computer:

root@computer:~# ip route show
default via dev eth0 dev tun0  proto kernel  scope link  src

Packets with a destination IP of sent to tun0 on this computer are not being sent out of eth0.

Long Description Of What I Am Trying To Build

The goal of this project is it give one of my computers (and more of them at a later time) a public IP address. There are two requirements:

  • This computer is behind a NAT that I do not control.
  • I don't want other computers on my LAN to need to go over the (relatively) slow internet to accesses it.


This is the architecture I am working with: enter image description here


  • A: a random computer on the internet that wants to connect to computer F.
  • B: has an extra IP ( I want to route to F through E.
  • C: out of my control.
  • D: my router, it has a static route: --->
  • E: establishes an SSH TUN with B, routes incoming packets destined for to its default gateway D.
  • F: a server that I want all other computers (both on my LAN for on the internet) to access by


IP forwarding was setup on B, E, F with:

echo 1 > /proc/sys/net/ipv4/ip_forward

/etc/sysctl.conf was modified in E:


SSH TUN established on E with:

ssh -w 0:0

tun0 interface brought up on E with:

ip link set tun0 up
ip addr add peer dev tun0

tun0 interface brought up on B with:

ip link set tun0 up
ip addr add peer dev tun0

I can now successfully ping E from B with:


IP removed from interface on B with: ifconfig venet0:1

route added to B with: ip route add via dev tun0

IP added to interface on F with: ip addr add dev eth0


The following command was run on A to test sending packets:

netcat -u 4444

The following commands were run on E to see if packets were being received:

root@computer:~$ tcpdump -n -i tun0 port 4444
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:48:21.034003 IP > UDP, length 5

root@computer:~$ tcpdump -n -i eth0 port 4444
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:48:21.034061 IP > UDP, length 5

The following command was run on E:

root@computer:~# netcat -u 4444

With the following command simultaneously run on F:

root@computer:~# nc -ul 4444


The problem I am facing is one of the computers (E) is receiving IP packets for a certain IP ( but not forwarding them to its default gateway.

I believe what I am missing is a command on E that will route incoming packets on the tun0 interface to its default gateway on the eth0 interface.

Does anyone know what command I may be missing?

  • Could be that E is rejecting the packets coming in on tun0 with source addresses that don't route back out tun0? Make sure that the value of /proc/sys/net/ipv4/conf/tun0/rp_filter is 0. Otherwise, some more tcpdump results could be helpful: When you try to send packets from A to F (all the way) (1) does E receive them (tcpdump -n -i tun0 port 4444)? (2) does E sent them out again (tcpdump -n -i eth0 port 4444)?
    – Celada
    Oct 21, 2016 at 21:12
  • Also: do not use ssh to build an IP-level tunnel You'll run into the TCP-in-TCP tunnel problem. Use OpenVPN or something like that instead.
    – Celada
    Oct 21, 2016 at 21:13
  • I set up OpenVPN between E and B. That part seems to be working well. Unfortunately my setup continues to have the same issue as before. I found rp_filter was indeed 1 and set it to 0. I posted some tcpdump results. Thanks for the advice.
    – robfors
    Oct 23, 2016 at 3:58
  • Hmm. Can you reach directly from E? I think I didn't see that in your tests. That would at least prove E follows its default route correctly and the static route on D (which you didn't list in the "Setup" section but you mentioned earlier that it was there) are working.
    – Celada
    Oct 23, 2016 at 6:12
  • Yes, E can reach F directly by
    – robfors
    Oct 23, 2016 at 16:50

1 Answer 1


The routing problem was solved by Celada's advise to disable Reverse Path Filtering by modifying the file /etc/sysctl.conf


Though I now realize that in order to compete this setup I will also need route returning packets back through E and B to avoid upstream reverse path filtering by my ISP.

You must log in to answer this question.

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