fragtion · October 21, 2021 19:27
diff --git a/upnphack.txt b/upnphack.txt
 # RouterOS has a limitation where you can't run UPnP on the same interface for both internal and external (in order to DST-NAT from a LAN IP to another LAN IP on same interface/subnet)
 # This hack lets you workaround this limitation
 #
 # In the following example, bridge1 has IP 192.168.0.2 and is the gateway for other some clients with uPnP needs
 # The router's default gateway upstream, is another LAN device, eg 192.168.0.1
 #
 # How it works:
 # 1. First we disable uPnP daemon
 # 2. We define the intended internal uPnP interface as an external one for now
 # 3. Enable uPnP
 # 4. While uPnP is still running, change that interface to be internal so that there are now two internal interfaces
 # Result: uPnP will now be listening for client requests on bridge1 because it is now internal, however the uPnP daemon (which is still running) has no other external interface, so it will still create nat rules with bridge1 as the in-interface, which is what we wanted all along
 #
 # How to implement:
 # 1. Create an extra bridge which we can call dummy0. it doesn't need an IP or actually do anything, it's just a placeholder interface
 # 2. Create a scheduled task to run on startup with the following (adjust to your needs)
 #
 # Caveats:
 # The sequence needs to be executed after every reboot of the router
 # Since this is a 'hack', you do it at your own risk
 #

 /ip/upnp/set enabled=no
 # enough delay to make sure the system has initialized bridges etc and is ready for us
 :delay 10
 /ip/upnp/interfaces/set numbers=0 interface=bridge1 type=external forced-ip=192.168.0.2
 /ip/upnp/interfaces/set numbers=1 interface=dummy0 type=internal forced-ip=192.168.0.2
 /ip/upnp/set enabled=yes
 :delay 1
 /ip/upnp/interfaces/set numbers=0 interface=bridge1 type=internal forced-ip=192.168.0.2
	# RouterOS has a limitation where you can't run UPnP on the same interface for both internal and external (in order to DST-NAT from a LAN IP to another LAN IP on same interface/subnet)
	# This hack lets you workaround this limitation
	#
	# In the following example, bridge1 has IP 192.168.0.2 and is the gateway for other some clients with uPnP needs
	# The router's default gateway upstream, is another LAN device, eg 192.168.0.1
	#
	# How it works:
	# 1. First we disable uPnP daemon
	# 2. We define the intended internal uPnP interface as an external one for now
	# 3. Enable uPnP
	# 4. While uPnP is still running, change that interface to be internal so that there are now two internal interfaces
	# Result: uPnP will now be listening for client requests on bridge1 because it is now internal, however the uPnP daemon (which is still running) has no other external interface, so it will still create nat rules with bridge1 as the in-interface, which is what we wanted all along
	#
	# How to implement:
	# 1. Create an extra bridge which we can call dummy0. it doesn't need an IP or actually do anything, it's just a placeholder interface
	# 2. Create a scheduled task to run on startup with the following (adjust to your needs)
	#
	# Caveats:
	# The sequence needs to be executed after every reboot of the router
	# Since this is a 'hack', you do it at your own risk
	#

	/ip/upnp/set enabled=no
	# enough delay to make sure the system has initialized bridges etc and is ready for us
	:delay 10
	/ip/upnp/interfaces/set numbers=0 interface=bridge1 type=external forced-ip=192.168.0.2
	/ip/upnp/interfaces/set numbers=1 interface=dummy0 type=internal forced-ip=192.168.0.2
	/ip/upnp/set enabled=yes
	:delay 1
	/ip/upnp/interfaces/set numbers=0 interface=bridge1 type=internal forced-ip=192.168.0.2