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 does not implement NAT-PMP (NAT Port Mapping Protocol). Only UPnP IGD is supported.

Sub-menus

/ip upnp
/ip upnp interfaces
/ip upnp permissions
/ip upnp mappings

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:

/ip upnp mappings print

You should see 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)
• No permissions rule is blocking the port range the console is requesting

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). Ensure your permissions allow the UDP high-port range at minimum.

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, ensure the server’s IP address is included in a permissions internal-address filter to prevent other hosts from hijacking those ports:

/ip upnp permissions
add action=allow interface=ether1 protocol=tcp dst-port=32400 internal-address=192.168.88.10 comment="Plex server"
add action=deny  interface=ether1 protocol=tcp dst-port=32400 comment="block others from Plex port"

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-lan 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:

Flags: X - disabled
 #   INTERFACE   TYPE
 0   bridge-lan  internal
 1   ether1      external

Restricting Mappings with Permissions

By default UPnP grants any internal host the ability to open any port on the external interface. Use permissions to restrict which protocols, ports, and source addresses are allowed.

/ip upnp permissions
# Allow TCP ports 1024-65535
add action=allow interface=ether1 protocol=tcp dst-port=1024-65535 comment="allow high TCP"

# Allow UDP ports 1024-65535
add action=allow interface=ether1 protocol=udp dst-port=1024-65535 comment="allow high UDP"

# Deny well-known ports
add action=deny interface=ether1 protocol=tcp dst-port=0-1023 comment="block privileged TCP"
add action=deny interface=ether1 protocol=udp dst-port=0-1023 comment="block privileged UDP"

Tip

Place deny rules after more specific allow rules. Rules are evaluated in order; the first match wins. A final deny-all is good practice if you want to block unmapped ports explicitly.

Parameters for each permission entry:

Parameter	Description
action	allow or deny
interface	External interface this rule applies to
protocol	tcp, udp, or both
dst-port	Port or port range (e.g., 1024-65535)
internal-address	Restrict by LAN source IP (optional)

Monitoring Active Mappings

View Active UPnP Mappings

/ip upnp mappings print

This shows the current set of active UPnP-requested port mappings including protocol, external port, internal address, and internal port.

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

Monitor Interface Status

/ip upnp interfaces monitor [find]

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	Without permissions restrictions, applications could map ports below 1024

Mitigations:

• Enable UPnP only on interfaces where all connected devices are trusted
• Use permissions to restrict mappable port ranges (block 0-1023 at minimum)
• Set allow-disable-external-interface=no
• Periodically review active mappings with /ip upnp mappings print
• 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 supports NAT-PMP in addition to UPnP. 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-lan 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 upnp mappings print shows no 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
3. Check permissions: A deny rule may be blocking the requested port — print permissions with /ip upnp permissions print and confirm the port range is allowed
4. Check client-side UPnP: The device must have UPnP enabled in its own network settings (common on consoles, disabled by default on some PCs)
5. 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. To remove stale entries manually:

/ip upnp mappings remove [find]

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
• Check that UDP traffic is allowed in the permissions rules
• Some consoles require specific ports (e.g., UDP 3074 for PSN). Add an explicit allow rule for those ports before any deny rules
• 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 with UPnP restricted to high ports:

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

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

# Restrict mappable ports
/ip upnp permissions
add action=allow interface=ether1 protocol=tcp dst-port=1024-65535
add action=allow interface=ether1 protocol=udp dst-port=1024-65535
add action=deny  interface=ether1 protocol=tcp dst-port=0-1023
add action=deny  interface=ether1 protocol=udp dst-port=0-1023

Verify after enabling:

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