To preserve your privacy, shw us the first two octets of your WAN address.
1 Like
Look at the status page which is shown when you first sign into the router. There's a section called "Network". Inside that section there's an entry called "IPv4 Upstream". Here's a (redacted) screenshot of what mine looks like.
I'm not sure what I can show, but here is what is looks like on my side,
Which field am I looking for here?
You're looking for the Address and Gateway fields... without the complete redaction.
Do you have a private IP address or a public IP address shown there? Does it match what you can see from any of the myriad "what is my IP address" websites out there?
The address field starts from 10. and Gateway 45. and according to www.whatismyip.com the IP address matches the gateway, except the digits after the last . on the the website it has a number bigger than 100, but on router page it is just .1
Also the gateway field changes its not static.
That's a private IP address, not a public one. That means that there's another router upstream of yours, and it's possible you might not be able to configure it. Who's your ISP? Does your ISP use "carrier-grade NAT"?
3 Likes
There is a modem connect to my router, that is connect to some fiber optics coming from ISP.
I'm not sure what "Carrier-grade NAT" is..
I can't say, I need to ask my ISP about this.
Indeed. If your ISP is giving you a private (RFC1918) address, then you'll need to request your ISP's assistance with inbound port forwarding. Alternately, you may need to request a public IP address from your ISP.
1 Like
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