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
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
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.
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
A few issues I'm encountering while trying to test it right now:
Very limited options for the "ip" for a given rule:
I wanted to try defining some test rules, but VyOS doesn't let you set a CIDR network as the "IP" for a rule. This is most certainly a bug, as [the example `miniupnpd.conf`](https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/miniupnpd.conf) exclusively lists CIDRs, and the tab-completion help thing also suggests CIDRs are acceptable options:
[edit service upnp] vyos@vyos# set ru 10 ip ? Possible completions: <x.x.x.x> The IPv4 address to which this rule applies <x.x.x.x/x> The IPv4 to which this rule applies [edit service upnp] vyos@vyos# set ru 10 ip 172.23.217.64/26 Error: 172.23.217.64/26 is not a valid IPv4 host Error: 172.23.217.64/26 is not a valid IPv4 address Invalid value Value validation failed Set failed
Additionally, I feel like it would make sense to allow firewall address-groups and network-groups to be entered here, though those would almost certainly need to be expanded into individual rules under-the-hood. I haven't at all looked into the code for how firewall groups work, so I don't know how feasible this would be.
No default rules:
This is probably not such a bad thing from a security standpoint, but it means that out-of-the-box enabling UPNP does nothing except advertise your router's existence over UPNP. However, I couldn't really find any sort of examples of "sane" UPNP default rules either, though in my experience _most_ things that take advantage of advertised UPNP port forwarding ability tend to default to a port range roughly coinciding with the RTP port range (50000-60000) over either TCP or UDP. This is probably because UDP + stateful NAT with persistent ports is another way to open ports for direct connection, and RTP is generally not blocked on internet gateways.
My Xbox One game console is set to use "automatic" settings regarding both port selection and forwarding (via UPNP), and in doing so it chose port 54060 on my LAN (and has been distributed the IP address 172.23.217.102 from my DHCP server — which is not VyOS, by the way).
I have the following config set on my VyOS box in hopes that the Xbox would be able to forward its port successfully:
[edit service upnp]
vyos@vyos# show
friendly-name vyos.home.ibeep.com
listen 172.23.217.65
listen 192.168.12.1
nat-pmp
rule 10 {
action allow
external-port-range 1024-65535
internal-port-range 1024-65535
ip 172.23.217.102
}
wan-interface eth0However, if I ask the Xbox to "test NAT," it states that the NAT type is "Strict" and that its attempt to forward the port via UPNP was unsuccessful.