miniupnpd-nftables: STUN does not work because it does not open local ports properly
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 4.6k
- Forks
- 4k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 134
Description
Maintainer: @stintel @stangri @jow-
Environment: OpenWrt SNAPSHOT, r23763-46ed38adeb, mt7622
Description:
My ISP provides CGNAT IP address with fullcone (including TCP). However, when I try to set up STUN for miniupnpd, it failed to detect the fullcone type.
I think OpenWrt's firewall blocked the incoming STUN packets, because the same had happened when I tested the NAT type on Windows: it does not detect the fullcone type unless I disabled the firewall or add the detection tool to the firewall allow list.
I set option log_output '1' in upnpd config to enable verbose logs, then I noticed it tried to add firewall rules to upnp_forward.
daemon.info miniupnpd[8842]: STUN: Performing with host=stun.miwifi.com and port=3478 ...
daemon.debug miniupnpd[8842]: resolve_stun_host: stun.miwifi.com:3478 => x.x.x.x:3478
daemon.info miniupnpd[8842]: perform_stun: local ports 40225 33021 33632 52450
daemon.debug miniupnpd[8842]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[8842]: wait_for_stun_responses: received responses: 1
daemon.debug miniupnpd[8842]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[8842]: wait_for_stun_responses: select(): no more responses
daemon.debug miniupnpd[8842]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[8842]: wait_for_stun_responses: select(): no more responses
daemon.debug miniupnpd[8842]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[8842]: wait_for_stun_responses: select(): no more responses
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0ad90, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0af80, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0b17c, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0b378, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0ad90, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0af80, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0b17c, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0ad90, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0af80, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: table_cb(0x7fdaf0ad90, 0x7fdaf0bdf0) fw4 upnp_forward 2
daemon.debug miniupnpd[8842]: parse_stun_response: Type 0x0101, Length 48, Magic Cookie 2112a442
daemon.debug miniupnpd[8842]: parse_stun_response: MAPPED-ADDRESS x.x.x.x:62527
daemon.debug miniupnpd[8842]: parse_stun_response: RESPONSE-ORIGIN x.x.x.x:3478
daemon.debug miniupnpd[8842]: parse_stun_response: OTHER-ADDRESS x.x.x.x:3479
daemon.debug miniupnpd[8842]: parse_stun_response: XOR-MAPPED-ADDRESS x.x.x.x:62527
daemon.notice miniupnpd[8842]: perform_stun: 1 response out of 4 received
daemon.warn miniupnpd[8842]: STUN: ext interface wan with private IP address 192.168.1.101 is now behind restrictive or symmetric NAT with public IP address 101.86.230.102 which does not support port forwarding
daemon.warn miniupnpd[8842]: NAT on upstream router blocks incoming connections set by miniupnpd
daemon.warn miniupnpd[8842]: Turn off NAT on upstream router or change it to full-cone NAT 1:1 type
When miniupnpd is restarting, 4 firewall rules are added to upnp_forward chain:
root@OpenWrt:~# nft list chain inet fw4 upnp_forward
table inet fw4 {
chain upnp_forward {
iif "wan" th dport 50826 @nh,128,32 0xc0a80165 @nh,72,8 0x11 accept
iif "wan" th dport 45510 @nh,128,32 0xc0a80165 @nh,72,8 0x11 accept
iif "wan" th dport 50952 @nh,128,32 0xc0a80165 @nh,72,8 0x11 accept
iif "wan" th dport 55067 @nh,128,32 0xc0a80165 @nh,72,8 0x11 accept
}
}
As the name suggests, this chain is only used in forward chain, not input chain, so miniupnpd does not open the ports properly.
If I manually call upnp_forward in input, everything works:
nft insert rule inet fw4 input jump upnp_forward
daemon.info miniupnpd[9316]: STUN: Performing with host=stun.miwifi.com and port=3478 ...
daemon.debug miniupnpd[9316]: resolve_stun_host: stun.miwifi.com:3478 => x.x.x.x:3478
daemon.info miniupnpd[9316]: perform_stun: local ports 34390 44751 37992 52958
daemon.debug miniupnpd[9316]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[9316]: wait_for_stun_responses: received responses: 1
daemon.debug miniupnpd[9316]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[9316]: wait_for_stun_responses: received responses: 2
daemon.debug miniupnpd[9316]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[9316]: wait_for_stun_responses: received responses: 3
daemon.debug miniupnpd[9316]: wait_for_stun_responses: waiting 3 secs and 0 usecs
daemon.debug miniupnpd[9316]: wait_for_stun_responses: received responses: 4
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0a40, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0c30, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0e2c, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba1028, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0a40, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0c30, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0e2c, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0a40, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0c30, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: table_cb(0x7fc8ba0a40, 0x7fc8ba1aa0) fw4 upnp_forward 2
daemon.debug miniupnpd[9316]: parse_stun_response: Type 0x0101, Length 48, Magic Cookie 2112a442
daemon.debug miniupnpd[9316]: parse_stun_response: MAPPED-ADDRESS x.x.x.x:63246
daemon.debug miniupnpd[9316]: parse_stun_response: RESPONSE-ORIGIN x.x.x.x:3478
daemon.debug miniupnpd[9316]: parse_stun_response: OTHER-ADDRESS x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: XOR-MAPPED-ADDRESS x.x.x.x:63246
daemon.debug miniupnpd[9316]: parse_stun_response: Type 0x0101, Length 48, Magic Cookie 2112a442
daemon.debug miniupnpd[9316]: parse_stun_response: MAPPED-ADDRESS x.x.x.x:63247
daemon.debug miniupnpd[9316]: parse_stun_response: RESPONSE-ORIGIN x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: OTHER-ADDRESS x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: XOR-MAPPED-ADDRESS x.x.x.x:63247
daemon.debug miniupnpd[9316]: parse_stun_response: Type 0x0101, Length 48, Magic Cookie 2112a442
daemon.debug miniupnpd[9316]: parse_stun_response: MAPPED-ADDRESS x.x.x.x:63248
daemon.debug miniupnpd[9316]: parse_stun_response: RESPONSE-ORIGIN x.x.x.x:3478
daemon.debug miniupnpd[9316]: parse_stun_response: OTHER-ADDRESS x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: XOR-MAPPED-ADDRESS x.x.x.x:63248
daemon.debug miniupnpd[9316]: parse_stun_response: Type 0x0101, Length 48, Magic Cookie 2112a442
daemon.debug miniupnpd[9316]: parse_stun_response: MAPPED-ADDRESS x.x.x.x:63249
daemon.debug miniupnpd[9316]: parse_stun_response: RESPONSE-ORIGIN x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: OTHER-ADDRESS x.x.x.x:3479
daemon.debug miniupnpd[9316]: parse_stun_response: XOR-MAPPED-ADDRESS x.x.x.x:63249
daemon.info miniupnpd[9316]: STUN: ext interface wan with IP address 192.168.1.101 is now behind unrestricted full-cone NAT 1:1 with public IP address x.x.x.x and firewall does not block incoming connections set by miniunnpd
daemon.info miniupnpd[9316]: Port forwarding is now enabled
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the miniupnpd firewall integration and the fw4 upnp_forward and input chains described in the report. Reproduce the STUN check, inspect the generated nft rules, and verify that incoming packets reach the local STUN ports without manually inserting an input-chain jump.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100