I have connected an OpenWrt router (call it Router 2) to a LAN port of another OpenWrt router (call it Router 1) that is connected to the Internet. Router 2 is used for IoT devices, and the setup works very well. By default, no device connected to Router 1 can see a device on Router 2 and vice-versa. Also, all devices on Router 2 have access to the Internet and to each other. Just what is needed. Now, I may have a need to allow adevice on Router 2 to be seen and accessed by devices on Router 1. Would like only this device to be seen and accessed. Can this be done? If so, how?
There are two ways to approach this, depending on the upstream router's capabilities:
- If the upstream router supports static routes, you will create a static route on that device that points to the downstream router's lan. From there, you'll turn off masquerading on the OpenWrt router's wan zone and then allow forwarding from wan > lan on the OpenWrt router (either in full, or a more granular allowance).
- If the upstream router doesn't support static routes, you'll treat this just like any other port forwarding operation and you'll reach the device in question by using the address that the OpenWrt router uses on the upstream lan (OpenWrt's wan address).
If you can replace the upstream router, you could make the OpenWrt router the main device and easily setup VLANs for this purpose.
Also, be aware that the devices connected to the OpenWrt router can theoretically reach all of the devices on the upstream lan unless you have created a firewall rule to block them. I mention this because the common intent of an IoT network is to prevent those devices from being able to reach the devices on the trusted lan. In the absence of an additional firewall rule, the IoT devices can reach the trusted devices.
1 Like
Peter,
Thank you for the quick response.
All of the routers in this scenario run OpenWrt. So, I suspect static routes are supported. Is turning off masquerading on the downstream router a weakness? How would a more granular allowance be implemented?
The downstream (IoT) router's DHCP issues addresses in a different subnet from the upstream router. When I connect a PC to the downstream router, it cannot get to any device on the upstream router - printers, servers, etc. Is that sufficient to show that there is no theoretical reach?
I used subnets to avoid the complication of setting up VLANs, and I have a separate IoT router to isolate all the IoT traffic from the main network. Good idea? Bad idea?
Gary
In that case, have you considered doing all of your routing on the main router. In other words, the main router handles the main lan + iot network (and others, if you want). This is typically described as multiple VLANs. It is much more efficient in terms of the overall network topology management since only one device is needed to control all the routing and firewall functiins.
Yes, static routes are supported, so you can implement the first option I had proposed, but I'd recommend that you consider doing all of the routing on the main router instead.
No. In fact, masquerading is kind of a clever hack (really useful, common, and used everywhere). Working without masquerading, when possible (such as your scenario) is better, though, as it avoids double-NAT and makes it possible to have symmetric routing.
This depends on your goals, but in the basic sense, you can allow all traffic from the trusted lan to reach the IoT network, or just from certain machines, or only to specific devices, or even restricted by the specific protocols and/or ports in use. It can be as broad or as granular as you need (as you get more granular, you do need to have more specific information about what is required to ensure the communications you desire work properly).
In theory, but I'd need to see the config to be able to know for sure. It very much depends on the config, but also the method by which you are trying to access those upstream systems.
So you'll use multiple subnets either way, it's just a matter of if that is all happening on a single router or on two or more devices. The way you have it is fine insofar as it is functional and can achieve your goals, but the more elegant solution is a using a single router for this purpose.
You make some good points about VLANs, and I will give that more consideration. I have a lot of IoT devices (at least 30) and I prefer keeping that traffic physically isolated from the main router as much as practicable. Knowing myself, I will add more (to my wife's chagrin). It is also something that I understand well. I am intrigued to learn more about VLANs. Just right now.
I was wondering how to avoid double-NATing in this scenario. That is done by turning off masquerading? On other routers I have owned, I had to enable their DMZ function.
What would the static route settings be to allow upstream router devices to access one, and only one, downstream router device? Can this be setup through Luci?
Gary
Properly configured, the effect is the same (or even better) when using VLANs vs multiple routers to achieve isolation.
Yes. Along with the static route added to the upstream router.
No, that's not the same thing at all. "DMZ" is really just a port forward scheme where you forward all ports to a specific host. The rover is still masquerading the upstream connection and it DMZ allows only a single host to be reached in this way; it doesn't allow symmetric routing between the two networks.
Disabling masquerading is how you remove double NAT and you get symmetric routing (still subject to the firewall, though, so you can make it as open or as restrictive as you like).
Static routes on the upstream router allow that router to understand how to reach the network behind the second router. It does not directly control access, though.
The access is controlled by means of the firewall on the 2nd router. The rules can be as broad or as granular as you want, allowing just one host, some, or all hosts to be reachable from one, some, or all hosts on the other network.
And yes, this can be done in LuCI.
Peter,
I think I follow all you have said. Perhaps I will move to VLANs eventually. Just not today.
To be sure of my understanding, this is what I think needs to be done
- On the downstream router, create a Firewall rule to allow incoming WAN traffic to be delivered to the specific IP address within the downstream LAN. I assume outbound WAN traffic is already allowed given each device can reach the Internet. All hosts on the upstream router should be able to access this device.
One question: Does the "Reject" for the WAN zone's incoming traffic override the Traffic rule being created here?
- Create a static route on the upstream router for the single IP address to be accessed. It would be a static IPV4 route for the lan interface with the target being the downstream host's IP address as xxx.xxx.xxx.xxx/32.
One question: Should the Gateway field be filled with the IP address of the downstream router or left blank?
How did I do?
Gary
Yes.
Yes, that is the lan > wan forward rule.
No.
No, it needs to be for the full OpenWrt lan network. That's because the masquerade rule will be disabled on OpenWrt's wan interface, and traffic will not flow back to the lan properly if the upstream router doesn't have the full network in the static route. It will likely be /24.
That said, the firewall on the OpenWrt router will only allow the ingress traffic that is either destined for the single host you allow to be reachable or return traffic from outbound requests made by hosts on the OpenWrt lan.
The static route will exist on the upstream router. The gateway field is mandatory -- it tells the router where to send the traffic destined for the OpenWrt lan.
Thanks Peter. Hopefully, my last question. For the "Route type" when creating the static route on the upstream router. . . . . . What should chosen?
Gary
Unicast.
If it doesn't work, please show your config and we'll figure out what's happening.
Peter,
I think everything is working now. For the static route on the upstream router, I had entered 192.168.xx.0/24, and after reading the thread again, that seemed incorrect. I changed that address to the IP address of the device with 192.168.xx.xx/214. Now I can reach the device from an upstream host. I still have something to figure out regarding an app that needs to use the downstream device, but I don't think that is a networking issue.
Thank you for the help! I definitely learned something new.
Gary
The first one should have been correct, but with the xx's there, I don't really know what you entered (no need to redact these -- they are not sensitive information). The second option you provided may not work properly.
If you'd like me to review the configs, I can do that... I just need the following from each router:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
Peter,
Everything is working great with the static route in the upstream router and the firewall rule in the downstream router. I need to add a firewall rule to the downstream router to restrict access from the downstream router to other devices on the upstream router, but that will happen over the weekend.
Gary
great!
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.