Could anyone help me work out or point me towards a resource that explains how to work out the right settings for the firewall page in Luci?
I have a simple setup with just Lan, Wan and VPN and currently all the settings are set to 'accept' which is probably too open. If anyone could take a look at my original post that would be great (Correct permissions for firewall with WireGuard, LAN and WAN zones) but if not just a pointer to a howto etc would be really appreciated.
I'm confused as to what the relation between the first column in Luci (zone => forwardings) and the subsequent ones (input, output, forwardings) is. Are these related? Or is the 'zone => forwardings' part unrelated to the later sections? I understand that the 'input, output, forward' parts are referring to the Luci appliance itself (I think). What about the masquerading tick box?
Use text configuration file /etc/config/firewall, and edit it manually.
I do not recommend to use WireGuard, I recommend to use OpenVPN instead.
I can comment settings for OpenVPN-client:
WAN INPUT, WAN FORWARD -> REJECT,
TUN INPUT, TUN FORWARD -> REJECT,
forwarding ONLY LAN->TUN (forwarding LAN->WAN is blocked),
masquerading ONLY for TUN (due to blocked forwarding LAN->WAN).
Specific ports should be opened in additional sections.
Remove the forwarding from WAN to Wireguard. Reset the WAN accept and forward to 'Reject'. If you're using wireguard just to get remote access to your LAN (and will only be using it with trusted devices) then you can simplify the setup by adding the Wireguard interface to the LAN firewall zone, rather than having a separate Wireguard firewall zone.
No. The first column shows whether traffic from that zone is allowed to pass to another zone. So, for example, a LAN -> WAN forwarding allows any traffic from the LAN zone to pass into the WAN zone (and therefore the WAN interface) which allows you to access the internet. If you don't have a forwarding then you can add individual firewall rules to allow traffic flow (this is generally how you set up traffic from the WAN zone to any 'internal' firewall zones).
The 'Input', 'Output' and 'Forward' options relate to traffic inside the zone. The first two options control the default rules for traffic coming from that zone to the router and from the router to that zone. The third option controls the forwarding of traffic between interfaces within that zone.
Thanks very much for the answers. I'm not sure what I'm doing wrong but I made a single change, in the WAN zone I turned the INPUT to reject, rebooted the OpenWrt appliance to check it did not lock me out and have been unable to get back into it. Also the WireGuard VPN no longer works to other hosts on the LAN (from outside in the internet).
I am doing this via the WireGuard VPN, from a different location - is this expected or has something gone wrong? It seems to me all I did was ban traffic coming from the WAN to the appliance so I guess since the WireGuard process runs on the appliance this rule applies before subsequent rules to allow wireguard traffic to the LAN - is that right? So if the wireguard rule was above the WAN rule I just changed it would not have cut me off?
Just to clarify the stuff regarding separation of the 2 columns, is the attached image I mashed up correct?
And re the WireGuard / OpenVPN, I just switched from OpenVPN having used it for years, because it was on a computer that took a lot of electrical power. Now on the small SOC I have OpenWRT running on OpenVPN would be slow so I switched to WireGuard, which does seem to do the job perfectly well and is secure enough I am led to believe.
No - sorry for my ignorance here... Should I do that in 'general settings', 'port forwards', 'traffic rules', 'nat rules' or 'custom rules'?
Trying to think this through, from what you said before I think that when I rejected WAN traffic in the 'input' column, I am saying WAN traffic destined for the router interface ip address (as a destination address) is rejected. So you're just saying allow a single port through that fits that pattern (rather than wide open to all ports)? So perhaps under 'traffic rules' I can add 'UDP from WAN (source zone) to DEVICE (dest zone) on port 51820 accept'?
What I don't get though is why, when all I did was reject traffic from WAN to 'Input', I could no longer contact hosts on the LAN - (the VPN no longer worked) - is that because the Wireguard process is running on this machine and so packets destined for the WireGuard process will have a destination address of the WAN interface on this machine? BUT - if thats true, since I still had WAN => Wireguard enabled in the first column (zone => forwardings), why did this not allow the traffic? Is it a question of the order they appear in lists? (Is that the IP tables list?)
Whats the best command for viewing the iptables rules in order BTW - -L and -S both seem to make quite a bit of noise. Is there a better way to see whats happening under the hood?
Assuming you're running wireguard in OpenWRT, then you should add it as a traffic rule. Protocol should be udp, source zone is WAN, destination zone is Device (input), destination port is whatever you're using for wireguard. Everything else can be left as default.
Yes
Because the traffic has to be allowed 'into' the WAN zone first. When you had the WAN zone input set to 'accept' you had essentially disabled the firewall (which is bad). By putting it back to reject any traffic which doesn't match a firewall rule is blocked. So until you add a rule allowing wireguard traffic through to the device (and then onto wherever it needs to go) you won't be able to access any internal hosts through the VPN.
As for viewing the firewall, OpenWRT's use of fw3 or fw4 (depending on what version of OpenWRT you're running) creates a lot of default rules to direct traffic correctly. Any rules you add through LuCI are checked against in the order they are listed (afaik), but they will come after the default rules. You can view details of the firewall in LuCI, but it's not the most intuitive thing to look through unfortunately.
Thanks, thats all starting to click into place now I think.
Thats particularly interesting because I was really stuck on that point. This applies to all packets does it, even purely routed ones? So for instance to route traffic between 2 LANs (separate zones) which are not NATted (so its just pure routing going on) both would need to 'accept' input packets? I had got it in my head for some reason that the 'zone => forwardings' section dealt with simple basic routing without the involvement of the 'input / output / forward' section, but that is wrong I think now?
No, you're mostly right in what you're thinking. I think you're getting a little confused though because you're not properly considering the packet destination.
Traffic between two internal LANs is going to (in most cases) be directed to a specific host in either LAN. So the packet is going to have that destination in the header. This means when it arrives at the router and the firewall examines the packet it knows it's not intended for the router and is instead dealt with by forwarding rules (which can be automatically created by setting up appropriate zone forwarding).
However, when traffic is coming from an external source the packet will have the router's IP as the destination. So when the firewall examines the packet it thinks this packet is for me and therefore pass it through the input rules (unless there's a port forward which rewrites the packet destination and sends it on its way).
In the case of the VPN traffic, it's coming from external with it's destination set to the router IP. You're not using a port forward as WG is running on the router so the packets go through the WAN input rules. If the traffic is allowed through the firewall it'll then be passed to the WG service which decrypts the data and puts it on the VPN interface.
How does NAT fit into the description - I would assume NAT is a process on the router, the incoming packet from the internet will have the router IP address and some router chosen port number. So I guess it gets dealt with by the input rules?
I am not at that place today and don't dare mess with it remotely this weekend so I will probably wait until Monday to try this out, but I might make a mock up of what I believe it should be and post it here for checking if thats ok.
