Miniupnpd issues with lastest snapshot
-
Thank you very much :)
edit: A question, after testing with uTorrent and skype, the ports for skype remain open even after I closed the program, but the uTorrent ports get closed. Why is that?
-
I have been watching this thread intensely waiting for this issue to be resolved before trying out 2.1. Finally upgraded and it went smoothly and miniupnpd is working as well, many thanks to you Jimp.
-
Just updated
2.1-BETA0 (i386)
built on Tue Aug 7 04:03:30 EDT 2012
FreeBSD 8.3-RELEASE-p4And working great, started right up. Test with just win7 upnp interface of device, sees pfsense as freebsd router due to discovery. Allowed me to create forward to .209 address, but got denied when tried to a different address. Which is per my settings. So that is working as well
allow 1024-65535 192.168.1.209/32 1024-65535
Side question, is there anyway to secure upnp other than allow disallow rules? How can there not be a signature, key, password portion to the protocol - that says hey without this key you can not do anything. Something like the rndc key with bind.
-
That's a question worthy of its own thread - I'm not aware of anything there, it's just how the protocol was designed, but someone else may know.
-
Side question, is there anyway to secure upnp other than allow disallow rules? How can there not be a signature, key, password portion to the protocol - that says hey without this key you can not do anything. Something like the rndc key with bind.
I've never heard of anything like that either… poke around here http://miniupnp.free.fr/
edit: A question, after testing with uTorrent and skype, the ports for skype remain open even after I closed the program, but the uTorrent ports get closed. Why is that?
I want to say that is Skypes fault… The client tell miniupnpd the ports aren't needed anymore. I noticed it with UTorrent when using NAT-PMP... If I exit out the program, the ports down close, but if uncheck the option to use NAT-PMP; uTorrent tells miniupnp to tear down the session.
Only way to tell is to run a packet capture and see what is being sent/receive.
-
Yes it's up to the client to inform the server to close the ports, unless you clear them manually. I don't recall if miniupnpd will reap them after a while or if it leaves them indefinitely.
-
OK, thanks for explaining.
-
UPnP is a dumb protocol, there's no authentication because Microsoft designed it. :P
The access controls built in to miniupnp are actually above and beyond the spec, amazingly.
I'm just happy we have it, Xboxes (and to a lesser extent, PS3 and some PC games) are much happier having it in place!
I can't remember if miniupnp reaps old ports, but it would be nice to have that option. Most devices automatically re-add them every time they power up anyway. Alternatively, a "selective reap" option to kill just one entry would be handy too. I'm not sure if this would be something that pfSense devs would need to add, or if it would have to be an underlying feature in miniupnpd (at which point I should submit the request to that developer rather than redmine).
-
@bradenmcg:
I can't remember if miniupnp reaps old ports, but it would be nice to have that option.
At least this shows in my logs:
Aug 7 22:13:03 miniupnpd[6959]: remove port mapping 4504 UDP because it has expired Aug 7 22:13:03 miniupnpd[6959]: remove port mapping 4504 UDP because it has expired Aug 7 22:13:03 miniupnpd[6959]: remove port mapping 5354 UDP because it has expired Aug 7 22:13:03 miniupnpd[6959]: remove port mapping 5354 UDP because it has expired Aug 8 03:06:15 miniupnpd[6959]: remove port mapping 9635 TCP because it has expired Aug 8 03:06:15 miniupnpd[6959]: remove port mapping 9635 TCP because it has expired -
"there is no authentication because M$ designed it" - what an idiotic statement
Anyway - to the admins/devs, thank you! This seems to be working much better now and makes my life a lot easier.
