Configuration: DNS, client isolation, LAN restricted, FW, VPN

Installing and Using OpenWrt
1

Hello,

I recently set up a basic OpenWRT configuration that mainly acts as a router.

Here is my config:
OpenWRT (version 21.02.1) running on a Raspberry Pi 4 model B (version 4GB).
I use an USB to Ethernet adapter to get a second RJ45 port.

On a native port, it's the LAN interface, and WAN for the adapter.

The DHCP server service is enabled for the LAN interface, while the WAN interface is set up as a DHCP client.
LAN network is 192.168.1.0/24, OpenWRT has the static IP @ 192.168.1.1 and serves as the LAN's gateway.
I have a local DNS server and want to use another public DNS as a fallback if the former stop responding.

  1. First questions regarding DNS.
    If i want to use specific DNS servers, should I enter their IP addresses for the WAN, the LAN or both?
    Let's see the situation the point of view of a device connected to my LAN that will get its network conf via DHCP.
    Also, for DHCP, I'd like that OpenWRT indicates to the clients that they should use this local DNS server instead of seamingly * having OpenWRT performing DNS resolutions on the behalf of said client.
  • On a Windows device at least, DNS obtained from DHCP are listed as 192.168.1.1, but I'd rather have the PC use 192.168.1.30 directly instead of forwarding requests to OpenWRT.

Now, what if I enable OpenVPN client on OpenWRT and want local devices to access the internet only via the VPN connection. Will they use the DNS servers specified in the OpenVPN config file, or OpenWRT DNS servers will still prevail ?

As mentioned earlier, if I set 2 DNS servers for an interface, the order specified will be use like a priority?
Or will requests be randomly or alternatively forwarded to each server an equal number of times?

  1. In this scenario, I'd like to isolate a device on the LAN (meaning it could not see other devices on the LAN, and vice versa) but still allow it to access the internet. Let's call it EvilDevice.
    I guess I could use a separate VLAN to achieve this, but I'm not a network guy, and I feel like that's too much hassle for just 1 device. If I had ten's of such EvilDevice, then I would probably reconsider the option.
    I can't install any software on EvilDevice. Besides, EvilDevice will be accessing the LAN via a WiFi Access Point on the LAN.

Unfortunately, I don't see any other option, but perhaps you have some ideas?
The FW will be useless here, right? Since devices on the LAN can access each other without having to go through the gateway.

  1. Next, EvilDevice, will need to access some other devices on the LAN (at least one, but I suppose at this point it is less critical if it can access other local devices). But, access to the Internet must be blocked. All communications are restricted to the LAN.
    I assume I can now benefit from using the FW, maybe iptables?

For guidelines given in 2) and 3), DHCP should be allowed regardless of the rest of the specified restrictions. And although EvilDevice will be configured via DHCP, I can assign it a static IP address to make the overall set up easier (I just hope it won't generate on its own a new random MAC address each time it is powered on or after X seconds :angry: ).

EvilDevice : 192.168.1.13

Maybe something like that?

iptables -A FORWARD -s 192.168.10.13 -j DROP # forbid WAN connections
iptables -I INPUT 1 -p udp --dport 67:68 --sport 67:68 -j ACCEPT # allow DHCP protocol, but I'm not sure that's actually required ? The rule above should not interfere with DHCP requests?

Please let me know if you need any clarification.

Thanks.

2

For custom DNS you should use:

  1. WAN DNS on router, and default setting for DHCP;
  2. Specific DHCP settings with '6' option.
    Only single DHCP server should act at the moment.

Isolation could be configured only via VLAN. You can leave device in the same network, but all traffic should go via OpenWRT router (in case of dumb switch it will connect to the whole network).

1 Like
3

Thanks for you reply.

  1. You mean that I can get the DNS servers provided by my ISP via DHCP, that won't interfere with DNS queries from local devices?
  2. Only OpenWRT acts as a DHCP server in my LAN. Regarding DHCP settings, what is the "6" option for, if you don't mind me asking?

I have both dumb and L2 switches in my LAN, so even if I configure VLANs on the managed switch, overall that won't isolate devices because the VLAN tag will be removed by the unmanaged switch?

4

This should help you better understand DNS configuration specifics:
https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#upstream_dns_provider

2 Likes
5

All switches (dumb/unmanaged and smart/managed) are L2 devices -- switching is an L2 construct. Some higher end managed switches have L2+ and L3 (routing) features.

Unmanaged switches are plug-and-play devices and do not have any configuration options. Those are designed only for use with a single network (untagged). Their behavior is not defined for tagged networks.

Smart/managed switches are VLAN aware and have the ability to be configured to properly switch multiple networks, untagged and tagged.

Do you have any smart/managed switches in your network?

There's a kernel of truth here, but there's much more to it...
First, VLANs must be configured first on the router if you want the networks to behave as normal routed networks. Then you need to configure the VLANs on a managed switch. This will allow you to configure trunk ports (i.e. multiple networks on a single port) and access ports (one network, untagged, typically to connect end devices).

You should never put tagged networks through an unmanaged switch because, as I mentioned earlier, the behavior is undefined. This means that the results can be unpredictable -- ranging from "it just works" to severe network issues. Many unmanaged switches will pass tagged frames without stripping them, but because the switch is not configurable, you cannot setup access ports and you cannot control which ports carry each VLAN. Some switches may strip the tags, or others may just choke on the tags altogether. So if you wish to use VLANs, make sure you don't have any tagged networks running through the unmanaged switches (or upgrade to managed switches).

1 Like
6

Or “3,192.168.1.1 6,192.168.1.1” to give out gateway and dns server addresses.

Each device has its own DNS, so different DNS servers are independent.

It is written above, and I also do not recommend use unmanaged switch with tagged traffic. Purpose of unmanaged switch is to extend existing untagged traffic.

1 Like
7

Thank you.

I can definitely disable peer DNS option:

# Disable peer DNS
uci set network.wan.peerdns="0"
uci set network.wan6.peerdns="0"

But, can I use a local DNS server for the WAN interface? I mean, since it's the WAN, is it not expecting to be given a public IP address?

# Configure DNS provider
uci -q delete network.wan.dns
uci add_list network.wan.dns="192.168.1.30"
uci add_list network.wan.dns="8.8.4.4"

But maybe I was not clear. I don't want OpenWRT to use it's own DNS resolver service (dnsmasq), but just tell LAN client via DHCP to use (or maybe forward DNS requests) to my local DNS server (192.168.1.30).

A picture is worth a thousand words:
DHCP_DNS

8

Thank you.

Would what you suggest give the behaviour I described?
Your article is relevant for my LAN, but @vgaetera 's answer is about configuring the WAN interface.
So, I'm still somewhat confused, sorry :blush: .

Also, can I provide several DNS server via the "6" option, something like that:

“3,192.168.1.1 6,192.168.1.30, 8.8.8.8”

Or perhaps it should be written this way:

“3,192.168.1.1 6,192.168.1.30 6,8.8.8.8”

Not problem mixing local and public DNS servers IP addresses?

9

Thank you for the detailed response.

At the moment, my LAN consists mostly of unmanaged switches, although I also have a L2 managed switch that is used as a dumb switch.

1 unit of (currently in use, but dumb switch usage)
TP-LINK TL-SG1024DE

I also have several 8 ports unmanaged switches at various locations in my house.

I own those as well:

2 units of (spare switches, not used at the moment)
TP-Link TL-SG3424

2 units of (spare switches, not used at the moment)
Netgear GS110TP-200EUS

But .. but ... as I said earlier, EvilDevice features only WiFi to access the network. Can WiFi APs support VLANs too?
Well, apparently mine does !
802.1Q => u6-lr

I actually also have an older model, UAP-AC-LR , that does VLANs as well, but I lost access to its controller (not sure I want to reset it as I'm not confident that I have made a backup of its settings ... I know I should).

10

For the isolation I have a common setup but didn't manage to get it working with 21.01. It worked with 19.07 though. This is the setup I have: Client isolation with VLAN in 21.02 - How?.

1 Like
11

Yes, sure. They will be used in the specified order. @vgaetera has written about WAN interface configuration with custom DNS.

1 Like
12

To answer this precisely:

  • standard Wifi, on its own, doesn't work with VLANs. By that, I mean that there can only be a single network on any given SSID.
  • If you are using WPA2/WPA3 Enterprise, you can actually have the RADIUS server handle the mapping of clients to VLANs. This is not an option for WPA2/WPA3 Personal.
  • APs themselves can often broadcast multiple SSIDs (depending on the hardware and firmware/software). In these cases (including your Unifi AP), you can associate a different VLAN to each SSID, and thus have wifi with multiple different VLANs in the form of different SSIDs (still a 1:1 mapping of SSID to VLAN).

You can, therefore, create an additional SSID that maps to the VLAN that "evil device" will be using using.
In order for this to work properly, there should be either a direct connection between the router and the AP(s), or it should be handled such that the tagged networks only pass through managed switches (there should be no unmanaged switches in the path).

You've got three options here if you want to use this AP for the new "evil device" VLAN > SSID:

  1. verify that you do have a functional Unifi Controller backup for that AP... you can spin up a controller instance on any Mac/linux/windows machine, restore the backup, and see if it contains what appears to be the working configuration of the AP. If that's the case, you can then use the controller to add a new VLAN + SSID.
  2. Reset the AP and start over with the Unifi Controller. If your setup isn't that complicated, this can be a pretty quick operation.
  3. Reset the AP and then install OpenWrt on it. From there, you can configure it without needing the controller. That said, if you're using other Unifi devices, you may want to stay within the Unifi context for easier management.

All Unifi APs (running the Unifi firmware or OpenWrt) support VLANs (802.1q).

1 Like
13

That's very well explained, thanks.
Let's say I create multiple SSIDs, and assign a different VLAND ID for each one of them.
Then the AP in question is plugged to a managed switch with VLAN enabled.
What kind of VLANs should I use? VLAN by port, right? MAC address VLANs in this scenario wouldn't be suited I guess.
But what VLAN ID should I affect to the port to which the AP in connected? Trunk? That's very old memories for me, but I think trunk allow all VLANs to pass?
Afterthought: maybe I can actually affect several VLAN IDs to the same port, but not necessarily of them at once (I think I remember that now). Assuming that's feasible, then I could tag the traffic going through the port with all the VLAN IDs (and only those) corresponding to the differents SSIDs of this AP.

That's off topic, sorry, but that would be an added incentive if other advanced features of a managed switch could benefit my usage (because just replacing physically unmanaged switches by managed switches takes some time, plus there is the initial setup that will virtually take the same amount of time regardless of the subsequent configuration I set up, there's probably some overlap to read the manual of each switch - because the GUI is usually really slow on entry models like those I have so it might be better to SSH into the switches and use the CLI instead - and so on).
I have some Rx errors / packets dropped, if (I'm not sure yet) that comes from local congestion, could link aggregation help eliminate that? Or Shortest Path Bridging (SPB)? Or QoS? And a few other features could also be useful I suppose, be it to reduce congestion / errors or for other purposes.

14

But if we consider a client on my LAN getting its network conf via DHCP, what is relevant regarding the DNS servers it will use?
WAN's DNS servers or LANs' ?
Anyway, that now seems to work the way I wanted it, thank you (I modified both WAN's DNS and LAN's DNS at the same time, so I don't know which one helped achieve this result):
DHCP_DNS_2

15

You'll use standard 802.1q VLANs and you will the VLAN membership on a per-port basis (this is usually pretty easy to do).

  • The ports that carry multiple networks (called trunk ports) will have:
    • zero or one untagged network
    • one or many tagged networks
    • the standard allows for untagged networks on a trunk port, but some people will advise against using trunks this way -- they will instead say to use all tagged networks.
    • the configuration of the tagged (and untagged) networks must match on either side of the the link. That is to say that the router and switch must have the same configuration of VLANs on the corresponding ports. Same with switch-to-switch connections.
  • Ports that carry just a single network, untagged, are called access ports.
    • this is the way that most end equipment expects to connect to the network.
    • the way that this is configured may vary from brand to brand with respect to the user interface. Some require that you do two steps - set the port to be a member of a specific network as untagged, and then set the PVID to that VLAN ID.
    • in some rare circumstances, you may have a device that uses a single tagged network (some VOIP phone systems do this) -- this isn't technically an access port (because of the tagged network), but it is not a trunk either (because it is just one network). I don't think you'll encounter this, though.

Trunks allow multiple networks -- it can be all of your VLANs or just a subset. You specify the networks on each port corresponding to your needs.

I'm not sure what you are saying here. Can you elaborate?

Managed switches have many features, although it obviously varies depending on the switch model/brand. Some such added features are port isolation, storm control, STP/loop detection, and other things.

It doesn't have to take that much time, depending on what you are doing with the configuration. You can also do your configuration for many of the features sort-of-offline.... in other words, connect it to your network so you can do the configuration, but leave your devices connected to the unmanaged switch until you're done with the configuration -- this will minimize downtime of those downstream devices.

Do whatever works best for you. Yes, the web interfaces can be a bit slow, but again, you don't necessarily need to do all that much in terms of configuration. Even with entry level switches, you should be able to do this within a few minutes once you know what settings you need to adjust. If you use the web interface, you don't need to learn the CLI for each individual switch, but whatever is best for your comfort.

This depends on the cause of the dropped packets. You could also have issues related to a bad cable or physical port, a failing device, or other things (especially if there is a wifi link in the mix).

1 Like
16

For the client, the DNS servers it will use are those advertised by the DHCP server (i.e. option 6, or if not specified, OpenWrt will by default send the router's address for DNS).

How it will use those DNS servers (when multiple are specified) depends on the host OS -- some will use the first entry as the priority, and fail over to the second one if the first is not available and/or cannot answer the query. Others will load balance in some way -- round-robin/alternating, or based on resolution speed or other things. So it isn't necessarily guaranteed that a specific client will use the DNS servers in the order you'd prefer. So only send the DNS servers you actually want the clients to use and assume it is out of your control how/when selects one over the other.

The above assumes that the client is going to use the DHCP advertised DNS servers... many clients can be set locally to use alternate DNS servers, and in some cases this may be done at the application layer (like a browser or other app may use a specific set of DNS servers).

1 Like
17

I think I confuse that with trunk, you can allow, as you said 'one or many tagged networks'.

Thank you very much for the explanations, I really appreciate that.
That confirms I really need to improve my skills if I want to go the VLAN route !
Moreover, I will have to think through the network infrastructure that would be optimal before configuring anything.

For inter-connections between multiple switches, or one switch and the router, it is then best to use trunk for the ports used for these kind of links?
Maybe include all tagged networks between the router and the switch it is directly attached to, and the rest depending on individual requirements for a given switch and the devices that are connected to it?

And is it possible to have a switch use a combination of per-port VLANs and MAC addresses based VLANs?

Yes, I used the '6' option and turned off the peerdns option.
I know I can usually set DNS servers manually for a device (not sure for IoT devices though) and still get DHCP network settings for the rest, but since I have quite a lot of devices, getting everything from the DHCP server is more convenient.

Maybe a nice feature (unless it already exists), would be to tell OpenWRT to advertise only the first DNS server to clients; unless it is not responding, in which case it would send the second DNS server as a fallback. Like an active / passive type failover to avoid having DNS resolution as a SPOF.

18

Hello,

I have added a rule in the Firewall - Traffic Rules section to block EvilDevice from accessing the internet.
BLOCK_Evil_Device_Internet

Let's assume that EvilDevice has the 192.168.1.126 IP address set as static (reserved by the DHCP server).
Can you please confirm that should work as intended?
I can also add a similar rule but instead using its MAC address in case its IP address ever changes, I just hope it's not gonna modify its MAC address on the fly, otherwise I'm screwed !

The new rule appears at the bottom of the listed rules, does that matter? More generally if there are priorities, and in particular for this case?

19

This will work as long as the EvilDevice is on a network in the lan firewall zone. (i.e. 192.168.1.0/24 must be part of the lan zone). If this is not the case and you have placed this network into a different zone, you just need to make sure that the source zone for this firewall rule matches.

This should be fine in theory, but I'd have to see your complete firewall to know for sure. Order does matter, but only insofar as relevant rules that could match this condition. To be more specific...

  • the firewall will evaluate all incoming packets against the defined firewall rules, and it does this sequentially.
  • the rules will be evaluated (sequentially) until there is a rule that matches. If it finds a match, it will execute that rule and then stop evaluating the rules.
  • if there are no matching rules, the firewall will execute the default action (which in this case is the forwarding rule from lan > wan (which I assume in your firewall rules) -- this says that unless anything else in the firewall rules prevent traffic from flowing, go ahead and allow the traffic originating on the lan (destined for the upstream network(s)/internet) to be forwarded to the wan.

So, if I have two rules in a few different states:

  • The following would allow all traffic except for 192.168.1.126 to pass to the wan:
  1. src lan + 192.168.1.126; dest wan; reject
  2. src lan + 192.168.1.0/24; dest wan; accept [strictly speaking, this rule is not necessary in this case]
  • This next one would allow all traffic including 192.168.1.126 to pass to the wan because the packet would match on rule 1 (because it covers the entire network):
  1. src lan + 192.168.1.0/24; dest wan; accept
  2. src lan + 192.168.1.126; dest wan; reject
  • Now no traffic will flow at all
  1. src lan + 192.168.1.0/24; dest wan; reject
  2. src lan + 192.168.1.126; dest wan; accept
  • and finally, only .126 would be allowed, the rest would be blocked
  1. src lan + 192.168.1.126; dest wan; accept
  2. src lan + 192.168.1.0/24; dest wan; reject

Does that make sense?

1 Like
20

I think that's alright:

FW

I think it does make sense to me, thank you.
Basically, the first rule that matches a device prevails, no matter its action is accept, drop, reject and so on.
Of course, if a rule is about a single IP address, it is used as is, otherwise, a CIDR IP is expanded to cover the corresponding IP range of the associated network.

Here is the rest of the FW configuration:

FW2
FW2978×827 58.6 KB

FW3
FW3862×1042 96.8 KB

1 Like