Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?)
-
@johnpoz said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
this is a horrible solution to what problem exactly?
Well, as horrible as it may be, it does solve an issue with miniupnp not wanting to play ball when WAN IP happens to be RFC1918...
@johnpoz said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
This sounds like a feature request, that shouldn't be too hard to do.. Just put in a feature request over at redmine for it. Since pfsense does this if your interface your monitoring is rfc1918. I would "guess" it should be easy enough for say a check box that says always use "the public IP address will be fetched and used instead." like it does now if the interface has rfc1918 on it.
I was about to make a request on Redmine but decided to check here first to see if there was a solution. I totally agree, a simple checkbox would be perfect.
But its bad practice to just randomly use some public IP range that is not used or allowed for you to be used by your isp.. While technically it will work - you can run into the issue of not being able to get to something really hosted on that public space - its bad practice to get into the habit of just using some random public IP space on your local network.
I don't disagree, but the risk of that IP being one that I would need to connect to, is one I may be willing to take. And just so we are clear, the setup is :
genuine public IP on LTE Router WAN -> fake public IP on LAN -> WAN2 on pfsense
And in my case this is on my failover WAN 2... I do believe I tested and saw it working when using a Shared IP (CGNAT range), so that could be an alternative, with less risk.But of course, I'd rather that miniupnp fixes the issue at their end...
-
@gblenn said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
but the risk of that IP being one that I would need to connect to, is one I may be willing to take
As long as you understand the issues that can happen, technically there is nothing preventing you from using whatever IP range you want on your own local networks.. You could run into issues with things thinking their public when they are not, since they don't see a rfc1918 address, etc.
Just wanted to make sure someone else reading this - didn't think this was a great idea.. You shouldn't use some public IP space on your local network. Unless its yours or been allocated to you from your isp that owns the space to use it, etc.
And keep in mind if sometime in the future you have some question where you talk about this connection, make sure you mention what your doing with your public IP range, etc. or can cause confusing in troubleshooting what is happening, etc.
Sometimes features that try and help the user from shooting themselves in the foot, or doing something that is non common practice needs to be circumvented sure.. Like UPnP not working if the interface is rfc1918, etc. Personally UPnP shouldn't even be a thing - its a horrible implementation of opening up ports - without any method of making sure that something actually has permission to open up said ports, etc.. I wouldn't use it.. Why can you not just manually open up the ports you need? Now your issues of rfc1918 space on the interface goes away.
-
@johnpoz Like I said, it would be way better if miniupnp simply accepted rfc 1918, like other UPnP implementations do. And an even better solution would be to use a router which support bridging, but mine doesn't, and most consumer models don't.
So, for a failover setup like mine, I'm thinking this could be an acceptable solution until miniupnp is changed...Wrt UPnP I agree about the risks it presents. But I do feel that the implementation in pfsense is pretty much as good as it can get. Especially the ACL is a nice addition.
For gaming, with multiple gamers in the house, UPnP is pretty much the only option available for "Open NAT"... -
@gblenn said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
Well, as horrible as it may be, it does solve an issue with miniupnp not wanting to play ball when WAN IP happens to be RFC1918...
Did you try to enable STUN?
-
@gblenn not trying to be augmentative.. But why can you not just manually open what ports you need?
UPnP is ok for grandma that doesn't know what an IP is in allowing for unsolicited traffic to her shiny new PS5..
And I get the info some of these game makers provide for ports and firewalls is horrible.. But can you not just run UPnP for a bit, figure out what ports its wanting open, and then just port forward them manually. if the info provide for what ports are needed is not clear enough?
Just curious.. I have never ran into anything that required to run UPnP.. Even when my boys were running console games - I just manually forwarded the ports they needed via a little investigation of what was required for feature xyz to work in the game, etc.
-
@johnpoz said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
Just curious.. I have never ran into anything that required to run UPnP.. Even when my boys were running console games - I just manually forwarded the ports they needed via a little investigation of what was required for feature xyz to work in the game, etc.
Yes well I have not seen any problems with console games, at least with my son being the only one playing on a PS4. And previously I was doing a bit of port forwarding as well. Might depend on what games are being played and in my case the problem games have been Inifinity Ward (Call of Duty) on PC.
The real challenge presented itself when we were three (myself included) PC's on the same game, online. The testing was tedious to say the least and I never managed to get all PC's up to Open NAT without the assistance of UPnP. I'm sure it's possible but I gave up.
What I have done to safeguard as much as possible is to use ACL to limit to the three PC's in question and to the port ranges in question...
-
@gblenn thanks - ok yeah multiple devices from the same network can get a bit crazy.. Thanks for quieting my curiosity cat..
-
@viragomann said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
@gblenn said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
Well, as horrible as it may be, it does solve an issue with miniupnp not wanting to play ball when WAN IP happens to be RFC1918...
Did you try to enable STUN?
I believe I have and if my memory serves me, I couldn't get it to work that way either...
-
@gblenn
According to some threads here, only the Google STUN works on pfSense.
But STUN just let the UPnP server know, what's your real public IP. You have also forward the necessary ports on your external router of course.
Best practice is to forward all to pfSense WAN or even set the pfSense WAN IP as DMZ or as exposed host if the router provides this option. -
@viragomann Yes, well I tested all servers, including Google. And perhaps I should test again to confirm it.
And yes, DMZ is a given here... Preferably bridge mode, but that's not always available. -
@gblenn google (with its port) is working. Every other server not with pfSense. Why, nobody can tell. ;)
-
@bob-dig said in Possible to force Dynamic DNS to use a check IP service (even if WAN IP is of a valid public IP range?):
@gblenn google (with its port) is working. Every other server not with pfSense. Why, nobody can tell. ;)
Thanks, good to know!
-
@gblenn I guess this thread should really continue over here...
https://forum.netgate.com/topic/178472/will-we-ever-get-upnp-to-work-behind-private-network-ipGoogle STUN server seems to be working and UPnP accepts requests to open ports. But it still isn't working. In fact it stops working and some games, like MW2 (2009) can't even connect to IW servers. Turning off UPnP gives me better results using manual port forwards...
However, the only way I have been able to get Open NAT across the board is faking a public WAN IP...
