OK, in configuration from initial state my question is not applicable, it makes sense only in Dumb AP being already configured. I don't know, why it doesn't work, please, write option src before option dest in config forwarding. There is also strange option
Got it. Now your router is configured as Dumb AP. So it is connected to main router via lan interface. The problem is in 'masq' option for this interface. Clients of guest wireless interface should use masquerading, so you should set 'masq' to 1 for lan interface. I don't know effect on Dumb AP operation. So you should enable 'wifi'->'lan' forwarding (already done), and set 'masq' to 1 for lan zone.
You are welcome! Masquerading changes IP address of sender by IP address of router itself. So router remembers in its table port number, and changes IP of reverse packet correspondingly.
I started trying to set it up on Friday evening.
Then spent most of Saturday on it.
After spending a good chunk of today on it, I decided to ask the community for help.
And there you were ;)!
For anyone stumbling upon this thread:
to finish up the firewall to isolate guests completely
add the following to /etc/config/firewall
config rule
option src 'guest'
option dest 'lan'
option name 'Disable Guest LAN Access'
option proto 'all'
option dest_ip '192.168.1.0/24'
option target 'DROP'
config rule
option src 'guest'
option target 'DROP'
option dest_port '80'
option proto 'tcp udp'
option name 'Disable Guest AP HTTP Access'
config rule
option proto 'tcp udp'
option name 'Disable Guest AP SSH Access'
option src 'guest'
option dest_port '22'
option target 'DROP'
The first rule disables people on the guest network (192.168.2.xxx) to access anything on the private network (192.168.1.xxx)
The second rule disables access to the router from the guest network.
The third rules disables ssh access to the router from the guest network.
One potential suggestion to consider with respect to the firewall. Consider dropping all connections from the guest network to the dumb-ap device (that is now also routing the guest network) and then selectively allowing services of interest (usually DHCP and DNS). This way, the guest network can not access the router at all, except as explicitly permitted by the firewall rules.
To do this, the default action on the guest zone would be reject for input, and two traffic rules would be enabled for DHCP (tcp+udp 67-68) and DNS (tcp 53),
Also - in your writeup, the guest zone addition to the firewall was neglected -- might be useful to show that, too.
When the media manager opens,
your very first action should be to change to the media namespace, and possibly further down until you have reached the namespace to which you want to upload the picture.
Thanks for the heads up, I have added the guest zone to the firewall on the wiki.
I have been playing around with your suggestion to Reject input and only allow DNS and DHCP, haven't gotten this to work yet.
When I reject input on the guest zone and I enable the traffic rule for DHCP.
I can ping devices on the 192.168.1.xxx subnet and ssh to them.
Also I can log into my gateway at 192.168.1.254.
config rule
option dest_port '67-68'
option src 'guest'
option name 'Guest DHCP'
option target 'ACCEPT'
option proto 'udp'
config rule
option dest_port '53'
option src 'guest'
option name 'Guest DNS'
option target 'ACCEPT'
option proto 'tcp udp'
I suppose I still have to add rules to block guest -> lan
config rule
option name 'Disable Guest LAN Access'
option dest 'lan'
option target 'DROP'
option proto 'all'
option src 'guest'
option dest_ip '192.168.1.0/24'
With the above added, everything works as before (and I suppose even better as all other ports are blocked).
So only these 3 rules are needed ;).
@WRTuser - Sorry if I caused any confusion about the rulesets. Yes, you still need the drop Guest > LAN access rule, as you have found and described. My intent was to prevent the guest network from accessing your secondary router itself (i.e. the dumb AP that is creating the guest network) on all ports except for those explicitly allowed.
That said, the three rules (plus the input reject for the guest network) is what I was aiming for, and in my experience does indeed work as intended (and hopefully is compliant with best practices -- I'm sure there are other people far more knowledgeable about firewall/security considerations who might be able to chime in if I have this wrong).
Everything else I haven't touched and is as it is out of the box.
For a visual representation you can check out step 3 at the webinterface config.
Also I haven't set up DNS of TLS (or HTTPS), but as I quickly scrolled the web and I think
if you set up your DNS server to 1.1.1.1 (i.e. cloudflare) they take care of it.