Create an External-Facing IPv6 Subnet on OpenWrt

20 minutes to read

Some home Internet users have a need to expose some devices on their home network to the Internet and meanwhile block external access to other devices. For example, some users may wish to allow external access to their home server and prevent their smartphones and workstations from being accessible from the Internet. To achieve this goal, these users can create a subnet exposed to the Internet on their router and put the external-facing devices into this subnet; the other devices can thus be kept on the default local area network (LAN) subnet, protected behind a firewall that blocks external access. The external-facing subnet is commonly referred to as a demilitarized zone (DMZ).

Users whose Internet service provider (ISP) has provided them with an IPv6 routing prefix that is shorter than or equal to /63 can create two IPv6 subnets to achieve this goal. Because of IPv4 address exhaustion, it is impractical for home Internet users to have IPv4 subnets in the Internet: most every home Internet user gets just a single public IPv4 address from their ISP if they can get one at all, and many users cannot even get one and thus are behind their ISP’s NAT. However, with increasing IPv6 deployment to home users, they can have multiple IPv6 subnets instead (as long as their ISP does not allocate them just one /64 prefix or a single /128 address). Even for users who have only one /64 prefix or one /128 and users whose ISP does not provide IPv6 at all, as long as they have a public IPv4 address, they can use a 6in4 tunnel like Hurricane Electric IPv6 tunnel broker to get IPv6, and these tunnels may generously provide them with a /48. (The drawback of relying on IPv6 for subnetting is that hosts in the DMZ cannot be accessed from an IPv4-only network. For example, if someone stays at a hotel whose Wi-Fi does not enable IPv6, then they cannot access their home server during their stay.)

This tutorial will walk through the steps to create an IPv6 DMZ on OpenWrt. The current version of this tutorial has been validated on OpenWrt 25.12.5.

Connect to the Router via SSH

This tutorial’s instructions will ask the network administrator (who is responsible for configuring the router) to run commands on the router through SSH. The network administrator can follow OpenWrt’s documentation regarding SSH for instructions to connect to the router via SSH.

The LuCI web interface can be used to create the identical DMZ configuration too. However, this tutorial only includes instructions for the command-line interface for these reasons:

  • LuCI is not always pre-installed on OpenWrt: snapshots and images for low-memory devices (4MB flash and/or 32MB RAM) do not come with LuCI pre-installed. However, the command-line interface is always available.
  • Instructions for LuCI are subject to more frequent changes due to new OpenWrt releases possibly changing LuCI’s graphical user interface.

Set Shell Variables for DMZ Components

Once an SSH connection to the router has been established, run these commands on the router to set shell variables that will be used throughout this tutorial:

# DMZ_DEVICE_NAME=br-dmz
# DMZ_INTERFACE=dmz

DMZ_DEVICE_NAME will be the DMZ’s network device name, and DMZ_INTERFACE will be the DMZ’s network interface name. The shown commands use sensible default values that follow OpenWrt’s conventions; however, network administrators are free to choose their own values.

Before DMZ configuration is complete, every time a network administrator reconnects to the router via SSH to resume the configuration process, they must rerun all these commands to set the variables again. This is because these commands set the variables only in the current shell.

Create the DMZ

The DMZ needs a new subnet, and a new subnet on OpenWrt needs a network device as well as a network interface.

Create a Device for the DMZ

  1. Add a new device configuration. The following command adds the configuration and prints its autogenerated ID. It is OK if the command’s actual output differs from the example output shown below.

    # DMZ_DEVICE=$(uci add network device); echo ${DMZ_DEVICE}
cfg070f15

  2. Set the device type to bridge device.

    # uci set network.${DMZ_DEVICE}.type=bridge

  3. Give the device a name. The following command uses the DMZ_DEVICE_NAME shell variable’s value as the name.

    # uci set network.${DMZ_DEVICE}.name=${DMZ_DEVICE_NAME}

  4. It is recommended that the “Bring up empty bridge” option be enabled for the device, so hosts that connect to the DMZ wirelessly will not encounter any trouble receiving an IPv6 address assignment from the DHCP server. As of OpenWrt 25.12.5, if this option is not enabled, and hosts connect to the DMZ through exclusively Wi-Fi, then after a router restart, these DMZ hosts may be assigned only an IPv4 address and no IPv6 addresses.

    # uci set network.${DMZ_DEVICE}.bridge_empty='1'

  5. Preview the pending changes.

    # uci changes
network.cfg070f15='device'
network.cfg070f15.type='bridge'
network.cfg070f15.name='br-dmz'
network.cfg070f15.bridge_empty='1'

  6. If the changes look good, apply them to create the device.

    # uci commit

Plan the Subnets

One decision that should be made now is the IPv6 prefix length of the DMZ subnet and that of the default LAN subnet (which is protected behind a firewall and is what hosts that should not be exposed to the Internet will connect to). Those subnets’ prefix lengths will depend on the length of the routing prefix allocated by the ISP.

To find the ISP-allocated routing prefix, run these commands. The first command prints the starting address in the prefix’s address block, and the second command prints the prefix length.

# ifstatus wan6 | jsonfilter -e '@["ipv6-prefix"][0].address'
2001:db8:85a3:1200::
# ifstatus wan6 | jsonfilter -e '@["ipv6-prefix"][0].mask'
56

In this example, the ISP has allocated an IPv6 address block with prefix 2001:db8:85a3:1200:: and prefix length /56. This is commonly written as 2001:db8:85a3:1200::/56.

In this scenario, a wide array of options including and not limited to these is available:

  • Divide the entire block evenly into two subnets; in this example, they would be 2001:db8:85a3:1200::/57 and 2001:db8:85a3:1280::/57. If there is no plan to create more subnets alongside the DMZ and the LAN in the future, then this option is suitable. However, if an extra subnet alongside might be created later, such as a subnet for a guest Wi-Fi access point, then this option does not work because it would have assigned the entire block to the two subnets, leaving no space for a new subnet alongside.

  • Use a /64 subnet for each of DMZ and LAN, such as 2001:db8:85a3:1200::/64 and 2001:db8:85a3:1201::/64. This maximizes the number of additional subnets that can be created alongside the DMZ and the LAN. However, because a /64 cannot be further divided into smaller subnets, no more nested subnets can be created within either the DMZ’s subnet or the LAN’s subnet. A ramification is, if another router will be connected behind the main router, then that router behind will not get its own IPv6 subnet and might have to use network address translation (NAT) for IPv6 networking, which defeats IPv6’s end-to-end principle.

  • Use a prefix length in between for both subnets, such as /60, so the subnets would be like 2001:db8:85a3:1200::/60 and 2001:db8:85a3:1210::/60. This allows both additional subnets alongside and nested subnets. The network administrator can choose an optimal prefix length to balance the two factors involved in this trade-off based on their needs.

  • Use different prefix lengths for different subnets. This is suitable when it is expected that a different number of nested subnets may be created within each subnet. For example, if the DMZ would no longer be further divided into nested subnets, but the LAN might be further divided into two nested subnets, then a /64 subnet could be used for the DMZ, and a /63 subnet for the LAN because it can be further divided into two /64 subnets. The resulting subnets could be 2001:db8:85a3:1200::/64 for the DMZ and 2001:db8:85a3:1202::/63 for the LAN.

An IPv6 subnet calculator can be helpful in evaluating the options and calculating the subnets’ prefixes.

Tip: The default OpenWrt configuration may let some ISPs allocate an IPv6 address block that is smaller than the largest block a customer can actually request. For example, the default configuration may only lead to allocation of a /64 while the ISP can actually allocate a block as large as a /56. With some other ISPs, the default configuration does not result in an IPv6 assignment at all. In any of these cases, try setting a different prefix length hint for the IPv6 address request. For example, to hint that a /48 is desired, run these commands:

# uci set network.wan6.reqprefix=48
# uci commit
# /etc/init.d/network reload

It is recommended that the largest block size (/48) be tried first because some ISPs have reportedly not allocated a larger block to a customer once it had already allocated a smaller block, regardless of the prefix length hint in new address requests.

When the hinted block size is larger than what the ISP is willing to allocate, the router might not get an IPv6 address block assigned at all. If this happens, try reducing the block size by increasing the prefix length (the longer the prefix, the smaller the block).

Meanwhile, to allow LAN hosts to access DMZ hosts using either IPv4 or IPv6 (which is called a dual-stack implementation), a new private IPv4 subnet can be created for the DMZ alongside an existing IPv4 subnet for the LAN. (This only enables the LAN to access the DMZ via IPv4; hosts on the Internet still cannot access the DMZ through an IPv4-only network.) The LAN’s IPv4 subnet can be queried using the following command:

# uci get network.lan.ipaddr
192.168.1.1/24

In this case, the DMZ’s IPv4 subnet can use the next available subnet that has the same prefix length, like 192.168.2.1/24. The network administrator is free to choose another subnet and/or prefix length as long as the choice does not clash with an existing subnet.

Create an Interface for the DMZ

  1. Add a new interface configuration with the protocol being static address and the device being the DMZ device just created.

    # uci set network.${DMZ_INTERFACE}=interface
# uci set network.${DMZ_INTERFACE}.proto=static
# uci set network.${DMZ_INTERFACE}.device=${DMZ_DEVICE_NAME}

  2. Set up the IPv6 subnets for the DMZ and the LAN. Two options need to be set for each subnet. ip6assign is straightforward: it is the subnet’s IPv6 prefix length.

    ip6hint, the other option, deserves more explanation. It will be used to determine the numerical value of the subnet’s prefix. Its value should be a hexadecimal number (IPv6 addresses are commonly written in hexadecimal too), and to determine the subnet’s prefix, the value will be numerically added to the most significant 64 bits of the ISP-allocated prefix (if the prefix is shorter than /64, then for the purpose of calculation, it will be extended to /64). Here are some examples:

    • If the ISP-allocated prefix is 2001:db8:85a3:1200::/56, ip6assign is 60, and ip6hint is 10, then the subnet’s prefix will be 2001:db8:85a3:1210::/60: the hint, 10, is numerically added to the ISP-allocated prefix to compute the subnet’s prefix, as in 2001:db8:85a3:1200 + 10 = 2001:db8:85a3:1210.

    • If the ISP-allocated prefix is 2001:db8:85a3:1200::/56, ip6assign is 60, and ip6hint is 0, then the subnet’s prefix will be 2001:db8:85a3:1200::/60: the two prefixes appear to have the same digits, but they are effectively different prefixes because they have different lengths.

    • If the ISP-allocated prefix is 2001:db8:85a3::/48, ip6assign is 49, and ip6hint is 0, then the subnet’s prefix will be 2001:db8:85a3::/49. Even though /49 means the fourth 16-bit group’s first bit is part of the prefix, the fourth group need not be written out in this abbreviated representation of the prefix. The unabbreviated representation is 2001:0db8:85a3:0000:0000:0000:0000:0000/49, but consecutive groups of zeros can be replaced with two colons (::) to shorten the representation.

    • If the ISP-allocated prefix is 2001:db8:85a3::/48, ip6assign is 49, and ip6hint is 8000, then the subnet’s prefix will be 2001:db8:85a3:8000::/49. First, only for the purpose of calculating the subnet’s prefix, the ISP-allocated prefix is extended to /64 to be regarded as 2001:db8:85a3:0000. Next, the hint is numerically added to the extended prefix as 2001:db8:85a3:0000 + 8000 = 2001:db8:85a3:8000.

      Note that this prefix’s representation is longer than that of 2001:db8:85a3::/49 despite that the two prefixes differ on only one bit. When one prefix’s representation is shorter than the other’s, it is recommended that the shorter one be assigned to the DMZ and the longer one to the LAN: hosts in the DMZ will be more frequently accessed, so shortening their IPv6 addresses’ representations helps make accessing them easier by reducing the time needed to type the addresses.

    • If the ISP-allocated prefix is 2001:db8:85a3:1248::/61, ip6assign is 62, and ip6hint is 4, then the subnet’s prefix will be 2001:db8:85a3:124c::/62 because 2001:db8:85a3:1248 + 4 = 2001:db8:85a3:124c.

    For example, the following commands create a /60 for the DMZ and a /60 for the LAN, and, if the ISP-allocated prefix is 2001:db8:85a3:1200::/56, then the two subnets’ prefixes will be 2001:db8:85a3:1200::/60 for the DMZ and 2001:db8:85a3:1210::/60 for the LAN due to the hints.

    # uci set network.${DMZ_INTERFACE}.ip6assign=60
# uci set network.${DMZ_INTERFACE}.ip6hint=0
# uci set network.lan.ip6assign=60
# uci set network.lan.ip6hint=10

    Here is another example, which creates a /49 for the DMZ and a /49 for the LAN; assuming the ISP-allocated prefix is 2001:db8:85a3::/48, the two subnets’ prefixes will be 2001:db8:85a3::/49 for the DMZ and 2001:db8:85a3:8000::/49 for the LAN, which implements the recommendation mentioned above.

    # uci set network.${DMZ_INTERFACE}.ip6assign=49
# uci set network.${DMZ_INTERFACE}.ip6hint=0
# uci set network.lan.ip6assign=49
# uci set network.lan.ip6hint=8000

    An IPv6 subnet calculator can be helpful in calculating the correct values of these options.

  3. Set up the DMZ’s IPv4 subnet. The following command sets it to 192.168.2.1/24.

    # uci add_list network.${DMZ_INTERFACE}.ipaddr=192.168.2.1/24

  4. Preview the pending changes.

    # uci changes
network.dmz='interface'
network.dmz.proto='static'
network.dmz.device='br-dmz'
network.dmz.ip6assign='60'
network.dmz.ip6hint='0'
network.lan.ip6assign='60'
network.lan.ip6hint='10'
network.dmz.ipaddr+='192.168.2.1/24'

  5. If the changes look good, apply them to create the interface.

    # uci commit
# /etc/init.d/network reload

Enable DHCP on the DMZ Interface

Once DHCP is enabled on the interface, OpenWrt will automatically assign a global IPv6 address and a private IPv4 address to each host connected to it. The following uci batch command, which sets multiple options at once, enables DHCP with OpenWrt’s default DHCP options.

# uci batch << EOF
set dhcp.${DMZ_INTERFACE}=dhcp
set dhcp.${DMZ_INTERFACE}.interface=${DMZ_INTERFACE}
set dhcp.${DMZ_INTERFACE}.start=100
set dhcp.${DMZ_INTERFACE}.limit=150
set dhcp.${DMZ_INTERFACE}.leasetime=12h
set dhcp.${DMZ_INTERFACE}.dhcpv4=server
set dhcp.${DMZ_INTERFACE}.dhcpv6=server
set dhcp.${DMZ_INTERFACE}.ra=server
add_list dhcp.${DMZ_INTERFACE}.ra_flags=managed-config
add_list dhcp.${DMZ_INTERFACE}.ra_flags=other-config
EOF

Preview the pending changes.

# uci changes
dhcp.dmz='dhcp'
dhcp.dmz.interface='dmz'
dhcp.dmz.start='100'
dhcp.dmz.limit='150'
dhcp.dmz.leasetime='12h'
dhcp.dmz.dhcpv4='server'
dhcp.dmz.dhcpv6='server'
dhcp.dmz.ra='server'
dhcp.dmz.ra_flags+='managed-config'
dhcp.dmz.ra_flags+='other-config'

If the changes look good, apply them to enable DHCP.

# uci commit
# /etc/init.d/dnsmasq reload
# /etc/init.d/odhcpd reload

Configure Firewall for the DMZ

The firewall on OpenWrt should be configured to allow hosts on the Internet to access hosts in the DMZ. It might also be useful to allow LAN hosts to access DMZ hosts, so, for example, a workstation in the LAN can upload backups to the home server in the DMZ. Meanwhile, because the DMZ is exposed to the Internet, security measures should be applied on it: for instance, the firewall should prevent the LAN to be accessed from the DMZ.

Create and Set Up a Zone for the DMZ

  1. Create a firewall zone for the DMZ, and specify its input, output, and forward settings. What each setting means is explained in OpenWrt documentation, and here is another explanation:

    Input
    Defines the action on packets from DMZ hosts to the router. Note that this also includes packets from DMZ to another zone (like LAN, and WAN for the Internet); after all, these packets need to first go from DMZ through the router before the router subsequently forwards them to the destination zone. “Accept” should be used here to allow DMZ hosts to initiate connections to the Internet, like for downloading software updates on the hosts.
    Output
    Defines the action on packets from the router to DMZ hosts. Note that this also includes packets from another zone to DMZ; these packets are first received by the router from another zone before the router subsequently forwards them to the destination host in the DMZ. “Accept” should be used here to allow hosts in other zones to connect to the DMZ hosts.
    Forward
    Defines the action on packets from an interface in the DMZ to another interface in the DMZ. With this tutorial’s configuration, the DMZ firewall zone will only have one interface, so this setting will not have any effect in practice. Any policy can be used here; the following commands use “reject” for the least privilege to achieve the best security possible.
    # DMZ_ZONE=$(uci add firewall zone); echo ${DMZ_ZONE}
cfg0edc81
# uci batch << EOF
set firewall.${DMZ_ZONE}.name=${DMZ_INTERFACE}
set firewall.${DMZ_ZONE}.input=ACCEPT
set firewall.${DMZ_ZONE}.output=ACCEPT
set firewall.${DMZ_ZONE}.forward=REJECT
add_list firewall.${DMZ_ZONE}.network=${DMZ_INTERFACE}
EOF

  2. Add a forwarding policy from WAN to DMZ to allow hosts on the Internet to access DMZ hosts.

    # FORWARDING_WAN_DMZ=$(uci add firewall forwarding); echo ${FORWARDING_WAN_DMZ}
cfg0fad58
# uci set firewall.${FORWARDING_WAN_DMZ}.src=wan
# uci set firewall.${FORWARDING_WAN_DMZ}.dest=${DMZ_INTERFACE}

  3. Add a forwarding policy from DMZ to WAN to allow DMZ hosts to access the Internet.

    # FORWARDING_DMZ_WAN=$(uci add firewall forwarding); echo ${FORWARDING_DMZ_WAN}
cfg10ad58
# uci set firewall.${FORWARDING_DMZ_WAN}.src=${DMZ_INTERFACE}
# uci set firewall.${FORWARDING_DMZ_WAN}.dest=wan

  4. Add a forwarding policy from LAN to DMZ to allow LAN hosts to access DMZ hosts.

    # FORWARDING_LAN_DMZ=$(uci add firewall forwarding); echo ${FORWARDING_LAN_DMZ}
cfg11ad58
# uci set firewall.${FORWARDING_LAN_DMZ}.src=lan
# uci set firewall.${FORWARDING_LAN_DMZ}.dest=${DMZ_INTERFACE}

  5. Preview the pending changes.

    # uci changes
firewall.cfg0edc81='zone'
firewall.cfg0edc81.name='dmz'
firewall.cfg0edc81.input='ACCEPT'
firewall.cfg0edc81.output='ACCEPT'
firewall.cfg0edc81.forward='REJECT'
firewall.cfg0edc81.network+='dmz'
firewall.cfg0fad58='forwarding'
firewall.cfg0fad58.src='wan'
firewall.cfg0fad58.dest='dmz'
firewall.cfg10ad58='forwarding'
firewall.cfg10ad58.src='dmz'
firewall.cfg10ad58.dest='wan'
firewall.cfg11ad58='forwarding'
firewall.cfg11ad58.src='lan'
firewall.cfg11ad58.dest='dmz'

  6. If the changes look good, apply them to create the zone.

    # uci commit

Because a forwarding policy from DMZ to LAN is not added, DMZ hosts cannot access LAN hosts. This is desirable for security reasons: should an attacker on the Internet compromise a DMZ host, the firewall would still block the attacker’s attempts to access the LAN from the DMZ host, granting the LAN maximum protection.

Deny Access to the Router from the DMZ

Without further firewall configuration, hosts in the DMZ can access the router itself, effectively exposing the router to the Internet (even just indirectly). This weakens network security because the router is a pivotal component in the network security and thus should not be accessible by anyone on the Internet. For example, if an attacker had compromised a DMZ host’s SSH server and could login to it via SSH, they could use that host to try accessing the router; there, they might utilize the same or a similar exploit to compromise the router’s SSH server, which would give them complete access to the router and thus the entire network.

Therefore, for best security, access to the router from the DMZ should be denied. Only a minimum set of the router’s ports that are absolutely necessary for DMZ hosts’ normal operation should be left open to the DMZ; these are the ports for DNS and DHCP.

  1. Add a traffic rule that allows DMZ hosts to access the router’s DNS server.

    # RULE_DNS=$(uci add firewall rule); echo ${RULE_DNS}
cfg1292bd
# uci batch << EOF
set firewall.${RULE_DNS}.name=Allow-DMZ-DNS
set firewall.${RULE_DNS}.src=${DMZ_INTERFACE}
set firewall.${RULE_DNS}.dest_port=53
set firewall.${RULE_DNS}.target=ACCEPT
EOF

  2. Add a traffic rule that allows DMZ hosts to access the router’s DHCPv4 server for IPv4 address assignments.

    # RULE_DHCP=$(uci add firewall rule); echo ${RULE_DHCP}
cfg1392bd
# uci batch << EOF
set firewall.${RULE_DHCP}.name=Allow-DMZ-DHCP
set firewall.${RULE_DHCP}.family=ipv4
add_list firewall.${RULE_DHCP}.proto=udp
set firewall.${RULE_DHCP}.src=${DMZ_INTERFACE}
set firewall.${RULE_DHCP}.dest_port=67
set firewall.${RULE_DHCP}.target=ACCEPT
EOF

  3. Add a traffic rule that allows DMZ hosts to access the router’s DHCPv6 server for IPv6 address assignments.

    # RULE_DHCPV6=$(uci add firewall rule); echo ${RULE_DHCPV6}
cfg1492bd
# uci batch << EOF
set firewall.${RULE_DHCPV6}.name=Allow-DMZ-DHCPv6
set firewall.${RULE_DHCPV6}.family=ipv6
add_list firewall.${RULE_DHCPV6}.src_ip=fc00::/6
add_list firewall.${RULE_DHCPV6}.dest_ip=fc00::/6
add_list firewall.${RULE_DHCPV6}.proto=udp
set firewall.${RULE_DHCPV6}.src=${DMZ_INTERFACE}
set firewall.${RULE_DHCPV6}.dest_port=547
set firewall.${RULE_DHCPV6}.target=ACCEPT
EOF

  4. Add a traffic rule that blocks all other traffic from DMZ hosts to the router.

    # RULE_DENY=$(uci add firewall rule); echo ${RULE_DENY}
cfg1592bd
# uci batch << EOF
set firewall.${RULE_DENY}.name=Deny-DMZ-To-Router
set firewall.${RULE_DENY}.src=${DMZ_INTERFACE}
set firewall.${RULE_DENY}.target=REJECT
EOF

  5. Preview the pending changes.

    # uci changes
firewall.cfg1292bd='rule'
firewall.cfg1292bd.name='Allow-DMZ-DNS'
firewall.cfg1292bd.src='dmz'
firewall.cfg1292bd.dest_port='53'
firewall.cfg1292bd.target='ACCEPT'
firewall.cfg1392bd='rule'
firewall.cfg1392bd.name='Allow-DMZ-DHCP'
firewall.cfg1392bd.family='ipv4'
firewall.cfg1392bd.proto+='udp'
firewall.cfg1392bd.src='dmz'
firewall.cfg1392bd.dest_port='67'
firewall.cfg1392bd.target='ACCEPT'
firewall.cfg1492bd='rule'
firewall.cfg1492bd.name='Allow-DMZ-DHCPv6'
firewall.cfg1492bd.family='ipv6'
firewall.cfg1492bd.src_ip+='fc00::/6'
firewall.cfg1492bd.dest_ip+='fc00::/6'
firewall.cfg1492bd.proto+='udp'
firewall.cfg1492bd.src='dmz'
firewall.cfg1492bd.dest_port='547'
firewall.cfg1492bd.target='ACCEPT'
firewall.cfg1592bd='rule'
firewall.cfg1592bd.name='Deny-DMZ-To-Router'
firewall.cfg1592bd.src='dmz'
firewall.cfg1592bd.target='REJECT'

  6. If the changes look good, apply them to create the traffic rules.

    # uci commit
# /etc/init.d/firewall reload

Attach Ethernet Ports and Wi-Fi Access Points to the DMZ

DMZ hosts and LAN hosts can all connect to the same router. To separate DMZ hosts from LAN hosts, any of the router’s Ethernet ports and/or additional Wi-Fi access points can be set up as the physical network interfaces that connect to the DMZ. Once set up, to let a host join the DMZ, the network administrator connects it to an Ethernet port or a new Wi-Fi access point associated with the DMZ; for hosts that should join the LAN, the network administrator connects it to a different Ethernet port or an existing Wi-Fi access point.

Ethernet Ports

By default, all of the router’s Ethernet ports are attached to the LAN. Any of these ports can be reattached to the DMZ, so when a host is connected to a reattached port, the host will join the DMZ, whereas if it is connected to any other port, it will join the LAN.

  1. Get the identifiers of the LAN and DMZ devices, and store them to shell variables for later use.

    # LAN_DEVICE=$(uci show network | grep "name='br-lan'" | cut -d. -f2); echo ${LAN_DEVICE}
@device[0]
# DMZ_DEVICE=$(uci show network | grep "name='${DMZ_DEVICE_NAME}'" | cut -d. -f2); echo ${DMZ_DEVICE}
@device[1]

  2. Get the names of all the Ethernet ports for LAN.

    # uci show network.${LAN_DEVICE}.ports
network.cfg030f15.ports='lan1' 'lan2' 'lan3' 'lan4'

    This example output shows that the router has 4 Ethernet ports for LAN, named lan1, lan2, lan3, and lan4 respectively.

  3. To reattach a port from the LAN to the DMZ, remove it from the LAN’s ports list, and add it to the DMZ’s ports list. For example, the following commands attach the lan1 port to the DMZ.

    # uci del_list network.${LAN_DEVICE}.ports=lan1
# uci add_list network.${DMZ_DEVICE}.ports=lan1

  4. Preview the pending changes.

    # uci changes
network.cfg030f15.ports-='lan1'
network.cfg070f15.ports+='lan1'

  5. If the changes look good, apply them to reattach the ports.

    # uci commit
# /etc/init.d/network reload

Wi-Fi Access Points

One or more new Wi-Fi access points can be created for the DMZ. If a host is connected to a new access point created for the DMZ, it will join the DMZ, whereas if it is connected to any existing access point, it will join the LAN.

  1. Get the names of the router’s Wi-Fi devices. A multi-band Wi-Fi router often has multiple Wi-Fi devices, one for each band.

    # uci show wireless | grep wifi-device
wireless.radio0=wifi-device
wireless.radio1=wifi-device

    This example output shows that the router has 2 Wi-Fi devices, named radio0 and radio1 respectively.

    Each Wi-Fi device’s band can be obtained by querying its band option using command uci get wireless.<device>.band:

    # uci get wireless.radio0.band
2g
# uci get wireless.radio1.band
5g

    This example output shows that radio0 is for the 2.4 GHz band, whereas radio1 is for the 5 GHz band.

  2. For each Wi-Fi device whose band is intended to be used with the DMZ, create an access point.

    1. For later convenience, set shell variables for the Wi-Fi device to be used for the new access point as well as the configuration name for the new access point. The following commands let device radio0 be used for the new access point and chooses a configuration name that follows OpenWrt’s conventions. Network administrators are free to choose their own values for the variables.

      # WIFI_DEVICE=radio0
# WIFI_IFACE=dmz_${WIFI_DEVICE}

    2. Create the Wi-Fi interface with the mode being access point and network being the DMZ’s interface.

      # uci set wireless.${WIFI_IFACE}=wifi-iface
# uci set wireless.${WIFI_IFACE}.device=${WIFI_DEVICE}
# uci set wireless.${WIFI_IFACE}.mode=ap
# uci set wireless.${WIFI_IFACE}.network=${DMZ_INTERFACE}

    3. Specify the access point’s credentials, including its SSID, encryption protocol, and password. The SSID should be different from that of every existing access point for the LAN.

      # uci set wireless.${WIFI_IFACE}.ssid=OpenWrt-DMZ
# uci set wireless.${WIFI_IFACE}.encryption=sae-mixed
# uci set wireless.${WIFI_IFACE}.key=password

    4. If additional bands are to be used with the DMZ, repeat the above steps for each band’s Wi-Fi device. The WIFI_DEVICE shell variable’s value should be changed to the new Wi-Fi device’s name.

      The access point’s credentials can be either the same as or different from those of previously-created access points for the DMZ. If they are the same, then DMZ hosts can connect to any band using the same credentials and automatically switch between bands.

      # WIFI_DEVICE=radio1
# WIFI_IFACE=dmz_${WIFI_DEVICE}
# uci set wireless.${WIFI_IFACE}=wifi-iface
# uci set wireless.${WIFI_IFACE}.device=${WIFI_DEVICE}
# uci set wireless.${WIFI_IFACE}.mode=ap
# uci set wireless.${WIFI_IFACE}.network=${DMZ_INTERFACE}

      # uci set wireless.${WIFI_IFACE}.ssid=OpenWrt-DMZ
# uci set wireless.${WIFI_IFACE}.encryption=sae-mixed
# uci set wireless.${WIFI_IFACE}.key=password

  3. Preview the pending changes.

    # uci changes
wireless.dmz_radio0='wifi-iface'
wireless.dmz_radio0.device='radio0'
wireless.dmz_radio0.mode='ap'
wireless.dmz_radio0.network='dmz'
wireless.dmz_radio0.ssid='OpenWrt-DMZ'
wireless.dmz_radio0.encryption='sae-mixed'
wireless.dmz_radio0.key='password'
wireless.dmz_radio1='wifi-iface'
wireless.dmz_radio1.device='radio1'
wireless.dmz_radio1.mode='ap'
wireless.dmz_radio1.network='dmz'
wireless.dmz_radio1.ssid='OpenWrt-DMZ'
wireless.dmz_radio1.encryption='sae-mixed'
wireless.dmz_radio1.key='password'

  4. If the changes look good, apply them to create the Wi-Fi access points.

    # uci commit
# wifi reload