Page MenuHomeVyOS Platform

Support UPNP protocol
Needs testing, NormalPublicFEATURE REQUEST

Description

UPNP protocol information:

Maybe we should consider supporting UPNP on Vyos

We can consider introducing miniupnpd_nftables

The implementation must rely on miniupnpd based on the nftables back end

There seems to be a miniupnpd_nftables available at the above Debian image address

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

jack9603301 triaged this task as Wishlist priority.Mar 22 2021, 8:33 AM
jack9603301 updated the task description. (Show Details)

There are genuine use cases, especially for small/home networks. But UPnP is a literal minefield of problems, and on top of that has had some serious security issues in the past due to fundamental design. If you were going to do this, I would want it off by default.

@Asteroza With Vyos, any service should be turned off by default unless it is explicitly configured by the user

jack9603301 changed the task status from Open to In progress.Mar 25 2021, 4:42 PM
jack9603301 raised the priority of this task from Wishlist to Normal.
jack9603301 moved this task from Need Triage to In Progress on the VyOS 1.4 Sagitta board.

UPnP is something I require (as a home user with multiple gaming systems), so I'm very happy to see this making progress in VyOS. I've been getting tired of the mess over in pfSense/OPNsense-land, wanting to try a Linux-based router, and I'm familiar with VyOS from past experience with "EdgeOS" on Ubiquiti hardware so it was on the top of my list, but held back by lack of UPnP in the past.

In short, thank you Jack (and anybody else who contributes to this)!

@ZPrime Although UPNP is not merged, you are welcome to test it if you wish, and if you have any questions, please let me know (you can also get in touch with me on Stack) so I can fix it before merging

@jack9603301 Unfortunately the only environment I have to test in is home, and my wife would probably kill me. ;) I also don't have a second "router PC" available right now which I would need before I can spin up VyOS and give it a try. I need to keep the other system untouched so I have something I can fall back on if I can't make VyOS work the way I want, and the hardware is old enough that if I virtualize my router OS, network performance suffers. I tried using ESXi with OPNsense and WAN throughput was down 200-300Mbps vs. what I can do on the bare metal.

I have a somewhat complicated home setup with dual-WAN and PBR that is forcing specific devices out certain WAN links, so the setup is a bit complicated to migrate from OPNsense to something new.

I've been looking at new router hardware though, so once I have that, I may have the ability to help test. I'll get in touch with you when/if I can help!

Thank you. If you have any questions, please keep in touch.

Unfortunately the only environment I have to test in is home, and my wife would probably kill me.

Oh, my God, please don't say that. I think it's a bit of an exaggeration.

Viacheslav changed the task status from In progress to Needs testing.Feb 4 2022, 9:11 AM
Viacheslav added a subscriber: Viacheslav.

@jack9603301 Could you test it, also create a pr for the documentation?

Ran some quick tests with current vyos installed in a VM and a client ubuntu server VM hooked up to it - since this is all internal stuff it is a double NAT scenario with the vyos external IP allocated out of 192.168.x.x space and using 10.100.100.0/24 internally for the client ubuntu VM.

Upnpd did not like that at all. It complained that the wan-ip address is not publicly routable and kept exiting and spamming the logs with:

Feb 04 14:10:14 vyos miniupnpd[5381]: Error: option ext_ip contains reserved / private address 192.168.13.71, not public routable

This particular issue appears to have been reported to the author of the miniupnpd project without any movement on reverting the change that started enforcing that check.

Regardless, I pushed ahead and configured upnp with a bogus wan-ip of 9.1.1.1. Using upnpc on the client to request a mapping from :3222 to :22 appears to work as I was able to connect to the ubuntu server client via the vyos external IP address.

I also tested it with a public STUN server instead of a bogus wan-ip and the upnpc client nonsensically reports that the mapping is <real external ip address>:3222 to :22. The end result is that the mapping is still created successfully.

As far as I can tell in my limited testing, requests to add/delete/list from the client via upnpc appear to work as intended.

Sorry I just saw it now, I'll test it. But because of limited conditions, I may test in the future, please forgive me

@Viacheslav @c-po Sorry I just saw it now, I'll test it. But because of limited conditions, I may test in the future, please forgive me

Should I make improvements to the remaining revisions in the PR?