2

I'm setting up a host that has two routes to the public internet: one via my run-of-the-mill home gateway router, the other via a gateway router on a semi-private network (AMPRNet on 44.0.0.0/8). Most of this is straightforward, but there's one tricky bit:

Mostly the 44.x.x.1 IP is used for communicating with other hosts on 44.0.0.0/8. This is easy to route outgoing packets onto the tunnel interface (tunl0) configured for the purpose.

Hosts on the public web can also reach my semi-private IP (44.x.x.1) via a gateway router at UCSD (169.228.66.251) that announces 44.0.0.0/8 on BGP. Replies to such packets from my node, though, wind up going out eth0 back to the originating host, which doesn't work because they get NATed along the way by my gateway router.

What I think I need to do is use iptables to SNAT incoming packets on tunl0 from non-44.0.0.0/8 hosts to a dummy IP in the 44.0.0.0/8 space, and DNAT them on the way back out using stateful connection tracking. This, however, doesn't seem to be working.

After running

iptables -t nat -A INPUT -s 44.0.0.0/32 -d 44.x.x.1 -j ACCEPT
iptables -t nat -A INPUT -s 0.0.0.0 -d 44.x.x.1 -j SNAT --to 44.0.0.2

when I ping 44.x.x.1 from a remote host, tcpdump on the tunl0 interface shows packets from the actual external IP, not from 44.0.0.2. And if I tcpdump eth0, I see the reply packets going back out to that external IP.

Is this configuration possible? If so, what am I missing?

How to send packets coming from a second router on a particular port back to the router, using iptables not a route seems to be related.

EDIT: adding some more network details

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:3b:93:ba  
          inet addr:192.168.3.192  Bcast:192.168.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14477 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6131 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4475095 (4.2 MiB)  TX bytes:1651639 (1.5 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:44.x.x.1  Mask:255.255.255.255
          UP RUNNING NOARP MULTICAST  MTU:1480  Metric:1
          RX packets:424 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:176191 (172.0 KiB)  TX bytes:836 (836.0 B)

pi@raspberrypi ~ $ sudo ip route
default via 192.168.3.1 dev eth0 
192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.192 

pi@raspberrypi ~ $ sudo ip rule
0:  from all lookup local 
44: from all to 44.0.0.0/8 lookup 44 
45: from 44.x.x.0/28 lookup 44 
32766:  from all lookup main 
32767:  from all lookup default 

pi@raspberrypi ~ $ sudo ip route show table 44 | head
44.0.0.1 via 169.228.66.251 dev tunl0 onlink  window 840
44.2.2.0/24 via 157.130.198.190 dev tunl0 onlink  window 840
44.2.10.0/29 via 71.130.72.52 dev tunl0 onlink  window 840
44.2.14.0/29 via 50.79.156.221 dev tunl0 onlink  window 840
44.2.50.0/29 via 68.189.35.197 dev tunl0 onlink  window 840
44.4.2.152/29 via 173.167.109.217 dev tunl0 onlink  window 840
44.4.10.40 via 69.12.138.16 dev tunl0 onlink  window 840
44.4.22.198 via 67.161.9.80 dev tunl0 onlink  window 840
44.4.22.200 via 50.136.207.176 dev tunl0 onlink  window 840
44.4.28.50 via 50.79.209.150 dev tunl0 onlink  window 840
...
1

Welp, it looks like the answer was pretty simple, after all:

ip route add default dev tunl0 via 169.228.66.251 onlink table 44

Packets come in on a particular interface, so the replies will go back out on that same interface. tunl0 is routing via table 44, so with a default route in table 44, we're good to go.

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.