DMZ and no access to ports on public ip?

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.)

1 Like

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..."

1 Like

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! :wink:

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
1 Like

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.

2 Likes

Thanks to everyone!! :slight_smile:

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.