Strange behaviour

Hello dear people of L1
I’m having few issues regarding hosting own stuff.
Lately I’ve finally convinced my ISP to open all ports for me so I can use my namecheapdomain for acessing my stuff remotley.
Therefore few issues rised.
1st. I can’t access my domain from local network
2nd I cant bypass my router’s configuration page (ex. 192.168.1.1), as I only get my router’s ip with ddns, so on port 80 and 443 I get my router page, therefore I’ve managed to guess that other ports are accessable, and using them works.

Any clues how to solve any of issues? Thanks in advance.

Basic networking: you need a new reference by the DNS that links your IP address to the domain name. Then, you need to forward the incoming traffic from your router to the server (where you host the actual data).

  1. to access your server from the LAN, add an entry to the hosts file on your PC, linking the server name to the LAN IP address.
  2. as stated above, you need to enable port-forwarding on your router, linking the incoming traffic to your server.
2 Likes

Interesting, I’d have expected pinhole nat to trigger out of the box? What router are you using? If you’re using OpenWRT, Mikrotik, Ubiquiti, or any of the newer Omada TP-Link stuff, it’s pretty flexible (in decreasing order) when it comes to port forwarding rules (compared to ISP provided or off-the-shelf el-cheapo stuff). Usually you can get it to do the right thing even if it’s doing the wrong thing by default.

…or set it up on your router/dns server such that in technical terms you have split-horizon dns , that returns different results based on where the client is. To hosts on your network www.example.com should resolve to 192.168.0.123 - your local server IP address, but on the internet or should resolve to 1.2.3.4 - or your internet facing IP address.

If you use pihole, you can setup local overrides, and if your webserver is always on, you can usually have it setup to pull double duty as a DNS server as well for your local lan.

…yes, but also, when forwarding, think about where the traffic is coming from, and where the replies should be going and where the replies should be coming from. Reply packets for external traffic from the internet get NAT-ed to look like they originate from your router / public IP. Reply packets that you DNAT to the server from your local LAN, do not get their source address touched. The server will try to reply directly to the client host, and the client host will be confused because that’s not the IP it was expecting to see a reply from. You also need to do “pinhole nat”. Specifically, traffic coming from local LAN onto the public IP address of the router, should be SNAT-ed (source address rewritten), such that it looks like it’s coming from the router.

You may be wondering “didn’t I just do this DNS stuff, why would I need this stupid double NAT thing?”. It’s because some devices / people refuse to use DNS handed to them by their local nework and configure 8.8.8.8 or 1.1.1.1 directly on their devices. These know nothing about your internal network and when asked about www.example.com will serve your public facing IP address in the reply - which may cause issuse.

Also, you may be wondering “why don’t I just configure pinhole nat from the start - why bother with DNS”. Accessing your server directly means your server can differentiate between different clients on your network and you get more useful logs and ability for your webapps to track client IPs. Most routers suck in terms of performance relative to a typical webserver.


… and then there’s ipv6; …and DNSSec; …and https; … and DSR and other stranger nats and proxies you probably don’t need.

2 Likes

Sorry for bump, but what is the correct way to redirect domain.com to domain.com:81 (since i cant use port 80) if there is a way?
also is there option to make subdomain by using specific port (ex:
domain.com:8080xxx.domain.com
)?