Port forward doesn't seem to work

I'm trying to forward a few ports to a server that I run, mainly port 80, 443, and 22. Right now I'm just trying to get a single port forward working but no dice. The firewall on the server accepts the ports, but I still can't connect to the server from outside my network, even if I disable the firewall and SELinux. Ironically mywebserver.com works inside my network, but not outside my network.

I had this working before I flashed OpenWRT so I know things are set up properly on the server, the only change is OpenWRT so I must be doing something wrong.

Firewall settings are here: https://pastebin.com/hzkJYep3

Not sure what else you might need but just let me know.

Packets coming on the WAN side are not destined to the LAN side untill the redirection occurs. You should not specify a "dest".

1 Like

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

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.

1 Like

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
Check tcpdump on the server.

1 Like

so on the server I ran

sudo tcpdump -i any -c 1000 > tcpdump

Then grep'd tcpdump for but grep returned no results. Would you like a pastebin of the results?


sudo tcpdump -n -i any tcp port 80


nc 80
1 Like


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 80 doesn't return any results from the router:

root@OpenWrt:~# nc 80

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:

1 Like

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 ?

1 Like

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

1 Like

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

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] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer:
[Thu Sep 05 18:09:38.405201 2019] [cgid:error] [pid 2228:tid 140103756379904] [client] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer:
[Thu Sep 05 18:09:38.426387 2019] [cgid:error] [pid 2228:tid 140103739594496] [client] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer:
[Thu Sep 05 18:09:39.429288 2019] [cgid:error] [pid 2228:tid 140103722809088] [client] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer:
[Thu Sep 05 18:09:40.436846 2019] [cgid:error] [pid 2228:tid 140103510914816] [client] AH01264: script not found or unable to stat: /var/www/cgi-bin/luci, referer:

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 to 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 both and ::1.

To be able to access the domain via IPv6:

1 Like

If you have ssl-luci connection to 80 get redirected to https 443 by uhttpd ? Am I wrong ?