UPnP and Automatic Port Mapping

UPnP and Automatic Port Mapping

RouterOS implements Universal Plug and Play Internet Gateway Device (UPnP IGD) versions 1 and 2. UPnP lets applications on the local network automatically request inbound port mappings through NAT — without requiring manual firewall or NAT rules. Common use cases include gaming consoles, P2P clients, and some VoIP applications.

Note

RouterOS implements both UPnP IGD and NAT-PMP (NAT Port Mapping Protocol). See NAT-PMP for configuration details.

Sub-menus

/ip upnp
/ip upnp interfaces

How UPnP Works

When a UPnP-capable application needs an inbound connection, it sends a UPnP request to the router. RouterOS creates a dynamic dstnat rule in the NAT table that forwards the requested external port to the requesting host. When the application releases the mapping (or its lease expires), the rule is removed.

Dynamic rules created by UPnP are marked with the D flag and appear at the end of the NAT table.

Common Use Cases

Gaming Consoles

Gaming consoles (PlayStation, Xbox, Nintendo Switch) rely on UPnP to dynamically open ports for multiplayer sessions. When UPnP is unavailable, consoles typically fall back to NAT Type 2 (moderate) or NAT Type 3 (strict), which can prevent peer-to-peer matchmaking or voice chat.

Enabling UPnP with the standard configuration is usually sufficient. The console will automatically request and release mappings as needed. To verify a console is connecting successfully, check the dynamic NAT rules created by UPnP:

/ip firewall nat print where dynamic

You should see dstnat entries appear during active gaming sessions. If not, confirm:

• The console’s LAN interface is set as type=internal
• UPnP is enabled on the device itself (usually under network settings)

Tip

Some consoles request ports in the range 1024-65535 for game traffic and use specific low ports (e.g., UDP 3074 for PlayStation Network, UDP 3544 for Xbox).

Media Servers (Plex, Emby, Jellyfin)

Media servers like Plex (TCP/UDP 32400) and Emby/Jellyfin (TCP 8096/8920) use UPnP to make themselves accessible for remote streaming. However, for these workloads, manual port forwarding is generally preferred — see UPnP vs Manual Port Forwarding.

If you choose UPnP for a media server, note that any LAN host can request port mappings — there is no built-in per-host restriction in RouterOS UPnP. For stable, predictable access, manual port forwarding is the better choice for media servers.

VoIP and Conferencing

SIP-based VoIP clients and some conferencing tools use UPnP to open RTP media ports dynamically. RouterOS includes NAT helpers (SIP ALG) which may handle SIP NAT traversal without UPnP. Test with the SIP helper first; enable UPnP only if the helper is insufficient for your deployment.

P2P File Sharing

BitTorrent clients and similar P2P applications use UPnP to improve connectivity. UPnP is appropriate here when all LAN users are trusted and you want to avoid managing per-client port forward rules.

Enabling UPnP

Step 1 — Enable the UPnP Service

/ip upnp
set enabled=yes

Global parameters:

Parameter	Description
enabled	yes to activate the UPnP service
allow-disable-external-interface	Allow UPnP clients to disable the external interface. Set to no in production.
show-dummy-rule	Show a placeholder NAT rule when no active mappings exist (improves compatibility with some IGD clients).

Recommended settings for most deployments:

/ip upnp
set enabled=yes allow-disable-external-interface=no show-dummy-rule=yes

Step 2 — Add Interfaces

UPnP requires at least one internal interface (LAN side) and one external interface (WAN side).

/ip upnp interfaces
add interface=bridge type=internal
add interface=ether1 type=external

Parameter	Value	Description
interface	interface name	Interface to participate in UPnP
type	internal / external	internal = LAN; external = WAN facing the internet

Only add trusted LAN interfaces as internal. Never add an untrusted or public-facing interface as internal.

Verify the configuration:

/ip upnp interfaces print

Example output:

Columns: INTERFACE, TYPE
# INTERFACE   TYPE
0 bridge  internal
1 ether1      external

Monitoring Active Mappings

RouterOS does not provide a dedicated UPnP mappings sub-menu. Active UPnP port mappings are visible only as dynamic NAT rules in the firewall table.

View Dynamic NAT Rules Created by UPnP

UPnP mappings appear as dynamic dstnat rules:

/ip firewall nat print where dynamic

Example output showing a UPnP-created mapping:

Flags: X - disabled, I - invalid, D - dynamic
 #    CHAIN    ACTION    PROTO  DST-PORT  TO-ADDRESSES    TO-PORTS
 0 D  dstnat   dst-nat   udp    45678     192.168.88.10   45678
 1 D  dstnat   dst-nat   tcp    55000     192.168.88.15   55000

Log UPnP-Forwarded Traffic

RouterOS does not provide a dedicated UPnP event log. To monitor traffic flowing through UPnP-opened ports, add firewall log rules:

# Log forwarded traffic through a specific UPnP-opened port
/ip firewall filter
add chain=forward protocol=udp dst-port=45678 action=log log-prefix="UPNP-FWD " place-before=0

Security Implications

UPnP is a convenience feature with real security trade-offs. Consider these risks before enabling it:

Risk	Detail
Any LAN host can open ports	Malware or a compromised device can punch holes through your firewall without admin interaction
No authentication	UPnP has no mechanism to verify that the requesting application is legitimate
Difficult to audit	Dynamic mappings come and go; without logging you may not know what ports are open at any given moment
Privileged ports	Any LAN application can request mappings on any port including ports below 1024

Mitigations:

• Enable UPnP only on interfaces where all connected devices are trusted
• Set allow-disable-external-interface=no
• Periodically review active mappings with /ip firewall nat print where dynamic
• Consider whether static port forwarding is a better fit for your use case

Alternatives to UPnP

Manual Port Forwarding

Manual dstnat rules are the most auditable and stable option. Rules are always visible, never change without admin action, and are appropriate for any service with a fixed address and port.

/ip firewall nat
add chain=dstnat in-interface=ether1 protocol=tcp dst-port=443 \
    action=dst-nat to-addresses=192.168.88.10 to-ports=443 \
    comment="static forward to internal web server"

Tip

Manual NAT rule changes take effect on new connections. Existing connections tracked in the connection table continue with the previous translation until they expire or are cleared with /ip firewall connection remove [find].

NAT-PMP (NAT Port Mapping Protocol)

RouterOS also implements NAT-PMP. NAT-PMP is simpler than UPnP (no SOAP, no discovery), and some clients (Apple Bonjour, certain game engines) prefer it. It provides the same automatic mapping capability with less protocol overhead.

Configure NAT-PMP under /ip nat-pmp:

/ip nat-pmp
set enabled=yes
/ip nat-pmp interfaces
add interface=bridge type=internal
add interface=ether1 type=external

If clients support both protocols, enabling both in parallel is safe — mappings from each protocol are managed independently.

Endpoint-Independent NAT (EIM)

For UDP-heavy applications like games and VoIP, configuring endpoint-independent mapping (EIM) can improve NAT traversal without requiring any dynamic mapping protocol. With EIM, UDP flows from the same internal source always use the same external port, allowing peers to reach each other through STUN-based hole-punching.

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether1 protocol=udp \
    comment="endpoint-independent NAT for UDP"

Note

RouterOS implements EIM for UDP by default in most NAT configurations. Verify your NAT behavior with an external STUN test if you experience NAT-related connectivity issues with specific games or VoIP clients.

Hairpin NAT (NAT Loopback)

When internal hosts need to reach a service by its public IP/domain while both are on the same LAN, hairpin NAT resolves the issue. This is a companion to manual port forwarding, not a replacement for UPnP.

/ip firewall nat
add chain=srcnat action=masquerade src-address=192.168.88.0/24 \
    dst-address=192.168.88.10 protocol=tcp dst-port=443 \
    comment="hairpin NAT for internal web server"

Comparison

	UPnP / NAT-PMP	Manual Port Forwarding
Setup	Automatic, application-driven	Admin-configured
Stability	Mappings are temporary and dynamic	Permanent until removed
Auditability	Harder — mappings change dynamically	Easier — rules are always visible
Security	Lower — any LAN host can request	Higher — admin controls what is open
Best for	Gaming consoles, P2P clients, dynamic apps	Servers, PBX, CCTV, stable services

Use UPnP or NAT-PMP when:

• Devices (gaming consoles, smart TVs) need port mappings but don’t support static configuration
• Applications dynamically negotiate ports (game clients, BitTorrent, some VoIP)
• All LAN devices are trusted and managed

Use manual port forwarding when:

• Running a self-hosted service (Plex, game server, SIP trunk, NVR)
• You need predictable, auditable, always-on rules
• Security requirements demand admin control over what ports are open

Troubleshooting

UPnP Mappings Not Appearing

If /ip firewall nat print where dynamic shows no dstnat entries after a device or application attempts to register:

1. Verify UPnP is enabled: /ip upnp print should show enabled: yes
2. Check interface assignments: Both an internal and external interface must be configured — verify with /ip upnp interfaces print
3. Check client-side UPnP: The device must have UPnP enabled in its own network settings (common on consoles, disabled by default on some PCs)
4. Firewall blocking discovery: UPnP discovery uses SSDP (UDP multicast to 239.255.255.250:1900). Ensure firewall rules on the internal interface are not blocking this traffic

Stale Mappings Persisting

If a device disconnects without releasing its UPnP mapping, the dynamic NAT rule remains until the lease expires. Dynamic NAT rules created by UPnP cannot be removed individually from the UPnP sub-menu — they will clear automatically when the lease expires or the router reboots.

Gaming Console Reporting Strict NAT

If a console reports NAT Type 3 (strict) despite UPnP being enabled:

• Confirm the console’s interface is configured as internal in /ip upnp interfaces
• Verify that /ip firewall nat print where dynamic shows dstnat entries during an active session — if not, the console’s UPnP requests are not reaching the router
• Verify no upstream NAT (double-NAT) is occurring between RouterOS and the internet — UPnP only affects the local router’s NAT table

UPnP Service Not Responding After Reboot

If UPnP stops working after RouterOS restarts, verify your configuration is saved (not just applied in-session). Check with /system script print or review /ip upnp print after reboot to confirm enabled=yes persists.

A typical home or small office deployment:

# Enable UPnP
/ip upnp
set enabled=yes allow-disable-external-interface=no show-dummy-rule=yes

# Define interfaces
/ip upnp interfaces
add interface=bridge type=internal
add interface=ether1 type=external

Verify after enabling:

/ip upnp interfaces print
/ip firewall nat print where dynamic