• Published:

These are practical notes for a few OpenWrt plugins and related network functions, mainly covering ZeroTier intranet access, OpenClash or ShadowSocksR Plus+ node setup, and Wake-on-LAN troubleshooting.

ZeroTier for free intranet access

ZeroTier can be used with OpenWrt as a free intranet penetration solution. After installing and joining a ZeroTier network on OpenWrt, the key point is not only whether the node is online, but whether the network permissions and routes are set correctly.

NAT does not necessarily have to be enabled. If the goal is to allow ZeroTier dial-in clients to access resources on the router’s LAN, the ZeroTier management page needs a route pointing to the LAN subnet. Newly joined nodes are not allowed to access the private network by default, so they must be authorized in the ZeroTier management platform before they can communicate normally.

The general idea is:

  • Create or manage a network in the ZeroTier official management console.
  • Let OpenWrt join that network.
  • Approve the newly joined client or router node.
  • Add a route to the OpenWrt LAN subnet if remote ZeroTier clients need to access LAN devices.
  • NAT can be considered optional depending on the actual access mode.

OpenClash and ShadowSocksR Plus+

OpenClash can be installed as an OpenWrt plugin and then configured with proxy nodes. Some installation guides make the process look complicated, but for basic use it does not have to be that complex.

For ShadowSocksR Plus+, the setup is usually simpler: import nodes directly, or use a subscription address if available. After importing, check whether the node can actually connect. If it does not work, go to the status page and see whether any required service has not started.

One thing to pay attention to is that the SOCKS server seems to need to be started in some cases. If the status page shows that a service is not running, enable it in the settings and test again.

Wake-on-LAN not working: check ARP state

If Wake-on-LAN does not work on OpenWrt, the ARP state may be the reason. One workaround is to make the target machine’s ARP entry permanent.

The basic steps are:

  1. SSH into the OpenWrt backend.
  2. Check the ARP state:

ipneigh

  1. Change the server’s ARP information to permanent.
  2. Use the following command format:

ipneighchange192.168.x.xlladdrxx:xx:xx:xxxxxxxxnudpermanentdevbr-lan

Here, 192.168.x.x is the device IP address, and xx:xx:xx:xxxxxxxx is the MAC address.

  1. Add a scheduled task so the command runs every minute:

*****ipneighchange192.168.x.xlladdrxx:xx:xx:xxxxxxxxnudpermanentdevbr-lan

This can also be handled through the OpenWrt web interface instead of using commands, depending on the firmware and installed packages.

For sending the Wake-on-LAN packet manually, the command can be:

/usr/bin/etherwake -D -i "br-lan" "6c:62:6d:aa::"

It is also possible to trigger Wake-on-LAN through Siri or iOS Shortcuts by using SSH to run commands on OpenWrt, which is convenient for waking a home computer remotely.

One unresolved case: after replacing the router, Wake-on-LAN stopped working and the exact cause was not clear. In that situation, checking the ARP entry, interface name such as br-lan, MAC address, and whether the router forwards or sends the magic packet correctly would be the first places to look.

Related Posts