UPnP Rules are not reapplied when firewall rules are reloaded

[andrewmackrodt]

Expected Behavior

When UPnP rules have been created, performing an operation which causes firewall rules to reload, e.g. modifying an OMR-Bypass rule should preserve UPnP rules.

Current Behavior

The local router preserves the UPnP rules (e.g. when inspected with PortMapper (java application) or miniupnpc (python library)), however rules have disappeared from luci and are no longer mapped on the VPS.

Possible Solution

Get the state of UPnP rules before reloading the VPS firewall and restore them in luci/VPS after rules are applied.

Steps to Reproduce the Problem

1. Map a port(s) via UPnP
2. Modify/add/remove any OMR-Bypass rule
3. Save and Apply

Context (Environment)

Preserving the UPnP rules is desired if making an OMR-Bypass change to an unrelated device. For example, a console has mapped UPnP rules and a user is hosting a game session. During this session, the network administrator modifies a OMR-Bypass rule to add a DNS exclusion.

Specifications

• OpenMPTCProuter version: v0.60-6.1
• OpenMPTCProuter VPS version: v0.60-6.1
• OpenMPTCProuter VPS provider: multiple
• OpenMPTCProuter platform: RPI5

[Ysurac]

Can you give me, via SSH on the router, the result of uci show firewall when it's available in the interface and when it's not ?

[andrewmackrodt]

Here is a diff of before and after.txt, where before has a working UPnP rule for port 8080 and after is when I disabled 22/tcp rule in OMR-Bypass. (I've redacted a MAC address under firewall.omr_dst_bypass_wan2_mac_4.src_mac, this device isn't part of this test).

--- before.txt
+++ after.txt
@@ -636,7 +636,7 @@
 firewall.omr_dst_bypass_all_4.match='dest_ip'
 firewall.omr_dst_bypass_all_4.family='ipv4'
 firewall.omr_dst_bypass_all_4.enabled='1'
-firewall.omr_dst_bypass_all_4.entry='199.232.192.193' '199.232.196.193' '104.18.29.7' '104.18.28.7' '217.160.0.152' '173.222.14.62' '23.53.173.12' '90.216.128.5'
+firewall.omr_dst_bypass_all_4.entry='199.232.196.193' '199.232.192.193' '104.18.28.7' '104.18.29.7' '217.160.0.152' '173.222.14.62' '23.53.173.12' '90.216.128.5'
 firewall.omr_dst_bypass_all_6=ipset
 firewall.omr_dst_bypass_all_6.name='omr_dst_bypass_all_6'
 firewall.omr_dst_bypass_all_6.match='dest_ip'
@@ -695,9 +695,8 @@
 firewall.omr_dst_bypass_all_dstport_tcp_4.src='lan'
 firewall.omr_dst_bypass_all_dstport_tcp_4.dest='*'
 firewall.omr_dst_bypass_all_dstport_tcp_4.target='MARK'
-firewall.omr_dst_bypass_all_dstport_tcp_4.enabled='1'
+firewall.omr_dst_bypass_all_dstport_tcp_4.enabled='0'
 firewall.omr_dst_bypass_all_dstport_tcp_4.set_xmark='0x4539'
-firewall.omr_dst_bypass_all_dstport_tcp_4.dest_port='22'
 firewall.omr_dst_bypass_all_dstport_udp_4=rule
 firewall.omr_dst_bypass_all_dstport_udp_4.name='omr_dst_bypass_all_dstport'
 firewall.omr_dst_bypass_all_dstport_udp_4.src='lan'

[andrewmackrodt]

I've just realised I have likely misreported the error here, sorry! It may be contained to the router only and the VPS is ok. I did the same before and after test but dumped the output of nft list ruleset and noticed the upnp entries are missing.

 	chain upnp_forward {
-		iif "tun0" th dport 8080 @nh,128,32 0xc0a864b0 @nh,72,8 0x6 accept
 	}
 
 	chain upnp_prerouting {
-		iif "tun0" @nh,72,8 0x6 th dport 8080 dnat ip to 192.168.100.176:8080
 	}

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days

[andrewmackrodt]

Commenting to keep open; I need to test this with v0.61-rc2 but I observed similar behaviour with v0.61-rc that rules are lost, although the router appeared to have the rule removed there, so some applications would at least be able to re-create the rule which then gets mapped correctly on the VPS side - which is positive.

[Ysurac]

What is the result if, via SSH on the router, you do a /etc/init.d/minuupnpd restart when it's not working ? Possible that it's not relaunched when firewall reload...

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days