Forwarding to device behind secondary router

Installing and Using OpenWrt
1

Hi,

My Edge Route Lite crashed, they have a weak point with the usb storage, and of course I did not have any recent back up. So I am reconfiguring it from scratch.

My set up is a openwrt on the ERL, connected to WAN through a FO modem. LAN is set up with ip 192.168.2.1 and network 192.168.2.0/24. On the LAN side, I have a unmanaged switch with a serie of devices and a Google Wifi Router with a static ip 192.168.2.188. The Google Wifi Router LAN is set up with ip 192.168.86.1 and network 192.168.86.0/24. On the 192.168.2.0/24, I have nginx running, and on the 192.168.86.0/24 I have a Home Assistant. On the WAN, I also use cloudflare.

Before the crash, I was able to ping 192.168.86.0/24 addresses from 192.168.2.0/24. Also, I was able to forward ports so I could reach my Home Assistant when connected to a public network.

I have set up port forwarding and a static route pointing in the openwrt, but to no avail.... I have been scratching my head for the last 2 days, and no success... So if anybody can help, it would be greatly appreciated.

Below Network & Firewall configs

cat /etc/config/network:
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'
config globals 'globals'
	option ula_prefix 'fd31:a348:2234::/48'
config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'
	list ports 'eth2'
config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.2.1'
config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
config interface 'wan6'
	option device 'eth1'
	option proto 'dhcpv6'
config device
	option type '8021q'
	option ifname 'eth1'
	option vid '20'
	option name 'eth1.20'
config interface 'Internet'
	option proto 'dhcp'
	option device 'eth1.20'
	option hostname '*'
config device
	option name 'eth0'
config device
	option name 'eth1'
config device
	option name 'eth2'
config route
	option target '192.168.86.0'
	option netmask '255.255.255.0'
	option interface 'lan'
	option gateway '192.168.2.188'

**************************
cat /etc/config/firewall
config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'
	list network 'Internet'
config forwarding
	option src 'lan'
	option dest 'wan'
config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'
config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'
config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'
config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'
config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'
config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'
config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'Cloudflare'
	list proto 'tcp'
	option src 'wan'
	option src_dport '443'
	option dest_port '443'
	option dest_ip '192.168.2.185'
2

A tcpdump would reveal what is going wrong there.

opkg update; opkg install tcpdump; \
tcpdump -i br-lan -c 20 -nv host 192.168.86.X and host 192.168.2.Y

replace X and Y with the correct last octets of the hosts and try to ping.

3

tcpdump will show what is the problem.

I also have a downstream router on its own subnet and I like to be able to connect from upstream to downstream.
I did two things:

  1. On the upstream router set a static route to the wan ip address of the downstream router, in your case (etc/config/network):
config route
	option interface 'lan'
	option target '192.168.86.0/24'
	option gateway '192.168.2.188'
  1. Allow traffic from the upstream router so I added to the firewall of the downstream router (etc/config/firewall):
config rule
	option name 'allow_forward'
	option src 'wan'
	option dest '*'
	option target 'ACCEPT'
	list src_ip '192.168.2.0/24'

config rule
	option name 'allow_input'
	option src 'wan'
	option target 'ACCEPT'
	list src_ip '192.168.2.0/24'

The first rule is to allow traffic to LAN clients (FORWARD rule), the second to allow traffic to the router itself (INPUT rule)

Maybe this helps

4

If you want to be able to reach the network behind this router (I'm assumign the configuration you posted is the secondary one), and it is connected via the wan (or internet) network, you need to disable masquerading.

5

Ok, many thanks, I'll install tcpdump and see if I can detect some incorrect config, and come back here.

6

The second / downstream router is a Google Wifi Router with stock firmware, there are no settings to modify the firewall, but in the past this was working well, but again, I'll run the tcpdump and we'll see.

7

I would not expect the ability to connect to devices downstream of the Google Wifi devices from your upstream network.... the other direction would work without issue, but the Google Wifi isn't going to allow unsolicited traffic. Are you sure you were using the Google Wifi in router mode (as compared to a dumb AP mode)?

And what is the purpose of the 2nd router?

8

Here is the dump, not much I can decipher...

tcpdump -i br-lan -c 20 -nv host 192.168.86.250 and host 192.168.2.219
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:55:57.565258 IP (tos 0x0, ttl 64, id 32537, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 1, length 64
17:55:58.581628 IP (tos 0x0, ttl 64, id 32737, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 2, length 64
17:55:59.605278 IP (tos 0x0, ttl 64, id 32861, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 3, length 64
17:56:00.629121 IP (tos 0x0, ttl 64, id 32884, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 4, length 64
17:56:01.653273 IP (tos 0x0, ttl 64, id 33051, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 5, length 64
17:56:02.677094 IP (tos 0x0, ttl 64, id 33231, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 6, length 64
17:56:03.701379 IP (tos 0x0, ttl 64, id 33383, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 7, length 64
17:56:04.725251 IP (tos 0x0, ttl 64, id 33631, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 8, length 64
17:56:05.749117 IP (tos 0x0, ttl 64, id 33862, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.219 > 192.168.86.250: ICMP echo request, id 45104, seq 9, length 64

My first router does not have any wifi capabilities, and I have quite a big place, so I use a Google Wifi mesh behind this second/downstream/GoogleWifi Router.

9

So it seems to me that you should be using the Google Wifi as a dumb AP, not a router. This will make it transparent and all devices will be on the same subnet.

10

First, many thanks to all.

I just found out Google Wifi cannot operate a mesh network if bridge / AP mode. As I quite appreciate the mesh, I do not plan to change this.

But then it seems from the above tcpdump traces that there is no reply from the 192.168.86.0 network... So I continue to wonder how this was working in the past. Maybe my memory is failing me.

11

Right, that is true. I would have mentioned that, but I didn't know you had a mesh system (as compared to a single unit).

This is completely expected.

Maybe you were accessing the 192.168.2.0/24 network from the 192.168.86.0/24 network -- this direction will work without issue and without special configuration.

12

Thanking you all for the support, and I am closing this issue (until I come up with a better memory or change in my set-up)

13

You could consider installing OpenWrt on your Google Wifi devices.

14

It is expected not to see any reply as the reply will come directly from the Google wifi to the 192.168.2.219 and not through OpenWrt to log it in tcpdump. If you cannot see any reply on 192.168.2.219 then you need to troubleshoot on Google Wifi, if possible, otherwise on the 192.168.86.250 whether it gets the ping and sends a response.

15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.