The purple part is already set up and working. What I am trying to do here is to set up the openWRT device to create sort of isolated network within a network. Just for a few devices, mainly for my work and developing. I want to isolate it to secure rest of the network. The devices under the openWRT should be able to only access internet, ideally block the access to the router admin page for them, I want to make sure that the devices can't do anything malicious to my home network and devices in it.
Is it possible to only allow SSH into the devices in the isolated network from my home network and allow openWRT admin page access from the home network, not in the isolated? To harden it as much as possible??
Maybe I am trying to do something that is not possible. Please, I am asking for help with the configuration, is it possible to do it only via the LuCI interface ?
I don't know what I am doing wrong here. Does this work even when the 192.168.1.1 is the default gateway? Because if I block the 1.x subnet I lose internet connection on the isolated network.
Secondly, before I give any advice, I want to clarify that I understand your requirements:
OpenWrt router is for isloated devices and will be on 192.168.7.x (192.168.7.0/24)
You want to deny access to the OpenWrt router's ssh and http to the devices that are connected to it (so no 192.168.7.x device can connect by ssh or by http to the router)
You want to allow access to the OpenWrt router's ssh and http only to devices that are on the proprietary router at 192.168.1.0/24?
EDIT:
Also please clarify how the OpenWrt router is to be connected to the proprietary router? Is it by physical ethernet, or by WiFi?
One possible approach to controlling access to OpenWRT itself...
Listen for SSH from WAN side (i.e., 192.168.1.x). Assume that "hardened" means "no passwords allowed, only private keys" - be aware that setting the password options to "off" will prevent any SSH login if no keys are configured.
Prevent clients in 192.168.7.0/24 from connecting to the SSH and HTTP(S) ports.
Allow clients in 192.168.1.0/24 to connect to SSH and HTTP(S) ports.
/etc/config/firewall:
config rule
option name 'Deny SSH from LAN'
list proto 'tcp'
option src 'lan'
option dest_port '22'
option target 'REJECT'
config rule
option name 'Deny HTTP from LAN'
list proto 'tcp'
option src 'lan'
option dest_port '80'
option target 'REJECT'
config rule
option name 'Deny HTTPS from LAN'
list proto 'tcp'
option src 'lan'
option dest_port '443'
option target 'REJECT'
config rule
option name 'Allow SSH from WAN - 192.168.1.0/24'
list proto 'tcp'
option src 'wan'
list src_ip '192.168.1.0/24'
option dest_port '22'
option target 'ACCEPT'
config rule
option name 'Allow HTTP from WAN - 192.168.1.0/24'
list proto 'tcp'
option src 'wan'
list src_ip '192.168.1.0/24'
option dest_port '80'
option target 'ACCEPT'
config rule
option name 'Allow HTTPS from WAN - 192.168.1.0/24'
list proto 'tcp'
option src 'wan'
list src_ip '192.168.1.0/24'
option dest_port '443'
option target 'ACCEPT'
You pretty much nailed all the points, however I don't plan on using ssh to connect to the router, but to the devices connected to it. Let's say I have a Raspberry Pi with some software I don't trust, so I hook it up to the isolated network. The Pi won't have a way to get into my home network, where my laptop, TV, phones and everything communicate and snoop on my traffic like that, but would be able to access the internet. The ssh part would be just for accessing the Pi from my home subnet, so I have a way of managing it.
The router is connected via Ethernet cable. From proprietary router's LAN port to openwrt's WAN port.
This'll allow connections from 192.168.7.0/24 to 192.168.1.0/24, but will not allow the reverse.
config rule
option name 'Deny Untrusted to Trusted'
list proto 'all'
option src 'lan'
option dest 'wan'
list dest_ip '192.168.7.0/24'
option target 'REJECT'
config rule
option name 'Allow Trusted to Untrusted'
list proto 'all'
option src 'wan'
list src_ip '192.168.7.0/24'
option dest 'lan'
list dest_ip '192.168.1.0/24'
option target 'ACCEPT'
You can tailor those subnet ranges to be individual IP addresses. Similarly, you can also tailor the rules for individual port numbers or port ranges. But those should serve as examples to help you get the sort of access policy you want.
It is. I set up the rules in LuCI before copying the resulting contents of /etc/config/firewall.
As long as you're clear about what you want to permit and deny, and from where to where, then you can achieve your results in either LuCI or on the command line.
That worked like a charm. Now I have to somehow add the openwrt router dashboard to it, too. But I am still wondering, how can I ssh into a subnet. Do I have to set up a route? Because I can't just run ssh 192.168.7.27 when I am on device in 192.168.1.x. Even ping does not get to it.
You can't. You can SSH to a specific address in that subnet, but you can't spam the entire subnet with SSH broadcasts.
(Well, you might be able to, but I wouldn't want to guarantee the results...)
It's possible that my rules might have been incomplete, or even just flat-out wrong. I figured you'd want everything in 192.168.1.0/24 to be able to talk to 192.168.7.0/24, on any port/protocol, but not the reverse. But I could have made a mistake. It's possible you might have to do some more firewall tinkering.
On that note, is your Raspberry Pi running any sort of packet filter itself? Is it possible that the traffic is reaching the Pi and the Pi is dropping it?
The first set of rules I posted should permit access to OpenWRT from 192.168.1.0/24 but deny access to OpenWRT from 192.168.7.0/24... if I didn't make a mistake.
Yes that is what I meant. Sorry, I badly explained myself.
That is correct I needed exactly that and it is working now. I can't get to my home subnet from the isolated one. However I can still access openwrt dashboard on 192.168.7.1 and for some reason on 192.168.1.181 too. But that is the only address in that range I can access.
Maybe I have some firewall rules overlayed which may cause this. I restored the firewall to defaults and then added the two rules. There are quite a few default rules that openwrt comes with.
For now I am testing it with just pinging my Fedora Linux laptop, but as far as I know it does not come with a firewall or anything like that.
The dropbear and http/https servers are listening on all interfaces; therefore, they will technically respond to a connection request to any of the addresses held by the router (don't worry... see point 2)
The firewall is configured to allow input from the zone/subnet/host in questoin. Point 1 seems scary at first because the router is even listening on the wan... but, this why the wan zone in the firewall has input = reject by default. The firewall will prevent access if the zone/network/host is not allowed input to the router.
When the addresses in questoin are on the router itself, they're technially not subject to inter-network routing restrictins becaue they are "input" to the router itself. If you were to draw a venn diagrm of the two (or more) networks, the router is the device that necessarily has an address on both networks.
I have to set the WAN input to accept even after the rule is set. I am trying to hide the router admin page from the 192.168.7.x subnet. So aren't these settings reverting the rules set ?
I have been setting this up for the whole day. You guys make it look so easy.
So if I understand correclty, you want the devices connected to the OpenWrt router (on the 192.168.7.0/24 subnet) to be unable to connect to the router itself, correct?
If that's the case, you need to set input = reject on the lan firewall zone.
Keep in mind that this action will cause DHCP and DNS to be locked out, as well, so you'll need to create rules to allow that. See the "guest DHCP" and "guest DNS" examples from this tutorial as a template, but in your case you'll be doing this for the lan zone as the source.
I think the simplest method for what you want is to connect the WAN port of your openwrt router to one of the LAN ports of the purple router would suffice to what you want. Set the SSID on your openwrt router to something different than the purple router and connect those isolated devices to that SSID.
my understanding is @RobusTetus only wants a secure area...not the entire network to be sectioned into 2 separate networks. As long as the SSID on the red network is identifiable as the secure network then this will achieve his aim.
The order of the rules is important. From memory, the firewall operates on a "first match" basis. The first rule with a pattern which matches the traffic takes effect, and all subsequent rules are ignored.
If you have an earlier rule which denies certain traffic, and a later rule which allows the same traffic, the earlier rule will take precedence; the later rule will never take effect (the term for it is "shadowed rule") so the desired traffic will never be permitted.
A general rule of thumb when configuring firewall policies is to have the narrowest scopes further up, and broader scopes further down. There are exceptions (of course), such as intentionally wanting to block specific traffic on an "everywhere" basis, but for general traffic control the principle of narrowest-to-widest applies.
Some examples:
Rule 1: Allow SSH from host A to host B (narrower scope)
Rule 2: Deny SSH from subnet A to subnet B (wider scope)
That would allow specific SSH access between two hosts, but block SSH for any other hosts in those subnets.
Rule 1: Allow HTTP from subnet A to everywhere (wider scope)
Rule 2: Deny HTTP from subnet A to subnet B (narrower scope)
In that example, rule 2 would never kick in ("shadowed rule"), because the "to everywhere" pattern in the preceding rule would take effect; subnet A would be able to use HTTP when talking to subnet B. Instead, reversing the order of the rules would allow granular control:
Rule 1: Deny HTTP from subnet A to subnet B (narrower scope)
Rule 2: Allow HTTP from subnet A to everywhere (wider scope)
I tried switching the rules around, but it does not look like it makes much of a difference. At least in this scenario. I think it is because the zone settings always precede the rules...
This will permit me even getting an address from the DHCP server, even though it is enabled in the rules.
I am attaching the firewall config... because I am really at a loss.
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option output 'ACCEPT'
option forward 'ACCEPT'
option input 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option input 'ACCEPT'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Deny-Untrusted-to-Trusted'
list proto 'all'
option src 'lan'
list src_ip '192.168.7.0/28'
option dest 'wan'
list dest_ip '192.168.1.0/24'
option target 'REJECT'
config rule
option src 'wan'
list src_ip '192.168.1.0/24'
option dest 'lan'
list dest_ip '192.168.7.0/28'
option target 'ACCEPT'
option name 'Allow-Trusted-to-Untrusted'
option family 'ipv4'
list proto 'all'
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'
You guys make it look so easy.