No internet from secondary router behind OpenWrt router

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello,
I have a setup with 3 routers; the visualization would look like this:
clients ↔ OPNsense router (no NAT) ↔routing rules ↔OpenWrt router (no NAT) ↔ routing rules ↔ ISP router with NAT ↔ Internet

The issue is that I have no internet access from secondary router (OPNsense) and any clients connected to it.

The following IPs are assigned:
primary router (OpenWrt):
LAN: 172.16.1.1/24
DMZ: 172.16.11.1/24
eth1: 172.16.0.1/30
WAN: 192.168.1.2/24
secondary router (OPNsense):
LAN: 172.16.1.2/24
Office: 172.21.10.1/24 (VLAN)
Guest: 172.21.20.1/24 (VLAN)
WAN: 172.16.0.2/30

Interface eth1 is not assigned to any firewall zone, it's a blank NIC.

And this is the routing table of primary router:

root@eddie:~# ip route
default via 192.168.1.1 dev wan src 192.168.1.2
172.16.0.0/30 dev lan5 scope link src 172.16.0.1
172.16.1.0/24 dev lan2 scope link src 172.16.1.1
172.16.11.0/24 dev lan4 scope link src 172.16.11.1
172.21.0.0/16 via 172.16.0.2 dev lan5 onlink
192.168.1.0/24 dev wan scope link src 192.168.1.2

My understanding is that there's no route from secondary router to internet.
Any communication between primary and secondary router is via subnet 172.16.0.0/30.

Can you please advise what is missing to route internet traffic from secondary router to ISP router via primary router?

THX

2

if they're connected LAN<>WAN, you can't use the same LAN subnet on both devices.

2 Likes
3

You could enable masquerade on the wan interface of OPNsense, which I understand is the upstream interface to eth1 in OpenWrt.
Otherwise you'd need to use unique subnets among the router interfaces, as @frollic suggested.

1 Like
4

I got really confused. Let's rebuild this from scratch with a more systematic plan.

There are 3 networks and 3 routers. Each network's router is .1 in its network. The next downstream router is .2
Network 3 (Users) on lan of router 3: 172.16.3.0/24
wan of router 3: 172.16.2.2
Network 2 (middle router) lan of router 2: 172.16.2.0/24
wan of router 2: 172.16.1.2
Network 1 (ISP router) lan of router 1: 172.16.1.0/24
wan of router 1: Internet

Routing rules define a network and the next hop to reach it.
Router 3 doesn't need any additional rules other than those established by default for its own networks. The default gateway is router 2, which then knows how to reach router 1, which then NATs to the Internet. The problem is when router 1 has to dispatch a return packet to router 2 or router 3's LAN.
Router 2 needs to know about router 3's LAN: 172.16.3.0/24 via 172.16.2.2
Router 1 is going to send packets for users of router 3 (.3.0 addresses) to router 2, which will then use its rule (above) to send them to router 3.
172.16.3.0/24 via 172.16.1.2
Additionally you probably want a route to router 2's lan in router 1, so that router 3 itself and anything else on the .2 lan can use the Internet.
172.16.2.0/24 via 172.16.1.2
These two rules could be combined into one by carefully choosing the IP ranges and expanding the netmask.

5

As documented in my visualization above
clients ↔ OPNsense router (no NAT) ↔routing rules ↔OpenWrt router (no NAT) ↔ routing rules ↔ ISP router with NAT ↔ Internet
masquerading is not an option (no NAT).

Let me add information of IPs and routes on the relevant router.

ISP router:
WAN: <public IPv4>
LAN: 192.168.1.1/24
Static route: 
  interface: LAN
  network: 172.16.0.0
  netmask: 255.240.0.0
  gateway: 192.168.1.2

(CIDR 172.16.0.0/12 has first IP 172.16.0.1 and last IP 172.31.255.254)

Primary router:
WAN: 192.168.1.2
LAN: 172.16.1.1/24
DMZ: 172.16.11.1/24
homelab: 172.16.0.1/30
Static route 1: 
  interface: LAN
  network: 172.16.11.0
  netmask: 255.255.255.0
  gateway: 172.16.1.1
Static route 2: 
  interface: homelab
  network: 172.21.0.0
  netmask: 255.255.0.0
  gateway: 172.16.0.1
Default route:
  interface: wan
  network: 192.168.1.0
  netmask: 255.255.255.0
  gateway: 192.168.1.2

Secondary router:
WAN: 172.16.0.2
LAN: 172.16.1.2/24
Office: 172.21.10.1/24
Default route:
  interface: wan
  network: 172.16.0.0
  netmask: 255.255.255.252
  gateway: 172.16.0.1

To simplify the issue resolution let's drop the secondary router for a moment.
This means I connect another client to interface homelab.

There's no DHCP service running for interface homelab, and this means no IP will be assigned.
Instead, the client's routing table is this:

default dev eth0 scope link src 169.254.127.45 metric 202
169.254.0.0/16 dev eth0 scope link src 169.254.127.45 metric 202

To assign a static IPv4 on eth0 I execute this command:
ip addr add 172.16.0.2/30 dev eth0
And finally to define a (new) default route I execute this command:
ip route add default via 172.16.0.1

This results in client's new routing table:

default via 172.16.0.1 dev eth0
default dev eth0 scope link src 169.254.127.45 metric 202
169.254.0.0/16 dev eth0 scope link src 169.254.127.45 metric 202
172.16.0.0/30 dev eth0 proto kernel scope link src 172.16.0.2

I don't think this NIC configuration is correct because I cannot access internet.
And I don't understand why IP 169.254.x.x is still shown in client's routing table.

My strategy is: once the client has internet access, I can continue with secondary router setup.

6

This is wrong and pointless. Network is directly connected in DMZ.

This is not default route, also wrong and pointless, as it is directly connected.

Network conflict with the LAN in primary router.

169.254 should not be there at all and it is link local, that means it cannot have a gateway to reach other networks.
Fix the things we have remarked already three times first and it will work. It's not something exotic.

2 Likes
7

Well, let's do it... step-by-step.

I have removed static route 1.
Communication LAN <-> DMZ is working as expected.

Primary router's default route is created automatically, means I didn't modify it.
WAN interface is a DHCP client and connected to ISP router downstream network (LAN) 192.168.1.1/24, therefore I don't understand why this should be wrong.

As of now, the secondary router is disconnected.
And I have modified primary router's interface homelab, means I modified subnet to 172.16.0.1/24 and enabled DHCP.
Now, interface homelab can be compared with interface DMZ.

If I connect a client to interface DMZ, command traceroute openwrt.org is working as expected:

pi@raspberrypi:~ $ traceroute openwrt.org
traceroute to openwrt.org (139.59.209.225), 30 hops max, 60 byte packets
 1  eddie.local.biszumbitterenen.de (172.16.11.1)  0.641 ms  0.571 ms  0.495 ms
 2  192.168.1.1 (192.168.1.1)  1.116 ms  1.020 ms  0.888 ms
 3  * * *
 4  ip-081-210-148-070.um21.pools.vodafone-ip.de (81.210.148.70)  25.090 ms  25.024 ms  24.842 ms
 5  de-str01c-rc1-ae-21-0.aorta.net (84.116.190.241)  28.690 ms  28.513 ms  28.441 ms
 6  de-fra01b-rc2-ae-4-0.aorta.net (84.116.140.201)  29.372 ms  25.143 ms  25.033 ms
 7  de-bfe18a-rt01-lag-1.aorta.net (84.116.190.34)  23.848 ms  23.767 ms  24.482 ms

When I connect the same client to interface homelab, command traceroute fails:

pi@raspberrypi:~ $ traceroute openwrt.org
traceroute to openwrt.org (139.59.209.225), 30 hops max, 60 byte packets
 1  eddie.local.biszumbitterenen.de (172.16.0.1)  0.342 ms  0.288 ms  0.217 ms
 2  eddie.local.biszumbitterenen.de (172.16.0.1)  0.235 ms  0.178 ms  0.199 ms

The major difference comparing interface homelab and DMZ is:
there's no firewall zone assigned to interface homelab.
This means homelab is a "blank" interface.

In my opinion interface homelab is not using default route and traffic is not routed to WAN.
Maybe this is related to a forwarding issue?

Until this traceroute issue is not solved I don't need to continue with secondary router.

8

After creating firewall zone homelab with these settings the issue is solved:

config zone
	option name 'homelab'
	option forward 'REJECT'
	list network 'homelab'
	option input 'ACCEPT'
	option output 'ACCEPT'

config forwarding
	option src 'homelab'
	option dest 'wan'

However, I'm not sure if I should be more restrictive with input and output settings.

9

By default if there is no forwarding configured, traffic is denied.
input policy matches the incoming packets. If you change it to drop or reject you'll need rules to allow the flows to access the router. output policy matches the egress packets. It is generally fine to leave it to accept.