So many of you have been asking for this episode
– well, here it comes. Actually, I’ve had so many questions from
you guys that we need to split this in two episodes. Here’s what we will do: First episode we
will look into a firewall configuration for our internal LAN, a guest network and a separate
network for our IOT devices. Second episode we will extend the LAN, guest
and IOT Wifi to a second Access point using VLANs. Stay tuned. (intro) Let’s log in to the web interface (which
is called Luci) of our first OpenWrt router. By default this is the 192.168.1.1 address. Here we go to Network, then Firewall. As you can see, there are already two firewall
zones predefined, namely LAN which is our internal network and WAN which is basically
the internet. Now – let’s not bother too much for the
time being what the settings here mean, I will explain them later. What we will do as a first step is that we
create two more zones by clicking on Add. Let’s call the first one GuestZone and save. Same thing for IOTZone and save. Then – important – click on save and apply. Let me quickly explain what we want to achieve. Nobody should be able to get into any of our
networks from the WAN interface. Our guests should be able to browse the internet,
so they need to be able to get to the WAN zone but they should not get anywhere else. We do not want guests to browse our internal
network. My IOT devices such as my vacuum cleaner should
not be able to get outside in any way. I don’t want these devices to phone home
to the vendor. So they should be confined in their zone. People in the internal LAN should be able
to browse the internet plus they should be able to browse the IOT zone, for example Web
interfaces of cameras which are in the IOT zone etc. Looking at the config page in Luci here we
can see that there are mainly three different settings that can be defined. Those are Input, Output and Forward. The possible settings are accept, drop or
reject. What do they all mean ? When a packet of data arrives at one of the
router’s interfaces it can either be for the router itself, so it is a packet for the
local host or for a process running on the router. Typical examples would be http – like we
just did with the web interface. The process that serves this interface is
running on the router. Or – alternatively – the packet could
be for a different network. An example would be if we browse the internet. Then the input interface would be the LAN
interface and the output interface would be the WAN interface. So as a first step we need some magic here
to decide where the packet wants to go and whether we accept it or whether we deny or
drop it. Under Linux this is typically done with iptables. IPTables has so called chains. The most basic chains are Input, Output and
Forward. If something wants to speak to a process on
the router then it needs to go through the INPUT chain first. If a process on the router wants to speak
to the outside world then the packet needs to go through the OUTPUT chain. If a packet wants to go from one Zone to another
then it will need to go through the FORWARD chain. If I wanted to browse to a page in the internet,
for example google.com, then I would first send a packet with a DNS request to the DNS
server on the router in order to find google’s IP address, so this needs to go through the
INPUT chain. The DNS daemon on the router would then need
to ask a DNS Server in the internet for Google’s IP address. This request would go through the Output chain. Once I have Google’s IP address then my
browser would try and establish a connection with it in the internet, so this request would
go through the FORWARD chain. Iptables has – like the name suggests also
various tables. The most important tables are called RAW,
MANGLE, FILTER and NAT. Each table can contain rules for various chains. This looks very complex. But don’t be afraid – we can simplify
this to a large extend. In real life for 99.9% of the cases we only
need the filter tables. Plus we might occasionally need Pre- and Postrouting
in order to NAT or rather MASQUERADE addresses. We’ll come to that later. For the time being we will concentrate on
INPUT, OUTPUT and FORWARD. Back to our Luci interface. With what we know now we can much better understand
the settings on this page. On the top we can see that there is a default
setting. This accepts Input, so things for processes
running on the router such as DNS, DHCP, the Web interface, or ssh access to the router. It has an accept on the output chain, so all
processes running on the router by default may access all other zones. And Forward is set to reject, so by default
everything is kept in its own zone. Now let’s apply the rules for the different
zones. First the WAN zone. Here we don’t really need to change anything. We want to reject incoming traffic. Let’s move to the LAN zone. The default settings are OK for what we want
to do. All three values are set to accept. Now there is just one thing to be aware of
with regards to the forward settings. Forwarding from one zone to the other is shown
in this left column and what this forward setting on the right means is forwarding between
networks in the same zone. Presumably by default you won’t have different
networks in one zone so don’t bother too much about the setting on the right. The most important one is the one on the left. Let’s see how we can modify this. We do this by clicking on Edit. Let’s do the first change here. We want our LAN users to be able to browse
the IOT zone, so at the bottom of the Zone settings we open the drop down box that says
“Allow forward to destination zones” and tick the IOT box. Let’s save. The settings for IOT seem to be OK. I do not expect an IOT device to open a browser
page on my router, so we can leave Input accepted. Now for our guests. We do not want our guests to open the web
page of the router configuration or try to ssh into the router, so we set input to reject. We do however want them to be able to browse
the internet, so we need to edit, then again go down to the bottom of the Zone settings,
then open the drop down box that says “Allow forward to destination zones” and tick the
WAN box. Let’s save. Before we click save and apply let’s quickly
double check. LAN can go to the WAN and to IOT. It can access the router itself. IOT is blocked from everything except the
router itself. Guests can only go the internet but not the
router itself or any other zone. Looks good so far, let’s save and apply. Before we define the network interfaces and
the Wi-fi SSIDs we need to talk about two more little things here. First, there are two exceptions which we need
to define for the guest network. As we deny access to the router itself, a
client from the guest network is blocked from two essential services: The first one is DNS,
I have briefly expanded on that before. The second one is DHCP. We do not want our guests to define IP addresses
for themselves. This should be seamlessly provided by the
DHCP server on the router. So for DNS and DHCP we need to define two
exception rules. This is done on the traffic rules tab. Let’s add a new rule here. I want to call it “Guest DHCP and DNS”
– we can pack both in one rule. Protocols are UDP and TCP (even though DNS
would strictly speaking only need TCP and DHCP only UDP but then we would need two rules). The source zone is Guest, the destination
zone is INPUT, so this device. And the destination ports used for DHCP and
DNS are 53, 67 and 68. Action is accept of course. Cool let’s save, then save and apply. Next let’s quickly talk about masquerading
or NAT which is short for Network address translation. The number of IP v4 addresses is limited. There are more devices on this planet than
public IP addresses. Therefore some IP address ranges are private,
namely the 10.x range, the 172.x range and the 192.168 range. You can do whatever you want in these ranges
and these addresses will never be routed in the internet. But how could a packet find its way back to
us if it comes from one of those private addresses ? We just tell the router to masquerade everything
that goes out to the internet with the public IP address of its WAN interface. This can be done in two ways. Either by ticking the box “Masquerade”
here on the zones or by adding a specific NAT Rule here on the NAT rules tab. (explain NAT rules) Awesome, our firewall setup is complete and
we can now add the Interfaces. We click on Network, then Interfaces. At the bottom I click on Add new Interface. I call the first interface guest. As protocol I will use a static address and
please tick the box “Bridge Interfaces”. This will help us in the next episode when
we add VLANs to extend to a second Access point. Leave the interface unspecified for the time
being. Click on Create Interface and now we can type
in all details. Let’s give the guest interface an address
in the 10.x range, for example 10.20.30.40. Very often routers have the .1 address at
the end, but there is no rule for this. I chose a class C network mask, that is three
times 255 dot zero and I leave everything else at default values on this tab. Just need to make sure that the router acts
as a DHCP Server, so I click on the DHCP Server tab and click on Setup DHCP Server. The default values should be OK for most use
cases. Last but not least, we need to assign the
interface to a firewall zone. This is done on the Firewall settings tab
and here we specify of course the guest zone. Let me quickly do the same thing with the
IOT network. Pretty much the same steps, just a different
IP address range. Here I chose the 172.18.18.19 address. Just any address I randomly picked out of
the private address range. Great, last but not least let’s add the
Wi-Fi interfaces. Let’s click on Network, then wireless. As you can see, I have two Wi-fi Network cards. One for 2.4GHz and one for 5GHZ. The most important setting here is the security. Guys, I will not go into detail on the wireless
settings. I have already made a couple of Wi-fi videos. Please do watch those if you have questions
on bandwidth, Roaming etc. Just one detail here, we need of course to
add the right interface to the right firewall zone. So IOT for the IOT wifi and guest for the
guest wifi of course. That’s it. Save, then Save and apply and we are done. Perfect, we have successfully segmented our
network into three firewall zones. We have a Wi-fi for Guests, for the LAN and
for our IOT devices with adapted policies. Guys, that concludes today’s episode. In the next episode we will extend the three
Wi-fis to a second Access point over a single cable using VLANs. Until then, many thanks for watching, liking
and subscribing. Stay safe, stay healthy, bye for now.
