3

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?

Improve this question
6
  • 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 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, 2016 at 6:12
  • Yes, E can reach F directly by 1.2.3.5.
    – robfors
    Oct 23, 2016 at 16:50

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

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