1

I am having trouble routing traffic between 2 subnets. With my current setup I can ping hosts on both subnets from my Rasbperry Pi but can't ping hosts from one subnet to another (timeout).

Basically, I would like hosts from one subnet to have access to hosts on the other subnet. My plan was to configure my Raspberry Pi to handle nearly all routing between subnets, since each subnet is behind its own basic household router which does not support static routing. I would then add a route on each host to the opposite subnet via its RPi 'gateway' interface.

Here is my current setup:

LAN A <---> Router A <---> RPi <---> Router B <---> LAN B

LAN A
Network: 192.168.0.0/24
Gateway: 192.168.0.1

LAN B
Network: 192.168.1.0/24
Gateway: 192.168.1.1

RPi
OS: Raspbian
eth0: 192.168.0.4
eth1: 192.168.1.4

RPi interface config:

# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.0.4
    netmask 255.255.255.0
    broadcast 192.168.0.255
    gateway 192.168.0.1

# The USB-Ethernet interface 1
allow-hotplug eth1
iface eth1 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    broadcast 192.168.1.255
    gateway 192.168.1.1

RPi routes:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     192.168.0.1     255.255.255.0   UG    0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     192.168.1.1     255.255.255.0   UG    0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1

RPi firewall rules:

# iptables -t nat -n -L -v
Chain PREROUTING (policy ACCEPT 2711 packets, 147K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 33 packets, 5204 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 97 packets, 7344 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 97 packets, 7344 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      eth0    192.168.0.0/24       192.168.1.0/24
    0     0 MASQUERADE  all  --  *      eth1    192.168.1.0/24       192.168.0.0/24

Host 192.168.0.3 (WIN 10) route:

>route PRINT
===========================================================================
Interface List
...
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3    281
...
      192.168.1.0    255.255.255.0      192.168.0.4      192.168.0.3     26
...
===========================================================================
...

Currently, this is what happens when I ping the opposite subnet's gateway from host 192.168.0.3:

>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss).

Looking at my setup, you could probably say I have taken the shotgun approach, but sadly it hasn't worked out. Could I please find out what else I might need to configure, or where I have gone wrong? Let me know if I need to provide any more information.

Many thanks in advance. :)

  • 1
    Why are you masquerading? You just want to connect two different subnets. ip_forward is enabled? – dirkt Jul 16 '17 at 10:32
  • 1
    Assuming everything on LANB has routes for LANA, then just remove all the iptables stuff, and turn on forwarding sysctl -w net.ipv4.ip_forward = 1. You can save this setting in /etc/sysctl,conf. The pi won't route without it, – Paul Jul 16 '17 at 11:33
  • Please don't take offense, but I think you need to learn about routing before you try fix this. There are multiple problems with your setup - possibly including cabling / labelling issues. You should not be using NAT of course, but your routers are not set up to route correctly (wan interfaces on lan IPs) and your RPI is not correctly used as a default gw. You almost certainly have redundant hardware and a needlessly complex setup - what are you trying to do? (A switch or 2 could replace routers or the pi, making life way simpler). – davidgo Jul 16 '17 at 20:17
  • Also, what type of routers? – davidgo Jul 16 '17 at 20:17
2

The full context of the setup is that we have 2 apartments with their own Internet connection and LAN which we have joined together using a RPi via jumper cabling in the garage. The whole point of this exercise was so that I can administer the upstairs apartment's NAS without having the network traffic leave the building (which would also make sharing data a LOT faster), and also retain each apt's Internet/network setup so that they may continue working in case the RPi goes down. Since the commodity routers in each apartment are so lacking in options and features, I was willing to compromise by manually adding routes to the hosts that I would do the administration from on my subnet.

It's true that I need to get a better understanding of networking, and I am continually in the process of doing so as an IT professional. I spoke with a colleague today about my issue and it turns out I didn't need to add any routes, I just needed to change the firewall rules to use SNAT instead of MASQUERADE and the subnets started talking to each other (I did also need to allow IPv4 forwarding as Paul suggested, thanks!):

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.4
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.1.0/24 -o eth1 -j SNAT --to-source 192.168.1.4

Full iptables list:

# iptables -t nat -n -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       all  --  *      eth0    192.168.1.0/24       192.168.0.0/24       to:192.168.0.4
    0     0 SNAT       all  --  *      eth1    192.168.0.0/24       192.168.1.0/24       to:192.168.1.4

As you can see, now the traffic is staying inside the building when testing from host 192.168.0.3:

>tracert 192.168.1.1

Tracing route to 192.168.1.1 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  192.168.0.4
  2     1 ms     1 ms     1 ms  192.168.1.1

Trace complete.

Many thanks for your comments.

  • I had a somewhat different configuration, but the same problem that nodes on one subnet couldn't ping nodes on another subnet with a dual homed RPi in between them. The iptables command with SNAT was the answer. But I still don't understand why. Is iptables based firewall always preventing subnet to subnet access, even with routes seemingly correctly configured? – CyberFonic Jan 26 at 13:16

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.