The goal is to build a public network (guest WLAN, hotspot, call it as you like it) with restricted access:
- Only several services are allowed (e.g. surfing).
- Clients from network 1 (192.168.4.0/24) shall not be able to communicate with hosts of network 2 (192.168.2.0/24) and vise versa.
Most of the tutorials for OpenWRT only cover this scenario where your OpenWRT device is the only router in the network.
with a policy that allows forwarding traffic from the zone ZONE_GUEST to the internet (zone WAN) via the interface WAN.
Adding a few rules to the firewall is all you have to do then. It is a very practical way to easily allow your guests to use your internet connection without allowing them to communicate with clients in the zone LAN. If you wish to set this up, visit the OpenWRT page.
How about this scenario?
If you have an existing network and only want the OpenWRT device to be a dumb Access Point (AP) that uses your LAN resources you won’t find as many tutorials. Traffic originating from zone ZONE_GUEST has to be forwarded to the zone LAN instead of WAN. What you need to do is:
Edit your LAN interface:
Adapt it to your existing network configuration (DNS, gateway, …). Don’t forget to turn off your DHCP for this interface. I assume that there is already a DHCP server in your network. If not you may have good reasons for that and should turn it off in your AP as well.
Create a new wirless network:
Edit the new interface:
Under “Common Setup” choose:
Under “Firewall Settings” choose:
Edit the firewall settings:
What is not shown here was not touched. So I focus only on the differences to the standard configuration.
This may be your general settings:
This is especially for your zone:
Get your network accessable:
Right now, you’re not able to connect to the new network nor are you able to do DNS requests if you use DHCP. This is because your zone’s INPUT rule is set to reject incoming traffic (to be more precise, these packets will hit the zone_Z_Wifi_Mitg_src_REJECT chain if you take a look in your iptables output).
Make an exception for DHCP in the tab “Traffic Rules” so that DHCP offers from 192.168.4.1 can reach your WLAN clients.
Do the same for DNS:
Tell your router about the new network:
Reaching this point you are able to initiate connections to clients of the LAN segment, but clients from LAN can’t connect to ZONE_GUEST, because there is no forwarding rule making this possible. Furthermore you can reach far away destinations like this website BUT: We did not enable NAT on LAN, so packets are routet to my website and unfortunately do not find their way back (router with IP 192.168.2.1 is asking it’s default gateway for a route to network 192.168.4.0/24 what will never be answered). Therefore, if you want to avoid double NAT (of course you want) you have to tell your router a route.
Gateway: 192.168.2.2 <– this is the LAN IP address of your AP, because it knows how to reach 192.168.4.0/24
Isolate clients within the WIFI_GUEST network:
To block traffic between clients in the network 192.168.4.0/24 you may take a look at the option “isolate” of the wireless configuration in OpenWRT. You can try if isolation is successful through a pingtest between two clients of this network before and after you isolated the clients with this option. If you don’t set this option you may think of other possibilities to protect your network against DNS poisoning, DHCP injections and so on.
Restrict access to certain services:
To restrict the clients in your network to use only allowed services it is the best option to set some firewall rules in the tab “Custom Rules” where you can add terminal commands that will be executed on firewall start. Here is an example (don’t change the command order unless you really know what you do):
# Insert (-I) entries into your public zone's forwarding rule ## Reject all traffic iptables -I forwarding_ZONE_GUEST_rule -j REJECT ## Reject all TCP traffic with reset flag to avoid unnessecary timeouts iptables -I forwarding_ZONE_GUEST_rule -p tcp -j REJECT --reject-with tcp-reset # Allow certain traffic iptables -I forwarding_ZONE_GUEST_rule -p tcp -m tcp --dport 80 -j ACCEPT -m comment --comment "Allow traffic on port 80" iptables -I forwarding_ZONE_GUEST_rule -p tcp -m tcp --dport 443 -j ACCEPT -m comment --comment "Allow traffic on port 443" # Reject traffic with destination LAN iptables -I forwarding_Z_Wifi_Mitg_rule -d 192.168.2.0/24 -j REJECT # Add a closing NewLine, otherwise the last command may be not interpreted correctly (e.g. because you did not use vi as editor).
What does it mean? First, a rule to reject all traffic that shall be forwarded from ZONE_GUEST to another is created. The chain forwarding_ZONE_GUEST_rule is a user chain. Don’t use system chains like zone_ZONE_GUEST_forward for your hacks. It works pretty fine if you restart the firewall when the AP is running. But these system chains are rebuild each time the corresponding interface is re-upped. That is also the case while booting -> firewall settings are applied, interfaces come up, rebuild, your hack is forgotten. Additionally every TCP packet is rejected with reset flag to avoid timeouts. Then rules are applied that allow traffic going to specific destination ports and finally access to LAN resources is prohibited.
Be careful with the interpretation of what these firewall rules are able to. Right now all traffic on TCP ports 80 and 443 is routet to the LAN and via gateway to the internet. Ok so far. But that does not mean that only HTTP(S) traffic is allowed. It means every connection with these ports, whether they are used for HTTP(S) as they were designed for or to transport other protocols is allowed. To ensure only HTTP(S) traffic is allowed you need to set up an OSI level 4 firewall (~proxy) like squid instead.