Using an external DHCP Server (dhcp relay/dhcp forwarding)

Installing and Using OpenWrt Network and Wireless Configuration
1

I am sorry to bother the gods of openwrt, but I have spent an entire day (and night) trawling the web for answers and experimenting to no avail.

I have 2 IP cameras that I will put in my baby's and toddler's rooms to monitor their sleep. I am a little paranoid about the cameras 'phoning home'. We have a decent router/gateway from our ISP already, so I bought a lightweight router that is running OpenWrt. There are obviously guides online (e.g. forum post and youtube guide) of others trying the same thing, but they usually:
a. configure it all in the one OpenWrt router, or
b. they only require communications one way (i.e. IOT --> LAN only).
I want to be able to send and receive data from the IOT devices from my regular home LAN, I just don't want them to be connecting to the internet at all.

If I set up the OpenWrt router with an IOT WLAN, I am able to:
[x] block the IOT devices from the internet
[x] ping IOT subnet --> LAN devices
[ ] ping LAN devices --> IOT subnet :expressionless:
This is because the IOT devices are on a different subnet (e.g. 192.168.3.1/24). I can have everything on the same subnet if I make my OpenWrt device behave as a 'dumb' WAP, but then I am unable to block the IOT WLAN from the internet via OpenWrt's firewall or my ISP's MAC filtering of the OpenWrt ethernet connection entirely.

From all of my research thus far, what I need is to configure my IOT zone/interface/WLAN to use my ISP Router as the remote/external DHCP server, so that my cameras get a static IP address that I can work with; but then use the OpenWrt router to block traffic destined for subnets outside of my home's main one (i.e. 192.168.0.1/24)

TL;DR: How can I configure a OpenWrt 'interface' (e.g. my IOT WLAN) to forward/relay DHCP messages to my upstream/ISP router but still use the OpenWrt's cool firewall features for everything else? I had tried this and bricked my router and had to start again.

                ┌─────┐
                │ WWW │
                └──┬──┘
                   │
     ┌─────────────┴──────────────┐          ┌───────────────────────┐
     │          ISP Router        │          │     OpenWrt Box       │
     │        192.168.0.1/24      │ ethernet │WAN Port's MAC Address │
     │  Basic controls possible   ├──────────┤is assigned 192.168.0.3│
     │  (set static ip addresses, │ patch    │by the ISP Router      │
     │   mac filtering, etc.)     │ cable    │                       │
     │                            │          │                       │
     └─┬─────────────┬─────────┬──┘          └─────┬──────────────┬──┘
       │  Home WLAN  │         │                   │  IOT WLan    │
       │             │         │                   │              │
       │             │         │                   │              │
┌──────┴──────┐ ┌────┴───┐  ┌──┴─┐        ┌────────┴──────┐  ┌────┴────────────┐
│             │ │        │  │    │        │  Camera 1     │  │  Camera 2       │
│ My laptop   │ │My phone│  │etc.│        │ 192.168.0.201 │  │ 192.168.0.202   │
│             │ │        │  │    │        │ (ideally)     │  │  (ideally)      │
└─────────────┘ └────────┘  └────┘        └───────────────┘  └─────────────────┘

So far I have left LAN as default. WAN is the interface that is connected to my main home LAN, so I have set 'Input' to accept. The 'home' zone is simply set to everything to do with subnet 192.168.0.1/24, and 'iot' is everything to do with my specific wifi SSID for IOT devices.

firewall overview
firewall overview970×324 23.2 KB

Again, this works swimmingly, except that I cannot access my IOT devices from my main/external LAN because it is on a different subnet (e.g. 192.168.3.1/24)

2

You cannot have the same subnet on 2 networks of a router. In other words, the WAN and LAN of your OpenWrt router must not be the same. You'll have to use some other method to do what you want.

  • Do you need to use your ISP router, or could you replace it with the OpenWrt device? That would be the most straightforward -- configure the OpenWrt router to handle all networks an you'll be golden.

  • If you cannot remove your ISP router, is there a bridge mode that would allow it to pass the ISP supplied IP address directly to the WAN of your OpenWrt device?

  • If the ISP router doesn't have/allow bridge mode operation, you could consider moving everything behind the OpenWrt box (this would be double-NAT, but for many situations, that doesn't cause any issues, but it is not ideal).

Other ways you can handle this:

  • Does your ISP router allow you to configure static routes? If so, you can setup your OpenWrt box as a dumb AP with a guest network, but modify the firewall configuration to suit your goals.

  • If nothing above is an option, you can look at setting up a bridge firewall. I've never done this, so I can't advise about the specifics here.

2 Likes
3

Thank you psherman for your reply!

Sorry, my original post was perhaps a little light on details. As for IP subnetting:

  • ISP Router is the sole DHCP server in the network, but unfortunately can only handle one 255.255.255.0 subnet - in my case 192.168.0.1/24.
  • I have some static IPs assigned for certain MAC addresses, e.g.:
    • 192.168.0.9 is my NAS
    • 192.168.0.3 is assigned to the MAC address of my the WAN ethernet interface of my OpenWrt box
    • 192.168.201 and 202 are the IP cameras (ideally)

As you know, the trouble is the NAT layer at the WAN interface forces everything that is connected to the OpenWrt box to be on its own subnet, rather than the OpenWrt box forwarding/relaying DHCP queries of new OpenWrt hosts/clients on to the ISP DHCP server, which would then assign IP addresses.

As for your questions:

  1. I cannot remove my ISP router unfortunately.
  2. The ISP router does not have a bridge mode.
  3. The OpenWrt box is very 'lightweight', i.e. is nowhere near as powerful as the ISP box that we have, so moving the family on to it would be less than ideal.
  4. The ISP router does allow static IPv6 routes. Could you elaborate on your idea there?
  5. The ISP router does allow my to disable the DHCP server, which I assume would make it request an IP address from another detected DHCP server on the network, which could perhaps be my OpenWrt box?
  6. The bridge firewall looks interesting, I will need to read more into it and get back to you.
  7. Are you familiar with DHCP Forwarding/Relaying in dnsmasq?
4

There is a way, but it is not useful in your case.
What fits nicely to your needs is a modified guest wifi, instead of guest you can have the iot, as mentioned earlier.
Add in the ISP router a static route for the iot network or, if it is not supported, in the routing table of the management devices.

2 Likes
5

Ah, the famous trendy! Thank you for jumping in!

I had seen your recommendation of a modified guest/iot wifi in a previous post, which I have also tried:

  • ISP router services my family's 'normal' devices on 192.168.0.1/24
  • ISP allocates the ethernet interface of my little OpenWrt box with 192.168.0.3, so that I can manage it from the household LAN
  • OpenWrt box has a IOT WLAN, where it is the DHCP server of its own network 192.168.3.1/24

With this, I am able to successfully block the IOT devices from the internet AND they are able to ping my devices on my household LAN. The trouble is that they are behind a NAT layer, where my devices on my household LAN cannot ping them, e.g. I cannot ping 192.168.3.1 or anything on that subnet from my household LAN.

This is where your last sentence may save the day:

Add in the ISP router a static route for the iot network

My ISP router can only set IPv6 static routes. Could I set a IPv6 DHCP server on my IOT network, equivalent to the 192.168.3.1/24 (perhaps with a restricted range of 64 devices), then map a fixed private IPv6 range on my ISP router to route all traffic to that range? I am not sure if that question makes a lot of sense :sweat_smile: I also assume that I will lose all ability to address those IOT devices with IPv4 static addresses, e.g. 192.168.1.201 right? I have absoluely no clue about IPv6, but I will try and play around with that idea.

... or, if it is not supported, in the routing table of the management devices.

I am sorry, that was all greek to me. Do you mean a routing table on the ISP router or OpenWrt router?

6

Given the answers to my questions (i.e. you need to keep your ISP router in place and you don't want to put everything behind the OpenWrt router), you don't really have all that many options.

Since you said that your ISP router doesn't offer a way to add static IPv4 routes, you won't be able setup the network on your OpenWrt router and make it accessible from the main network. The method (which won't work without IPv4 routes on the main router) involves disabling NAT masquerading on your OpenWrt WAN and then allowing forwarding from WAN > LAN but not LAN > WAN on the OpenWrt firewall. Depending on the needs, you can add a specific network allowance from LAN > WAN (i.e. accept traffic from lan zone to destination wan zone 192.168.2.0/24).

Can you show us a screenshot of your ISP router's static routes page?

Failing all of that, the only remaining option to do what you want is to use a bridge firewall as I mentioned earlier, but I don't know if this will work or not.

1 Like
7

The proposed solution is a dumbAP with the additional iot network. There is no wan interface to nat. wan and lan ports are bridged and in the same broadcast domain, so the ISP router is dhcp server for devices connected to OpenWrt as well.

Maybe because I am :greece: :sweat_smile:

No, on the windows or linux or whatever workstations that you are using to manage the iot devices.

1 Like
8

OK, a little update... I'm close, but still no cigar.

I spoke to a friend, who happened to have an old Netgear router that I can recycle/re-use that should be powerful enough to be the 'central' router, instead of my ISP's router. He told me that he had tried OpenWrt on it, but that its WiFi performance was much better when using the Netgear/OEM firmware. Fortunately, the Netgear router's firmware does have a lot more functionality than my ISP router, including IPv4 Static Routing! :muscle:

With some of the keywords that you two listed above, and another entire day tinkering with kids crawling over me, I managed to get this to work:

┌──────────────────┐
│    WWW           │       Static Route in Netgear Router:              Static Route in OpenWrt Router:
└───┬──────────────┘         Dest IP Addr: 192.168.2  .0                  Target IP   : 192.168.1  .1
    │                        Dest IP Subn: 255.255.255.0                  IPv4-Netmask: 255.255.255.0
┌───┴──────────────┐         Gateway IP  : 192.168.1  .2                  IPv4-Gateway: 192.168.1  .2
│ ISP Router       │
│ 192.168.128.1/24 │
└───┬──────────────┘
    │
    │WAN Interface                       WAN Interface
    │192.168.128.2                       DHCP Client
┌───┴──────────────┐                     (Static IP in Netgear) ┌─────────────────┐
│ Netgear Router   │                     192.168.1.2            │ OpenWrt Router  │
│ 192.168.1.1/24   ├────────────────────────────────────────────┤ LAN Interface   ├───────────────┐
└───┬──────────┬───┘                                            │ DHCP Server     │               │
    │          │                                                │ 192.168.2.1/24  │               │
    │          │                                                └───────┬─────────┘               │
    │          └──────────────────┐                                     │                         │
    │                             │                                     │                         │
    │                             │                                     │                         │
┌───┴──────────────┐         ┌────┴──────────────┐              ┌───────┴─────────┐     ┌─────────┴────────┐
│Host 1            │         │ Host 125          │              │Cam 1            │     │Cam 2             │
│192.168.1.3       │   ...   │ 192.168.1.127     │              │192.168.2.201    │     │192.168.2.202     │
│(Dyn. Assigned IP)│         │ (Dyn. Assigned IP)│              │(Static IP in    │     │(Static IP in     │
│                  │         │                   │              │OpenWrt Router)  │     │ OpenWrt Router)  │
└──────────────────┘         └───────────────────┘              └─────────────────┘     └──────────────────┘

:white_check_mark: IOT devices are blocked from the internet via the OpenWrt Router's firewall (see below)
:white_check_mark: IOT devices can ping my household devices (i.e. 192.168.2.1/24 --> 192.168.1.1/24 works)
:white_check_mark: Household devices can ping the IOT devices (i.e. 192.168.1.1/24 --> 192.168.2.1/24 works)

Here's what the OpenWrt's firewall settings look like. I created a zone just for the 192.168.1.1/24 subnet called 'home':

Screenshot 2022-01-04 221053
Screenshot 2022-01-04 221053961×281 20 KB

OK, everything is great... except one thing... None of it works when I am running my VPN client on my computer (e.g. for Netflix) :sweat_smile:. When I turn the VPN client on my PC (say 192.168.1.3), the VPN client on the PC detects traffic destined to 192.168.2.x as an external network and pushes it through the VPN connection, which is obviously as useful as a chocolate teapot.

An obvious solution would be to white list the 192.168.2.1/24 subnet... Except that that the VPN client doesn't allow for that, and in any case, I would have to do that on every host.

I thought that a more 'elegant' solution would be to change the subnet mask in the Netgear router above to cover a wider address range, e.g.

  • Netgear: 192.168.1.1/22 (i.e. 255.255.252), which would cover 192.168.0.1 - 192.168.3.254, but where I keep the DHCP server's existing limit to only issue addresses to 192.168.1.2 - 192.168.1.127, which will avoid IP address conflicts.
  • OpenWrt Box: 192.168.2.1/24 (unchanged)
    This would mean that I can keep the working firewall settings, static IP addresses to the camera (that are available on my household LAN), while keeping those IOT IP addresses (e.g. 192.168.2.201) firmly within my PC's subnet, as far as the VPN client running on my PC is concerned.

I tried this, but couldn't get it to work. I was obviously completely off the mark when it came to the external DHCP server, so I thought I should check with the experts, is my above idea practical? What am I missing? Any buzzwords, or links you can share to point me in the right direction would be very appreciated.

9

No. If you do this, it will break the rest of the network. You cannot have overlapping subnets across a router.

The static route on your OpenWrt router is not necessary. It doesn't actually do anything at all. You can remove that and things will still work properly.

I'm not exactly sure what I'm looking at with the firewall summary screenshot, but if you want that reviewed, please post the latest files:

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

This is typically expected behavior. But it depends on the configuration of the VPN. Wireguard, for example, allows you to sepcify the IPs that should go through the tunnel -- so you can exclude RFC1918 addresses fairly easily. Since you're using this on your PC, you'll have to look at the configuration options on that system, as it is no longer related to any of your network infrastructure configurations (i.e. your routers and static routes are completely bypassed when the VPN is enabled on the PC).

10

One simple solution is to run the vpn on the OpenWrt and with the help of vpn-policy-routing package to divert to the tunnel only the interesting traffic, leaving the internal networks alone.

1 Like
11

@psherman , thanks for the feedback. I will try removing the redundant static route on the OpenWrt device tomorrow. The native client of my VPN provider does not support whitelisting. Their technical support suggests using the OpenVPN client to connect with their OpenVPN servers. The trouble is that I haven't found a good resource that explains how I can white list or split tunnel traffic destined for a separate (private) subnet. In any case, managing this on all of the PCs like this is a little cumbersome (but perhaps it's the only way).

cat /etc/config/network.

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fddf:14b2:7ec0::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option hostname 'OpenWrtBox'
        option ipaddr '192.168.2.1'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'
        option metric '10'

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'
        option disabled '1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'

config interface 'guest'
        option ifname 'guest'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.9.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option bridge_empty '1'

config device 'wan_dev'
        option name 'eth0.2'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config device 'lan_dev'
        option name 'eth0.1'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config route
        option target '192.168.1.1'
        option netmask '255.255.255.0'
        option interface 'lan'
        option metric '0'
        option gateway '192.168.1.2'

cat /etc/config/firewall:

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option flow_offloading '1'
        option flow_offloading_hw '1'
        option synflood_protect '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option output 'ACCEPT'
        option forward 'REJECT'
        option mtu_fix '1'
        option input 'ACCEPT'
        option masq '1'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'
        option reload '1'

config include 'glfw'
        option type 'script'
        option path '/usr/bin/glfw.sh'
        option reload '1'

config zone 'guestzone'
        option name 'guestzone'
        option network 'guest'
        option forward 'REJECT'
        option output 'ACCEPT'
        option input 'REJECT'

config forwarding 'guestzone_fwd'
        option src 'guestzone'
        option dest 'wan'

config rule 'guestzone_dhcp'
        option name 'guestzone_DHCP'
        option src 'guestzone'
        option target 'ACCEPT'
        option proto 'udp'
        option dest_port '67-68'

config rule 'guestzone_dns'
        option name 'guestzone_DNS'
        option src 'guestzone'
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'

config rule 'sambasharewan'
        option src 'wan'
        option dest_port '137 138 139 445'
        option dest_proto 'tcpudp'
        option target 'DROP'

config rule 'sambasharelan'
        option src 'lan'
        option dest_port '137 138 139 445'
        option dest_proto 'tcpudp'
        option target 'ACCEPT'

config include 'gls2s'
        option type 'script'
        option path '/var/etc/gls2s.include'
        option reload '1'

config include 'glqos'
        option type 'script'
        option path '/usr/sbin/glqos.sh'
        option reload '1'

config zone
        list subnet '192.168.1.1/24'
        option name 'home'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'home'

config forwarding
        option dest 'home'
        option src 'lan'
12

The trouble is that the hardware of the OpenWrt box is nowhere near as good. Making it the centre of the system would definitely lead to lower performance overall. The original idea was to simply use the OpenWrt's firewall features to 'jail' the IOT devices from phoning home, but I didn't realise what I was getting myself into :sweat_smile:

I was thinking a work around would be to:

  1. Point my PC's traffic to a spare IP address in my local subnet address range, e.g. 192.168.1.201, instead of 192.168.2.201
  2. These packets are considered local subnet traffic by the VPN client running on my PC, so it leaves those packets alone. They then go directly to the Netgear router, which then uses the following static route to pass all packets destined for addresses above .128 to the OpenWrt box's WAN interface, i.e.:
    192.168.1.128/25 --> 192.168.1.2
  3. The OpenWrt box then applies some sort of Network Address Translation rule to edit/forward the packet with destination IPs of 192.168.1.201 to 192.168.2.201 (camera 1) instead.
13

Some comments on your configuration:

First, is this guest network being used? If not, delete this interface.

This static route can be deleted.

Next, in the firewall... I'm guessing that you are connected to the upstream network via the WAN port, right? Since you have a static route to 192.168.2.0/24 (the OpenWrt LAN) via 192.168.1.2 (the OpenWrt WAN), you can actually remove the masquerading from the WAN zone.

What is this glfw script? Are you using a GL-inet device with their customized version of OpenWrt (and not the official OpenWrt versions hosted here)?

If the guest network (earlier) is not being used and will be deleted, you can remove all of the related guest firewall rules below:

Are you sharing any network drives or other samba devices? If not, delete these

Again, is this GL-inet firmware? What are these scripts doing?

Now... don't do this yet, but I'd recommend deleting these in favor of a different method of handling the firewall:

Currently, there is no forwarding rule to allow LAN > WAN. This is good as it prevents those cameras from having access to the internet. However, when you remove the above rules, it will also mean that your connectivity breaks to the cameras.

The reason I said wait on this part is that it would be a good idea if you could define your goals for the camera access. I know you don't want the cameras to reach the internet. However, the question is this:

  • do the cameras need to be able to initiate connections to the upstream/trusted LAN? If you have a NVR or similar on the main network, this may be necessary. On the other hand, typically IoT type devices are not trusted, so it may be desirable to prevent them from initiating connections with the trusted LAN. In that case, you'd want firewall rules that allow connections to be initiated from the upstream network (and allow the cameras to respond) but not vice versa.
1 Like