1

Summary Of The Problem

Here is a routing table on a linux computer:

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

Packets with a destination IP of 1.2.3.5 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.

Architecture

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

Computer:

  • A: a random computer on the internet that wants to connect to computer F.
  • B: has an extra IP (1.2.3.5) I want to route to F through E.
  • C: out of my control.
  • D: my router, it has a static route: 1.2.3.5 ---> 192.168.1.3
  • E: establishes an SSH TUN with B, routes incoming packets destined for 1.2.3.5 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 1.2.4.5

Setup

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

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

/etc/sysctl.conf was modified in E:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

SSH TUN established on E with:

ssh -w 0:0 1.2.3.4

tun0 interface brought up on E with:

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

tun0 interface brought up on B with:

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

I can now successfully ping E from B with:

ping 10.0.0.100

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

route added to B with: ip route add 1.2.3.5/32 via 10.0.0.100 dev tun0

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

Tests

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

netcat -u 1.2.3.5 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 4.3.2.1.44312 > 1.2.3.5.4444: 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 4.3.2.1.44312 > 1.2.3.5.4444: UDP, length 5

The following command was run on E:

root@computer:~# netcat -u 1.2.3.5 4444
test

With the following command simultaneously run on F:

root@computer:~# nc -ul 4444
test

Issue

The problem I am facing is one of the computers (E) is receiving IP packets for a certain IP (1.2.3.5) 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 '16 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 '16 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 '16 at 3:58
  • Hmm. Can you reach 1.2.3.5 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 1.2.3.5/32 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 '16 at 6:12
  • Yes, E can reach F directly by 1.2.3.5. – robfors Oct 23 '16 at 16:50
0

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

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

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.

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.