UPnP behind private IP- working with a "hack"
-
...or trick. But what are the consequences?
For a long time, UPnP is not working behind a private IP, like if pfSense is (the exposed host) behind another router. And while other projects fixed it, here it is not.
But you can define an alternate WAN-address and I did this with a virtual IP...
And it looks like it is working!
But what is the consequence of this? Is this more dangerous or problematic then UPnP in general?
-
Maybe @JeGr has some thoughts?
-
@bob-dig said in UPnP behind private IP- working with a "hack":
For a long time, UPnP is not working behind a private IP, like if pfSense is (the exposed host) behind another router. And while other projects fixed it, here it is not.
In progress: https://redmine.pfsense.org/issues/10587
-
@viktor_g Thank you for letting me know.
Regarding my "hack", today I noticed that the dyndns.update cron-job failed for IPv4 with my cloudflare "clients", the RFC 2136 "client" had no problem with IPv4.
I then removed the virtual-IP, only had 6.6.6.6 in the UPnP & NAT-PMP Settings and dyndns.update is working again and UPnP is still working!So the only thing someone has to do is to put in some random public IP in Override WAN address in the UPnP & NAT-PMP Settings, to get it working behind a private IP?!
Is it so easy?
No need for a STUN Server and all this nonsense??
I really don't know, why (mini-)UPnP needs to know the public IP in the first place.
