Routing to different subnet via single NIC to another box

Question

I have a home network with 3 subnets (I like to play around!)

I've been struggling with something that I thought would be easy, but after a few days I'm no closer to the answer. My network is depicted in this image

The main subnet is 192.168.1.0/24, which is connected to the 192.168.2.0/24 subnet via a laptop with an ethernet (192.168.1.2) and wifi (192.168.2.1) adapter.

I am running hostapd and dhcpd on the laptop with the 2 NIC's (with IP Maquearading) - so I am using it as a WiFi hotspot. The setup there is working fine (has been for some time). I recently added a wifi router, which is connected to the 192.168.1.0/24 subnet via a WAN connector ethernet link (192.168.1.10), dishing out DHCP addresses in the 192.168.3.0/24 subnet range.

The main subnet is connected to a Linux box (192.168.1.1) which acts as a gateway router to the internet for the internal network (with IP Masquerading for packets to and from the public internet).

If I am on the Linux box (router) I can ping 192.168.1.2 as well as 192.168.2.2 (after adding the entries in the routing table to reach the 192.168.2.0/24 subnet):

ip route add 192.168.2.0/24 via 192.168.1.2

My goal is to reach the mobile phone (192.168.2.2) from the laptop (192.168.3.2) connected wirelessly to the wifi router, which in turn is connected to the 192.168.1.0/24 subnet.

This is where things go wrong. I thought that the packets originating from 192.168.3.2 - which are destined for 192.168.2.2 - will be sent to 192.168.1.1 (the default gateway for the wireless router), and since 192.168.1.1 can ping 192.168.2.2, I assumed that this would work (because of the routing entry mentioned above).

IP Forwarding is enabled on the Linux router (192.168.1.1) as well as on the laptop acting as a WiFi hotspot. Is what I am trying to do here possible, or am I missing some fundamental concept?

• Routing tables

Routing table for 192.168.1.1:
Destination   Gateway       Genmask     Flags Metric   Ref     Use Iface
0.0.0.0       10.0.0.1     0.0.0.0         UG    10      0        0 eth0
10.0.0.0      0.0.0.0      255.255.255.0   U      0      0        0 eth0
192.168.1.0   0.0.0.0      255.255.255.0   U      0      0        0 eth1
192.168.2.0   192.168.1.25 255.255.255.0   UG     0      0        0 eth1

Routing table for 192.168.1.2:
Destination Gateway       Genmask       Flags Metric Ref  Use Iface
0.0.0.0     192.168.1.1   0.0.0.0       UG     0     0    0   eth0
192.168.1.0     0.0.0.0   255.255.255.0 U      0     0    0   eth0
192.168.2.0     0.0.0.0   255.255.255.0 U      0     0    0   wlan0

Thank you all!

Answer 1

And here I have to admit to a very blind oversight, and answering my own question (at least the part that tripped me over!)

I have a script that start and stop my Linux router settings (setting firewall rules, enable IP forwarding an Masquerading etc), and doing the "reverse" on a stop command. One of the lines in the stop sections was:

iptables -P FORWARD DROP

This sets the FORWARD policy to DROP - effectively killing packet forwarding, and hence was the cause of all my problems! In the end it was as simple as adding the

ip route add 192.168.2.0/24 via 192.168.1.2

route to the routing table on the Linux router. Packets from different subnets are correctly forwarded to 192.168.1.1, from where they are forwarded further if need be, via the 192.168.1.25 GW for subnet 192.168.2.0/24

Thanx to wurtel and user2999479 who'se answers made me dig further into my own setup :)

Answer 2

As you did on the Gateway Linux box, can you add a route on the Wifi Router (What make/model router is that anyway?)?

From experience, I've noticed differences in how different IP stacks handle certain IP services, such as DHCP, Masquerading, & Forwarding. It also might be worth noting the OS and version of TCP/IP on 192.168.1.1 & 192.168.3.2 to assist with further troubleshooting.

Answer 3

The masquerading on 192.168.1.2 is what's causing trouble. The ping packets may reach 192.168.2.2 but the return pongs are being masqueraded, and hence aren't received by 192.168.1.1.

There's no need to do masquerading (NAT) on 192.168.1.2 anyway. 192.168.2.0/24 traffic should be able to reach your whole internal network as-is, provided you have routes set up correctly. When 192.168.2.2 wants to go to the internet, then masquerading performed on 192.168.1.1 should be enough (if configured correctly and routes to 192.168.2.0/24 and 192.168.3.0/24 are set up correctly on 192.168.1.1).

You won't be able to ping 192.168.3.2 either, unless you can tell your wifi router not to perform masquerading.