I have been using OpenWRT for some years now, but there’s still a lot to learn. Today I upgraded to OpenWRT 25.x and I tried to preserve my configs from the 24.x series. It didn’t quite work which probably due to my configs.
I ended upgrading without preserving configs, and now I’m slowly rebuilding things and wondering how I can make this easier in the future. Any input would be greatly appreciated.
The dmz zone is connected to a “dmz” interface configured with one of the ports of my Linksys router.
The dmz interface is statically configured to give an IP range (10.0.0.x) that’s different from the default one.
The dmz interface port is connected to a network switch where servers in the dmz can get their IPv4 and IPv6 addresses.
Traffic from the wan zone is allowed to reach the dmz, but traffic from the dmz zone isn’t allowed to reach any of the other zones (except wan).
Using IPv6 prefix delegation on the dmz interface I provision globally routable IPv6 addresses to the devices in the dmz. IPv4 traffic from the wan gets routed by a reverse proxy in the dmz.
To re-cap: I recently was forced to upgrade to v25.x with fresh configs.
My 3 servers in the dmz had static leases for their ipv4 and ipv6 addresses before my openwrt upgrade.
When I eventually reconfigured my dmz interface with dhcp4 and dhcp6 my servers within the dmz were still not visible in the OpenWRT web interface (luci). However, I did make some screenshots of luci before the upgrade which showed their previous 10.0.0.x addresses and when I ping those they respond.
Building on the previous point I ssh into the servers and reboot them which seem to trigger dhcp lease renewal and they show up in luci.
This setup will eventually stabilize I think. I’ve already done this adventure when moving from OpenWRT 23.x → 24.x. And it’s working quite well for many years now, but it’s a little bit hazzle to setup.
Questions
Up until now I’ve noticed that if a server has a 10.0.0 .200 address, it’ll get a corresponding ip6 address looking something like 2a01:700:1234:6304 ::200. In other words the suffix of the ipv6 address is inferred from the ip4 address. What’s this feature called? Is this a feature related to static leases defined in OpenWRT?
To simplify future upgrades should I release the static leases and shorten the lease periods, in order to force my servers to quickly check-in when the router is back online?
Or should I simply note their IPv4 addresses before the upgrade so that I can reach them?
Running `sudo dhclient -6 eth0` on the servers forces them to re-new their IPv6 addresses.
I’m also thinking about scripting the router setup using ansible which I’m already using for the servers. Any tips about that?
Thank you for reading this far. I would appreciate any advice and pointers regarding my setup, are there any guides, resources or specific documentation I should read?
After I set static lease on the IPv4 address in LUCI, and renewed the IPv6 lease, the router gave me an ipv6 address with the same suffix as the ipv4 address.
Can't confirm that's always true. I got only one dhcpv6 client receiving an ipv6 suffix showing the last hextet to be the last octet of it's ipv4 address. Most of my other dhcpv6 clients are running debian trixie and do receive some non ipv4 related ipv6 suffix.
I would think it depends on what DUID type a given dhcpv6 client is sending to openwrt dhcpv6 server. There are 4 types of DUID as far as I understand from reading RFCs.
It might be worth to look what DUID type your servers are sending into your openwrt router.
Is your concern about: a.) A duplicate IP being issued by DHCP?
or b.) Because you rely on the lease list in LUCI to see your server addresses?
For a.) as long as the server is online and replies to ICMP, you shouldn't have issues with duplicate IPs if you are using DNSMASQ. I believe DNSMASQ uses ICMP to an address before issuing it to see if there is a reply – indicating address is already in use. (Thereby mitigating risk of a duplicate address being issued.)
Additionally, you have the option from LUCI "Overview" screen to reserve an address to a particular device's MAC address.
For b.) You could then access the list of all reservations from the Network>DHCP screen of LUCI to reference a list of all devices by name and IP address. Since you refer to them as "Servers" you would probably want to have fixed reserved addresses for them anyway.
Yes, that's the feature I've been using. I realize I called it "static lease", when in fact it's still a dynamic lease but reserved.
Mainly I want to simplify the process of rebuilding the network if/when I'm forced to do an OpenWRT upgrade that doesn't preserve configuration. Yes, I want to solve b) and a) I didn't even consider.
I compared my servers' DUIDs from the 24.x version, and their DUIDs from the 25.x version and they're not the same so something's changed about OpenWRT DUID functionality. I skimmed the 25.x changelog and the DUID functionality has been tweaked somewhat for supporting IAIDs for static IPv6 leases.
Stepping back a bit I think there's two possible approaches.
Approach 1: Client-side configuration
Set static ip4 addresses on my 2-3 servers, and re-use the last ip4-octet to set an IPv6 token so that when the router sends out an IPv6 global network prefix it will result in IPv4 and IPv6 addresses with corresponding suffix.
Approach 2: Router-based configuration
Configure globally unique DUIDs on my servers (type 4 duid).
Today my servers are using vendor assigned DUID.
Setup static leases in OpenWRT that reference the servers' DUUIDs and set ipv4 address and ipv6 token.
Tradeoffs... I'm already provisioning my servers using ansible, so it's not hard to implement approach 1 but maybe I'll use ansible for openwrt which would make it easier to enable approach 2 as well which will make future update easier if I need to rebuild my OpenWRT configs from scratch. Or something in between.