I see, BTW if I try to go to the address starting with 10. it opens my OpenWRT LuCI interface.
Double-check your firewall and uhttpd configuration. It's not usually considered good practice to expose your router's admin interface on its WAN side.
Further to the above, I've just tested in my VM lab. If I connect to the WAN interface from a host behind the firewall on the LAN side, I can bring up the Luci login page. However, if I try to connect to the WAN interface from a host on the WAN side (e.g. another machine elsewhere on my LAN), I can't connect. This is as it should be, if the firewall is set to its default configuration.
However, it's always worth double-checking, to make sure that ports 80 and 443 aren't exposed to the WAN unless you have a specific reason to do so.
What am I looking for in the firewall settings? And how to check uhttpd settings?
-
/etc/config/firewall- Are ports 80 and 443 exposed to the WAN? -
/etc/config/uhttpd- Are ports 80 and 443 exposed to the WAN?
I have shared my firewall config here - How to port forward to my Jellyfin server? - #3 by apoorv569
and here is the uhttpd config,
# Server configuration
config uhttpd main
# 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
# Redirect HTTP requests to HTTPS if possible
option redirect_https 1
# Server document root
option home /www
# Reject requests from RFC1918 IP addresses
# directed to the servers public IP(s).
# This is a DNS rebinding countermeasure.
option rfc1918_filter 1
# Maximum number of concurrent requests.
# If this number is exceeded, further requests are
# queued until the number of running requests drops
# below the limit again.
option max_requests 3
# Maximum number of concurrent connections.
# If this number is exceeded, further TCP connection
# attempts are queued until the number of active
# connections drops below the limit again.
option max_connections 100
# Certificate and private key for HTTPS.
# If no listen_https addresses are given,
# the key options are ignored.
option cert /etc/uhttpd.crt
option key /etc/uhttpd.key
# CGI url prefix, will be searched in docroot.
# Default is /cgi-bin
option cgi_prefix /cgi-bin
# List of extension->interpreter mappings.
# Files with an associated interpreter can
# be called outside of the CGI prefix and do
# not need to be executable.
# list interpreter ".php=/usr/bin/php-cgi"
# list interpreter ".cgi=/usr/bin/perl"
# List of prefix->Lua handler mappings.
# Any request to an URL beneath the prefix
# will be dispatched to the associated Lua
# handler script. Lua support is disabled when
# no handler mappings are specified. Lua prefix
# matches have precedence over the CGI prefix.
list lua_prefix "/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua"
# Specify the ubus-rpc prefix and socket path.
# option ubus_prefix /ubus
# option ubus_socket /var/run/ubus.sock
# CGI/Lua timeout, if the called script does not
# write data within the given amount of seconds,
# the server will terminate the request with
# 504 Gateway Timeout response.
option script_timeout 60
# Network timeout, if the current connection is
# blocked for the specified amount of seconds,
# the server will terminate the associated
# request process.
option network_timeout 30
# HTTP Keep-Alive, specifies the timeout for persistent
# HTTP/1.1 connections. Setting this to 0 will disable
# persistent HTTP connections.
option http_keepalive 20
# TCP Keep-Alive, send periodic keep-alive probes
# over established connections to detect dead peers.
# The value is given in seconds to specify the
# interval between subsequent probes.
# Setting this to 0 will disable TCP keep-alive.
option tcp_keepalive 1
# Basic auth realm, defaults to local hostname
# option realm OpenWrt
# Configuration file in busybox httpd format
# option config /etc/httpd.conf
# Do not follow symlinks that point outside of the
# home directory.
# option no_symlinks 0
# Do not produce directory listings but send 403
# instead if a client requests an url pointing to
# a directory without any index file.
# option no_dirlists 0
# Do not authenticate any ubus-rpc requests against
# the ubus session/access procedure.
# This is dangerous and should be always left off
# except for development and debug purposes!
# option no_ubusauth 0
# For this instance of uhttpd use the listed httpauth
# sections to require Basic auth to the specified
# resources.
# list httpauth prefix_user
# Defaults for automatic certificate and key generation
config cert defaults
# Validity time
option days 730
# key type: rsa or ec
option key_type rsa
# RSA key size
option bits 2048
# EC curve name
# Curve names vary between mbedtls/px5g and openssl
# P-256 or P-384 are guaranteed to work
option ec_curve P-256
# Location
option country ZZ
option state Somewhere
option location Unknown
# Common name
option commonname 'OpenWrt'
# config httpauth prefix_user
# option prefix /protected/url/path
# option username user
# option password 'plaintext_or_md5_or_$p$user_for_system_user'
That's how the magic happens. uhttpd is listening on ports 80 and 443 on all interfaces (0.0.0.0). That's how you can connect to Luci by the WAN address even though you're on a machine on the LAN side.
The firewall does not - according to the configuration you posted earlier - permit inbound connections from external hosts to the WAN interface on ports 80 and 443. However, it does permit connections to the WAN interface from machines which are on the LAN side.
In short, as far as incoming connections from the WAN are concerned, uhttpd allows it, but the firewall blocks it.
I see, should I change the listen address in the uhttpd configuration then?
My recommendation would be to do so. My preference is that it's not enough for the firewall to drop inbound connections; the underlying daemon shouldn't even be listening on all interfaces in the first place (the fact that it does listen on all interfaces is a convenience to help make OpenWRT easier to use for the novice).
It's an additional layer of security: admin interfaces should onlly be exposed to the networks which need them.
Other people have different opinions; I have seen it argued elsewhere on this forum that 0.0.0.0 is fine. I can only offer my own experience and opinion. Ultimately you should weigh up the pros and cons and come to your own conclusion.
Be very careful if changing the configuration of /etc/config/uhttpd - if you get the listening IP address wrong you can lock yourself out of Luci.
I see, I don't feel comfortable with changing it yet, as I'm not very familiar with networking in general, its something I am still learning and interested in, maybe I'll change it later.
1 Like
I tried port forwarding port 22 on the same server that I'm trying to forward port 8096, and I tried ssh into it over other network, it finds it, but for some reason it says permission denied.
because you tried to ssh into the router of your provider.
3 Likes
So ports are not forwarded back my LAN they stay in WAN you mean?
Okay, I will talk to my provider.
Thank you, this somewhat helped me with understanding. So basically my ISP has given me some IP that acts as a WAN for my local network which I control, and it is not a public IP. So when I try to ssh to my public IP I'm basically connecting to ISP's router.
So just curious, will my ISP open up port 8096 on his/her router for me, or is it some other procedure?
There's a difference between will and can.
Your ISP can, but might not. In fact, probably won't. But it's worth having a conversation with your ISP anyway. Depending on your ISP, you might be able to get the port opened the way you want, or you might even be able to get a public IP address.
2 Likes
I see, thank you for explaining.
1 Like
Some ISPs allow users to open ports on their routers/modems, some give direct access to the configuration page, some have dedicated tools; and some ISPs completely ban the opening of any port at all. You might want to check with your ISP.
4 Likes