
Following our MikroTik hAP ax³ initial setup guide, we are now ready to unlock the advanced capabilities of the router . Thanks to its powerful quad-core ARM64 CPU, this router is perfect for handling encrypted traffic and network segmentation without compromising speed.
We will implement four essential features to enhance your network's reach and security:
- Dynamic DNS: Ensuring reliable remote access even with a changing WAN IP.
- WireGuard VPN: Setting up a high-speed, modern tunnel for secure remote connections.
- DNS Cache Server: Accelerating local web browsing and improving query privacy.
- Guest Wireless LAN: Creating an isolated network for visitors to keep your main data secure.
This tutorial adapts proven configuration principles for my legacy Mikrotik hAP ac³ guide, ensuring you get the most out of your hAP ax³ hardware.

Figure 1 - Network Topology
1. MikroTik Dynamic DNS Configuration
1.1 Register New DNS Domain on Dynu.com
Dynu.com offers free registration of four three-level domains. Complete your Dynu.com registration and log in to your account. Navigate to Control Panel -> DDNS Services (Figure 2). Click the Add Dynamic DNS button. Choose the hostname and select the domain name from the list (Option 1). In my case, the hostname is a102 and the domain is mywire.org. Do not fill in option 2 - "Use your domain name". Click the Add button. Click the Save button in the next window to complete the process of registering your new DDNS domain.

Figure 2 - Dynu.com Control Panel
To enhance security, you can use IP Update Password instead of your account password with IP update clients. Navigate to Control Panel-> My Account-> Username/Password and enter the "New IP Update Password". This is the password used by DDNS client to authenticate its IP address updates sent to the DDNS server (dynu.com).

Figure 3 - Registered DNS Domains
1.2 Configure Dynamic DNS
MikroTik supports Dynamic DNS client configuration in form of the script run by scheduled task. Firstly, download the script dyn.com-script.txt.rsc from the Linux Debian into MikroTik router via SSH. Login to MikroTik via terminal and enter the command below:
> /tool fetch url="sftp://192.168.88.215/home/user123/dyn.com-script.txt.rsc" user=user123 password=pass_to_linux upload=no dst-path=configuration-file.txt.rsc
- 192.168.88.215 - IP address of Debian where script is stored
- user123/pass_to_linux - login credentials to login to OpenSSH server running on Linux
- dst-path=configuration-file.txt.rsc - name of the script in MikroTik filesystem
Note: If the download is successful, the text file configuration-file.txt.rsc appears in the output of the command /file print.
Now we will create a script called Dynu (Figure 4):
> /system script add name=Dynu dont-require-permissions=yes policy=reboot,read,write,policy,test,ftp,sensitive source=[/file get configuration-file.txt.rsc contents]
> /system script print brief

Figure 4 - Dynu Script Registered
This will evaluate the potion in the braces which produces the content of the file and use that content as the value for source. Now, we can run the script and check if the IP address is updated (Figure 5):
> /system script run Dynu

Figure 5 - Registered DNS Domains with New IP address 91.127.181.25
In case of any trouble, check the log file with the command below (Figure 6):
> log/print

Figure 6 - Successful DDNS Update
Once we have the script "registered" we can use the /system scheduler to invoke it:
> /system scheduler
add comment="Update Dynu DDNS" interval=5m name=ddns_sheduller on-event="/system script run Dynu\r\n" policy=reboot,read,write,policy,test,ftp,sensitive start-time=startup
If you are running the script through the Scheduler, check its status directly here:

Figure 7 - Checking Run-count and the last-started Timestamp after a Successful Execution
In the next-run column, you will see when the script is scheduled to execute next. If the timestamp shown is in the past and the script is not running, it is likely disabled or the interval is configured incorrectly.
2. Wireguard on MikroTik and Debian Linux
WireGuard is a modern VPN protocol. It is fast, secure, and easy to configure. It uses strong cryptography and minimal code. In this guide, we configure WireGuard in a road-warrior setup. This means a remote client (laptop or phone) securely connects to the home router from anywhere on the Internet.
2.1 Configure Wireguard on MikroTik
This command creates the WireGuard interface and automatically generates public and private keys.
> /interface wireguard add listen-port=13231 mtu=1420 name=wireguard1
Print the interface configuration and save the public key for the client configuration.
> /interface wireguard print

Figure 8 - Private and Public keys pair generated by MikroTik
Allocate an IP address to the wireguard interface. This will also automatically create a route for 192.168.90.0/24.
> /ip address add address=192.168.90.1/24 interface=wireguard1 network=192.168.90.0
Add a firewall rule to allow incoming traffic to the WireGuard service. This rule must be positioned above the generic drop rule (which discards all traffic not originating from the LAN). In our configuration, the drop rule is at index 4 (chain=input action=drop in-interface-list=!LAN). Therefore, the new WireGuard rule should be inserted at position 4, pushing the drop rule down to position 5.
> /ip firewall/filter/add chain=input action=accept protocol=udp dst-port=13231 comment="accept WireGuard" place-before=4
As shown in Figure 9, the WireGuard 'accept' rule is set at index 4. It is positioned specifically before the rule that drops all traffic not coming from the LAN.
> ip firewall/filter/print

Figure 9 - Firewall Filter Rules Showing the WireGuard 'accept' Rule Placed at Index 4
Add the WireGuard interface to the LAN list. This allows VPN clients to access LAN resources.
> interface/list/member/ add interface=wireguard1 list=LAN
2.2. Install and Configure WireGuard on Debian Client
Install WireGuard and Openresolv packages. The openresolv package manages the DNS configuration updates whenever the VPN tunnel is established or closed.
$ sudo apt install wireguard openresolv
Navigate to the directory where the WireGuard configuration files and the private/public key pairs will be stored:
$ sudo su
# cd /etc/wireguard
The command below generates a private key and writes it simultaneously to stdout and to the file client_priv.key. It then reads that a private key from stdin to derive the public key, which is saved to the client_pub.key file.
# wg genkey | tee client_priv.key | wg pubkey > client_pub.key
Store MikroTik public key on the Debian client for later use so it can identify the MikroTik router as a trusted peer.
# echo "X/Jb2pUFONAQ1jxypbGA9u/6Xf9uxCcT3xxPxHt5bTc=" > mikrotik_pub.key
Check if all the keys are stored in /etc/wireguard directory (Figure 10).
# cat client_priv.key client_pub.key mikrotik_pub.key

Figure 10 - Debian private / public keys and MikroTik public key in /etc/wireguard
Create and edit the client config file:
# vi /etc/wiguard/wg0.conf

Figure 11 - WireGuard Configuration File for Debian Linux
This configuration routes all traffic to the MikroTi (including internet traffic). In case you want to route only private IPs to the VPN change the AllowerIPS parameter as following:
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Set file permissions (keys and config) to root only (read/write):
$ sudo chmod 600 /etc/wireguard/*
2.3 Add the WireGuard peer on MikroTik
This command authorizes the Debian client on the router. The key is the public key used for WireGuard of Debian Linux:
> /interface wireguard peers
add allowed-address=192.168.90.2/32 interface=wireguard1 public-key="ocILMkovDGPEa8O+0uMbsWGSGPHX2ubxshldt+xsyiA="
2.4 Activate the VPN Connection on Debian Client
Start the WireGuard tunnel on the Debian client. The road-warrior client (Debian) is now securely connected to the MikroTik router and you should be able to ping LAN interface of MikroTik - 192.168.88.1.
# wg-quick up /etc/wireguard/wg0.conf
To check VPN connection on the Debian side, enter the command (Figure 12):
# wg show

Figure 12 - Checking VPN Connection on Debian Linux
- The handshake 40 seconds ago confirms the connection is alive.
- The received 1.28 GiB of data confirms that the tunnel is not just established but actively transmitting high volumes of traffic.
- The IP address 95.103.245.237 is a public address of Mikrotik along with the port 13231 Debian is connected to.
Let's verify the VPN tunnel status from the MikroTik side to ensure the handshake was successful and data is being exchanged.
> /interface wireguard peers print detail

Figure 13 - Checking VPN Connection on MikroTik
- The last-handshake 14s confirms the router has recently authenticated the peer.
- The router’s "transmitted" (TX) data 1337.7 MiB corresponds to the client’s "received" 1.28 GiB data, confirming bi-directional flow.
- The allowed-address=192.168.90.2/32 ensures that only this specific internal IP is permitted for this peer.
To disconnect VPN tunnle enter the command:
# wg-quick down /etc/wireguard/wg0.conf
2.5 Create WireGurad Service on Client
To ensure the WireGuard tunnel starts automatically during the Debian boot process, first enable the service using systemctl:
# systemctl enable wg-quick@wg0
Afterward, you can manually start the service and verify its operational status as shown in Figure 14:
# systemctl start wg-quick@wg0
# systemctl status wg-quick@wg0

Figure 14 - Checking WireGuard Service Status on Debian
The next time Debian boots up, the VPN tunnel will start automatically.
3. DNS Cache Server
The DNS cache is utilized to reduce the number of external DNS queries and to speed up DNS resolution times. In our setup, the DNS cache is set to IP address 192.168.88.1 which is specified in the DHCP server configuration.
Since the external DNS server IPs are automatically provided by the ISP's DHCP server, there is no need to manually specify them. The only required step is to enable remote DNS requests, as shown in Figure 15:
> /ip dns set allow-remote-requests=yes

Figure 15 - DNS Cache Server Configuration
4. Guest Wireless Network
A Guest WiFi provides an isolated wireless connection for visitors or IoT devices. It allows access to the Internet while strictly preventing any communication with your local network resources (LAN). This segmentation is essential for preserving the integrity and privacy of your primary data.
This section describes how to create an isolated Guest Wi-Fi network using virtual APs, a separate bridge, DHCP, and firewall rules.
4.1 Create Guest Wi-Fi Interfaces (wifi3, wifi4)
We create two virtual APs (VAPs). Each VAP inherits radio settings from its master interface.
- wifi3: Guest SSID on 5 GHz (master: wifi1)
- wifi4: Guest SSID on 2.4 GHz (master: wifi2)
> /interface/wifi add name=wifi3 master-interface=wifi1 configuration.ssid="internethome2-guest-5Ghz" security.passphrase="changeme"
> /interface/wifi add name=wifi4 master-interface=wifi2 configuration.ssid="internethome2-guest-2.4Ghz" security.passphrase="changeme"
Enable both interfaces:
> /interface/wifi/enable wifi3,wifi4
4.2 Create a Dedicated Guest Bridge and Assign an IP Address to the Guest Bridge
To isolate guest traffic, we use a separate bridge. Create the bridge with the command:
> /interface/bridge add name=bridge-guest
Add guest Wi-Fi interfaces to the bridge:
> /interface bridge port add bridge=bridge-guest interface=wifi3
> /interface bridge port add bridge=bridge-guest interface=wifi4
The guest network will use subnet 192.168.89.0/24.
> ip address add address=192.168.89.1/24 interface=bridge-guest network=192.168.89.0
4.3 Configure DHCP for the Guest Network
Create a DHCP pool and server for guest clients.
> /ip pool add name=pool-guest ranges=192.168.89.10-192.168.89.254
> /ip dhcp-server add name=dhcp-guest address-pool=pool-guest interface=bridge-guest disabled=no
> /ip dhcp-server network add address=192.168.89.0/24 gateway=192.168.89.1 dns-server=192.168.89.1
4.4 Configure Firewall - Drop Traffic from Guests to Main LAN and Accept DNS from Guests
Let's have a look at the firewal_rules. Currently, a firewall has two significant flaws that we need to address:
a) Security risk: Guests in the guest subnet (192.168.89.0/24) can access a primary LAN (192.168.88.0/24). This is because there is no forwarding rule to drop this traffic. This is unacceptable for a secure network as guests should only have access to the Internet.
b) DNS usability: Guests cannot browse the Internet because MikroTik drops their DNS queries. Since bridge-guest is not part of the trusted LAN list, Rule 5 (Input Chain) blocks all requests to the router's DNS service (Figure 16).

Figure 16 - LAN List with Bridge and WireGuard Interfaces as Members
To allow DNS queries (destination UDP port 53) from the guest interface to the router's bridge-guest interface, enter the command below:
> /ip firewall filter add chain=input action=accept protocol=udp in-interface=bridge-guest dst-port=53 comment="Allow Guest DNS" place-before=5
Note that rule is placed before the "drop all not coming from LAN" rule (Rule 5) (firewal_rules). If placed after, the DNS request is dropped before it can be accepted.
To block all traffic from the guest network to the primary LAN (192.168.88.9/24) and WireGuard (192.168.90.0/24), enter the following rule:
> /ip firewall filter add chain=forward action=drop in-interface=bridge-guest out-interface-list=LAN comment="Block access from Guest WLAN to LAN" place-before=10
We have placed the rule early (before Rule 10) to drop unauthorized packets immediately.
> ip firewall/filter/print
Figure 17 - Complete Firewall Rules
Conclusion
This guide covered the complete advanced configuration of the MikroTik hAP ax³. The final setup provides a secure and well-structured network design with separated LAN, Guest WLAN, and VPN access.
The router now supports Dynamic DNS for remote reachability, WireGuard for secure road-warrior VPN access, and DNS caching for faster local resolution. Guest devices operate on an isolated subnet, while firewall rules enforce strict traffic separation without impacting performance.