Packets coming on the WAN side are not destined to the LAN side untill the redirection occurs. You should not specify a "dest".
You need delete this rule
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '80'
option name 'http'
This rule mean you opened the port 80 on this openwrt router.
The forward port is correct.
- Make sure you have a public IP address.
- Test from the outside using some other ISP or internet service.
- Use
tcpdump
on OpenWrt to verify the redirect is working. - Use
tracepath
on the server to verify it can reach the internet via OpenWrt.
Thanks for the help, I have deleted this rule but the port forward still seems to not be working.
I tried the rule with and without option dest 'lan'
but it seems to have no effect.
- I have a public IP
- That is what I am trying to accomplish
- I honestly don't know what I'm looking at here. The local server IP doesn't show up. I let it run for about a minute.
- tracepath appears to fail. Which is strange to me because I can ping google.com just fine, and I can also run
dnf upgrade
just fine.
tcpdump -n -i any tcp port 80
Just make sure the server has the internet connectivity and the router is its default gateway.
Well I only sort of understand what I'm looking at haha, but here is a pastebin of the first bit of results: https://pastebin.com/97837gFF
This time the connection didn't time out, but it appears that it was intercepted by OpenWRT. That is, when I navigated to myserver.com from outside my network, I got the OpenWRT login page. Not really what I want, but I'll take that as a mark of progress! Thank you!
The redirect works, but there's no answer from 192.168.1.152
.
Check tcpdump
on the server.
so on the server I ran
sudo tcpdump -i any -c 1000 > tcpdump
Then grep'd tcpdump for 192.168.1.152 but grep returned no results. Would you like a pastebin of the results?
Server:
sudo tcpdump -n -i any tcp port 80
Router:
nc 192.168.1.152 80
server:
https://pastebin.com/MX2sx9xN
While the command was running I kept trying to connect to the server from outside my network, not sure if that hurt of helped. I figured it would show up in the logs.
nc 192.168.1.152 80 doesn't return any results from the router:
root@OpenWrt:~# nc 192.168.1.152 80
root@OpenWrt:~#
There's no relevant traffic in the log.
Only an outgoing HTTP connection:
If the server is a VM, you should check the hypervisor firewall.
Try this:
wget 192.168.1.152
curl 192.168.1.152
wget gives me
Failed to allocate uclient context
curl gives me the content of index.html, as expected. The server isn't a VM, and access fails even if I disable the firewall and UFW.
You sure your ISP isn’t blocking traffic to your 80 port ?
What is the openwrt router management port number ? Is it 80 or something else ?
@Pippo, as you can see here the redirect is working but the destination host is not responding.
@dpistachio, make sure you see a connection attempt from the router to the server when you run tcpdump
on the server.
@Pippo Yes I'm positive the ISP isn't blocking port 80. It was working for well over a year, right up until I flashed OpenWRT and then it stopped working instantly.
@vgaetera I'm seeing the IP address of the computer outside my network in the tcpdump log, but the external computer is still getting the luci login page. How can I change the port that this listens on? I modified /etc/config/uhttpd but that doesn't seem to have changed it. https://pastebin.com/Vh7qfb2U
Your last tcpdump
log looks like it is working, but there's a web server error:
Do you see the incoming connections in the web server log?
This is confusing.
Check from the router:
ip a; ip r; ip ru; iptables-save
iptables-save: https://pastebin.com/3pSEbiaC
I checked the httpd error log on the server and it is filled with
[Thu Sep 05 18:09:37.402309 2019] [cgid:error] [pid 2228:tid 140103747987200] [client 192.168.1.1:50064] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer: http://192.168.1.1/cgi-bin/luci/admin/network/firewall/forwards/cfg0f3837
[Thu Sep 05 18:09:38.405201 2019] [cgid:error] [pid 2228:tid 140103756379904] [client 192.168.1.1:50064] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer: http://192.168.1.1/cgi-bin/luci/admin/network/firewall/forwards/cfg0f3837
[Thu Sep 05 18:09:38.426387 2019] [cgid:error] [pid 2228:tid 140103739594496] [client 192.168.1.1:50064] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer: http://192.168.1.1/cgi-bin/luci/admin/network/firewall/forwards/cfg0f3837
[Thu Sep 05 18:09:39.429288 2019] [cgid:error] [pid 2228:tid 140103722809088] [client 192.168.1.1:50064] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer: http://192.168.1.1/cgi-bin/luci/admin/network/firewall/forwards/cfg0f3837
[Thu Sep 05 18:09:40.436846 2019] [cgid:error] [pid 2228:tid 140103510914816] [client 192.168.1.1:50064] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer: http://192.168.1.1/cgi-bin/luci/admin/network/firewall/forwards/cfg0f3837
I don't know why it's looking for /cgi-bin/luci. I imagine that is somehow the routers doing. Document root for this server is /var/www/html/
First, let's fix some obvious errors and make it more clear:
uci set firewall.@redirect[0].dest_port=""
uci set firewall.@redirect[0].proto="tcp"
uci set firewall.@redirect[1].dest_port=""
uci set firewall.@redirect[1].proto="tcp"
uci commit firewall
service firewall restart
If this is not enough, try to disable firewall reflection rules.
If you have a domain name:
- Create an
A
record for your domain pointed to192.168.1.152
on the local DNS server and make sure your LAN clients use this DNS as primary. - Add the domain name to
/etc/hosts
on the server pointed to both127.0.0.1
and::1
.
To be able to access the domain via IPv6:
- Create a static IPv6 lease for the server.
- Create a permissive WAN to LAN forward rule for IPv6 family.
If you have ssl-luci connection to 80 get redirected to https 443 by uhttpd ? Am I wrong ?
https://forum.openwrt.org/t/how-to-change-port-web-ui/20589/6
Firewall NAT rules always override locally open ports.
DNS-based solution is a preferable way over hairpinning to avoid redundant traffic.