use public ip in the lan network
-
@vettalex said in use public ip in the lan network:
The need is to use the public IP and the port even when you are inside the company
Why? Just setup a host override to resolve what fqdn your public IP resolves to the internal IP.. Only the shittiest of crappy applications would hard code an IP be it public or private...
-
@emammadov thanks I solved it ... very kind
-
@johnpoz hello, even if I solved it, I wanted to deepen your solution. Can you give me more info so I can study it? thank you very much
-
So you have some fqdn, lets call it service.domain.tld the resolves on the public internet to say 1.2.3.4
You see traffic to port X on 1.2.3.4 and you forward it to 192.168.1.100..
This works great on the outside of your network.. For clients inside your network.
Just create a host override for service.domain.tld that points to 192.168.1.100
Now when clients inside your network, using your dns they would just resolve service.domain.tld to 192.168.1.100, no need for nat reflection.
-
@johnpoz In Finland it costs couple bucks to get private IP on Mobile Broadband in the super overflowed network which speed is around 5/5 Mbps with a huge ping. 3 bucks server with 1Gbps port and public IP is a cheap and much better choice with less ping. You cannot have a wired connection with public IP on a sparsely populated area here in Finland. Maybe not the best practice but as long as it works it serves the purpose. I have the same kind of issue with PfSense but I'd more likely set PfSense with a redirect to internal IP rather than use Hamachi.
-
Huh? What does that have to do with split dns?
-
@johnpoz Stop being a dick anyway.
-
Huh?
Your statement makes no sense in relation to the topic at hand.. It doesn't - so I'm a dick?
Maybe you posted in the wrong thread?
-
@johnpoz Might be that I misunderstood concept. I apologize if I did. I don't still find any reason why not to do that in "crappiest shit" applications. I just find your comment negative and my honest opinion is that it does not suit you
-
Hard coding an IP into an application is BAD... Its crappy design no matter how you look at it.
What happens when that IP changes.. Now the application has to be changed.. If the application used a fqdn to talk to whatever it is it needs to talk to.. All that has to happen is that fqdn points to whatever IP this services it running on.. It could change daily for that matter, etc.
The only scenario where you would have to use nat reflection is when the application in use is hard coded to that specific public IP.. Which would be a crappy designed application ;)
edit: Its possible the OP doesn't even have a fqdn that points to this public IP.. You can get a ddns fqdn that points to your public IP for "free".. so then just use the fqdn vs the IP, and again the need for nat reflection goes away.. If this is business use, you can get a domain for like $10 a year.
I stand by my opinion - if your using IP vs a fqdn to access pretty much anything its crappy design..
edit: Here you go - the person that uses hard coded IPs in an application vs fqdn.. Prob the same person that would design something like this
ie they didn't think it through = crappy design ;)
