i don't have an own local dns. my router do relay from public dns servers.
Much easier to set up dnsmasq
or unbound
than all you're trying to do.
Even if you get half of hairpin NAT working, how are you going to deal with the return packets if the two hosts are on the same network?
Outbound packet
192.168.1.100 => publicIP gets routed to 192.168.1.1 and NAT-ed to
192.168.1.100 => 192.168.1.171
Return packet
192.168.1.171 => 192.168.1.100 which is link-local and never touches the router
Your host never sees publicIP => 192.168.1.100
Edit -- Here's what I would do
Ignore the subnet that your ISP gives you, configure your OpenWrt WAN for 192.168.254.2 -- that's effectively a one-to-one mapping of your public IP.
Put all your hosts behind the OpenWrt box.
Set up dnsmasq
on your OpenWrt box to provide DHCP and DNS
Set up dnsmasq
on your OpenWrt box to resolve whatever hostname(s) you want to the IP of the service host on your behind-OpenWrt net.
Set up port forwarding on your OpenWrt box to forward 192.168.245.2:nnnn to the IP and appropriate port of the service host on your behind-OpenWrt net.
Done.
Want a little more security? Put your service hosts on their own subnet and route to them from your internal hosts. Firewall as appropriate between the two. (I personally wouldn't trust the security of "win10 machine with apache" exposed to the Internet.)
That's what i have done, the port forward works. but the problem was the access to my external ip form my own subnet (where the server is)...
-> "NAT Loopback". And yes, i occurs too when i put my server directly into the 192.168.254.xx zone from the ISP's router. So the Nat loopback problem is there, and not on OpenWRT...
The Win10 Machine with Apache is just for testing. It's my own laptop and not a server
Now i have one strange probem more, "/etc/init.d/fwrules disable" does not remove the entries in /etc/rc.d/" anymore. Yesterday, when i remember right, there wasn't a problem like that:
root@OpenWrt:/etc/rc.d# /etc/init.d/fwrules enable
root@OpenWrt:/etc/rc.d# ls
K10gpio_switch K98boot S11sysctl S35odhcpd S95done
K50dropbear K9999fwrules S12log S50cron S96led
K85odhcpd K99umount S12rpcd S50dropbear S98sysntpd
K89log S00sysfixtime S19dnsmasq S50uhttpd S9999fwrules
K90network S10boot S19firewall S80ucitrack S99urandom_seed
K90sysfixtime S10system S20network S94gpio_switch
root@OpenWrt:/etc/rc.d# /etc/init.d/fwrules disable
root@OpenWrt:/etc/rc.d# ls
K10gpio_switch K98boot S11sysctl S35odhcpd S95done
K50dropbear K9999fwrules S12log S50cron S96led
K85odhcpd K99umount S12rpcd S50dropbear S98sysntpd
K89log S00sysfixtime S19dnsmasq S50uhttpd S9999fwrules
K90network S10boot S19firewall S80ucitrack S99urandom_seed
K90sysfixtime S10system S20network S94gpio_switch
root@OpenWrt:/etc/rc.d#
the entries "K9999fwrules" and "S9999fwrules" are still there...
And a "disable_service" method will not be accepted so it seems. nothing happens:
#!/bin/sh /etc/rc.common
# chkconfig: 5 9999 9999
START=9999
STOP=9999
start() {
set -x
# sleep 30
rm /etc/init.d/public_ip.txt > /dev/null 2>&1
wget -qO- https://api.ipify.org > /etc/init.d/public_ip.txt
for IP in $(cat /etc/init.d/public_ip.txt);
do iptables -t nat -A PREROUTING -d x.x.x.x -m tcp -p tcp --dport 80 -j DNAT --to-destination $
done
iptables -t nat -A POSTROUTING -d 192.168.1.21 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1
# rm -f /etc/init.d/public_ip.txt
}
stop() {
rm /etc/init.d/public_ip.txt > /dev/null 2>&1
}
disable_service()
{
rm -f /etc/rc.d/K9999fwrules
rm -f /etc/rc.d/S9999fwrules
}
"sh /etc/init.d/fwrules disable" does also not help. The entries "S9999fwrules" and "K9999fwrules" are still in "/etc/rc.d/"
Is it because of "# chkconfig: 5 9999 9999" ?
That's the only one change when i compare it to the previous version...(?)
Yes, it's 100% not disabled. "public_ip.txt" will be re-generated after reboot..
What i try for disabling is exactly what i read here: https://medium.com/openwrt-iot/lede-openwrt-boot-structure-e689c4ddea91
"You can lead a horse to water..."
no i need to check it from outside... what is if the connection fails..?
and access to www.abc.com stil works. then i don't care about anyting, while the connection is lost. i have my reasons for that!
Now that seems to work for disabling. But in my opionion it makes no sense when i need to override the "disable" method. and why i don't need to override the "enabled" method...?
#!/bin/sh /etc/rc.common
# chkconfig: 5 9999 9999
START=9999
STOP=9999
start() {
set -x
# sleep 30
rm /etc/init.d/public_ip.txt > /dev/null 2>&1
wget -qO- https://api.ipify.org > /etc/init.d/public_ip.txt
for IP in $(cat /etc/init.d/public_ip.txt);
do iptables -t nat -A PREROUTING -d x.x.x.x -m tcp -p tcp --dport 80 -j DNAT --to-destination 192.168.1.21:81;
done
iptables -t nat -A POSTROUTING -d 192.168.1.21 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1
# rm -f /etc/init.d/public_ip.txt
}
stop() {
rm /etc/init.d/public_ip.txt > /dev/null 2>&1
}
disable()
{
rm -f /etc/rc.d/K9999fwrules
rm -f /etc/rc.d/S9999fwrules
}
forum seems to have a problem with formatting inside "´´´"
Look, it just works.
I also pretty much guarantee you'll be putting up another 40 to 100 posts of your personal notes when you find out that you can't configure the return packets if you try to continue on the path you're on with packet mangling.
Outside hosts:
- Get your public DNS
- Connect to whatever your public IP address is
- Your ISP NATs that and delivers it to you on 192.168.254.2
- Your OpenWrt box NATs and delivers to 192.168.1.171
- Return packets follow the reverse path
Inside hosts:
- Get your local DNS
- Connect to 192.168.1.171
- Return packets return on link
Yes there is. You check it from outside of your network. Besides, the configuration you're setting up will not confirm that your server works from the Global Internet. You even said that yourself:
You make this entry on the OpenWrt router, not the clients.
I have to agree with @jeff:
It often does not work to access your own public IP via your own ISP connection. As others said, that requires the ISP's systems to "hairpin" packets back at you, which many do not do.
If your ISP won't hairpin, you have to do the DNS workaround, so what appears to be a public connection from inside is actually handled locally.
A true test of whether your server can be reached from the Internet would require an separate Internet connection such as a phone, or making a request originated from a third party server on the Internet. For example subscribe to a VPN service then go to your own web server via the VPN.
Thanks to everyone!!
It works "not bad" until now. More is here, for the german-speaking persons: https://debianforum.de/forum/viewtopic.php?f=18&t=170787
With best regards,
Jan
"It works "not bad" until now."
Most current version of my script:
#!/bin/sh /etc/rc.common
# chkconfig: 5 9999 9999
START=9999
STOP=9999
start() {
set -x
rm /etc/init.d/public_ip.txt > /dev/null 2>&1
wget -qO- https://api.ipify.org > /etc/init.d/public_ip.txt
for IP in $(cat /etc/init.d/public_ip.txt);
do
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 24 -j DNAT --to-destination 192.168.1.26:22;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 80 -j DNAT --to-destination 192.168.1.21:81;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 444 -j DNAT --to-destination 192.168.1.21:444;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.26:3306;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9000 -j DNAT --to-destination 192.168.1.21:9000;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9001 -j DNAT --to-destination 192.168.1.21:9001;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9002 -j DNAT --to-destination 192.168.1.21:9002;
# POSTROUTING
iptables -t nat -A POSTROUTING -d 192.168.254.2 -s 192.168.254.0/24 -j SNAT --to-source 192.168.1.1;
done
}
stop() {
rm -f /etc/init.d/public_ip.txt > /dev/null 2>&1
/etc/init.d/firewall stop
/etc/init.d/firewall start
}
disable() {
rm -f /etc/init.d/public_ip.txt > /dev/null 2>&1
rm -f /etc/rc.d/K9999fwrules > /dev/null 2>&1
rm -f /etc/rc.d/S9999fwrules > /dev/null 2>&1
/etc/init.d/firewall stop
/etc/init.d/firewall start
}
restart() {
stop
start
}
Most current version, but i'm not sure about the post routing part of it. (?)
#!/bin/sh /etc/rc.common
# chkconfig: 5 9999 9999
START=9999
STOP=9999
start() {
set -x
rm -f /etc/init.d/public_ip.txt > /dev/null 2>&1
wget -qO- https://api.ipify.org > /etc/init.d/public_ip.txt
for IP in $(cat /etc/init.d/public_ip.txt);
do
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 24 -j DNAT --to-destination 192.168.1.26:22;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 25 -j DNAT --to-destination 192.168.1.168:22;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 80 -j DNAT --to-destination 192.168.1.21:81;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 444 -j DNAT --to-destination 192.168.1.21:444;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.26:3306;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9000 -j DNAT --to-destination 192.168.1.21:9000;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9001 -j DNAT --to-destination 192.168.1.21:9001;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 9002 -j DNAT --to-destination 192.168.1.21:9002;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.21:3389;
iptables -t nat -A PREROUTING -d $IP -m tcp -p tcp --dport 3390 -j DNAT --to-destination 192.168.1.26:3389;
# POSTROUTING
# iptables -t nat -A POSTROUTING -d 192.168.1.21 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1;
iptables -t nat -A POSTROUTING -d 192.168.254.2 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1;
done
}
stop() {
rm -f /etc/init.d/public_ip.txt > /dev/null 2>&1
/etc/init.d/firewall stop
/etc/init.d/firewall start
}
disable() {
rm -f /etc/init.d/public_ip.txt > /dev/null 2>&1
rm -f /etc/rc.d/K9999fwrules > /dev/null 2>&1
rm -f /etc/rc.d/S9999fwrules > /dev/null 2>&1
/etc/init.d/firewall stop
/etc/init.d/firewall start
}
restart() {
stop
start
}
It's not entirely clear to me the issue but if you just put your public IP on your lo interface as a /32 doesn't that just solve all the problems with hairpin NAT?
It looks like you are solving the problem from the wrong side, because according to those port forwardings you should set up a VPN.
And if you want to access a service by the same name from LAN and WAN without VPN, just rebind it to LAN IP-address on your LAN DNS-server.