Can't Open Port 80

@trendy

This is the output:

[0:0] -A zone_lan_prerouting -s 192.168.10.0/24 -d 135.23.172.137/32 -p tcp -m tcp --dport 80 -m comment --comment "!fw3: gateway80 (reflection)" -j DNAT --to-destination 192.168.10.228:80
[2665:107708] -A zone_wan_prerouting -p tcp -m tcp --dport 80 -m comment --comment "!fw3: gateway80" -j DNAT --to-destination 192.168.10.228:80

@iplaywithtoys

This is the output:

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2374/uhttpd
tcp        0      0 :::80                   :::*                    LISTEN      2374/uhttpd

and

Here is the output:

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      2374/uhttpd
tcp        0      0 :::443                  :::*                    LISTEN      2374/uhttpd

Thanks.

bdika

At the moment your router listens on ports 80 and 443 on all interfaces, even the WAN interface. That's what the 0.0.0.0:80 and 0.0.0.0:443 entries mean. I believe that might be interfering with your attempts to open port 80 inbound. If you limit uhttpd to listening solely on the LAN interface, and not the WAN interface, it should - all being well - allow inbound traffic on ports 80 and 443 to your internal server.

I'm going to hazard a guess that your router's LAN interface is on 192.168.10.1. If my guess is wrong, feel free to replace the IP address with the correct one.

I reckon your /etc/config/uhttpd probably starts like this:

        # HTTP listen addresses, multiple allowed
        list listen_http        0.0.0.0:80
        list listen_http        [::]:80

        # HTTPS listen addresses, multiple allowed
        list listen_https       0.0.0.0:443
        list listen_https       [::]:443

If you change those lines to the following (remembering to change the IP address if my guess is wrong), and restart uhttpd, it might do the trick:

        # HTTP listen addresses, multiple allowed
        list listen_http        192.168.10.1:80
        list listen_http        [::]:80

        # HTTPS listen addresses, multiple allowed
        list listen_https       192.168.10.1:443
        list listen_https       [::]:443

To restart uhttpd from the commane line, issue the command /etc/init.d/uhttpd restart

@iplaywithtoys

I followed your instructions and something has changed. When I use the open port tool, it shows my external IP address as different than the one show above (135.xxxxxx). When I replace the external IP address with the one above (135.xxxxxx) and test port 80, it says it is open! But when I try port 443 it says it is closed. I want to reboot my router but I can't right now because of other people in the household depending on a steady internet connection. I will reboot it later tonight and see if anything changes.

I got my son to try and connect from outside my lan, with both http and https but no luck.

If you have any idea why my external IP is different than what is showing on my router (VPN?) or know why port 443 would show as closed, I would appreciate your knowledge.

Why was the change you suggested required? Did I inadvertently change something since using NO-IP?

In any case I will keep you posted.

Thank you very much.

bdika

Be very careful that you don't expose the OpenWRT admin web page to the Internet by mistake.

I've re-read what I wrote last night, and I realised I omitted something rather fundamental: an explanation of why OpenWRT listens on ports 80 and 443 already.

The default installation of OpenWRT opens both ports 80 and 443 for its own admin web page, which is why those 0.0.0.0:80/443 entries already exist. If you've changed one of those entries in /etc/config/uhttpd from what I suggested to your public-facing address instead, you risk opening your router's admin web page to the whole world.

Successful traffic flow requires three things:

  • A route ("where do I send this?")
  • A firewall rule ("is this permitted?")
  • Something at the other end listening for the traffic

That final point might be why port 443 is still closed. If you've altered my suggestions and used your public address where I suggest to use your router's LAN address, traffic might be hitting your router on port 443 and uhttpd might be trying to process it.

However, the default installation of OpenWRT does not include luci-ssl pre-installed, so any attempts to connect directly to the router's management web page via HTTPS (443/tcp) will fail. You can try it yourself on your router's LAN address:

If you want to manage your router via HTTPS, luci-ssl will be useful. If you want to allow inbound HTTPS traffic to a different server entirely, you don't need luci-ssl on OpenWRT.

To summarise: remember the difference between trying to connect directly to OpenWRT's own web server (which is used by OpenWRT for its own management) and trying to connect to a web server sitting on the network behind OpenWRT.

1 Like

It doesn't matter as the DNAT rule in the PREROUTING chain changes the routing decision.
Moreover, interface/socket binding is best to avoid due to possible race conditions.

1 Like

Very useful to know, thank you! I wasn't sure about the order of precedence.

1 Like

@iplaywithtoys
@vgaetera

I want to avoid this. I am trying to log into http/https://dikacloud.duckdns.org from outside of the lan.

I didn't alter your instructions.

This worked.

I rebooted my router but the result is the same.

Thank you both.

bdika

I've just gone back and re-read the thread from the beginning. Unless I've missed something in the configuration excerpts which you posted, it looks like you've set up a rule for port 80 but haven't yet set up an equivalent rule for port 443. If that's the case, it might explain what you're seeing. What are the current contents of /etc/config/firewall?

2 Likes

@iplaywithtoys
@vgaetera

Success!! My son could connect to my site from outside the lan.

Thank you so much.

I'm still not sure why it was so easy to set up with NO-IP but required

this change to work with duckdns. I don't recall changing anything.

You were right. I set up the rule in luci and it now it all works.

Thanks again!

@vgaetera

Thanks for having patience with me when I was busy and slow to respond.

bdika

3 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.