It's like putting your phone number on the wall of a bathroom stall. Maybe you won't get a lot of prank calls, maybe you will. It's a crapshoot.
The thing is, posting your public IP is like asking for a number of hackers to start probing your network for lapses in security. Not because you're a juicy target, but simply because you put the information out there. That's been bog standard for the internet for 20 years now.
Sure, IP addresses can be found through various ways, but having them out for everybody to see is just asking for more trouble than it is worth. You're making yourself a target and creating more work for yourself if you're constantly getting hacked because of it.
Like I don't even want to do anything malicious and I immediately started up a traceroute.
If the router supports hairpinning, the IP request can be resolved locally.
The domain name lookup would be a different issue and could potentially need to be resolved externally, but the router's DNS cache should be able to answer eventually.
Depends. If the zone responsible for whatever resolves to that IP is hosted locally - then DNS request would stay local.
If the service behind that IP is running locally - then all traffic would stay local. Network stack would be smart enough to not run circles to find itself.
Yeah, the router ought to know that public IP belongs to a device in its own network unless you're doing stuff like running your own router behind an ISP provided router and just forwarding ports instead of maintaining IP assignment / routing tables
The client will look up your domain at whatever DNS it uses. It will return your public IP.
Client will send a packet with that as destination. It will reach the router which goes 'I know! The call is coming from inside the house!' and sends it to the server without modification.
The server gets it and sends a response, but the response is addressed back to client's local IP.
Client gets the response, but that packet's origin (in the header) is server's local IP.
Client goes 'wtf, I didn't call you?!' And drops the packet, still waiting for a response with your public IP as its origin.
This can be solved with the router modifying the appropriate traffic's headers so that the headers match the expected, called NAT Loopback, or by using IPv6 global addresses.
It might also work running a local DNS server that returns your server's local IP for a given domain, but that might yield certificate errors, and won't work if devices ignore the DNS coming from DHCP.
I was using straight firewall rules for some years, but lost the template when the NAT Loopback checkbox started working (OpenWRT).
Couple good ideas already posted, but also you can update your hosts file with a ref to the internal IP, or if you are running your own DNS server, add an override for the domain
It's not internal, but there are other private address ranges beyond 192.168.0.0/16. 10.0.0.0/8 is another common one. Container platforms like to use 172.16.0.0/12.
Oh wow.... Didn't know this lol. I thought that OP would be using their private IP to access their homserver from home. Turns out I got completely confused....