WebUI external access

Is there a way to configure the WebUI for external access? Is it possible to change the default port from 8080 to something else?

This is already the case, and the port is already opened in the firewall iptables. If communication isn’t going in-bound, let us know from where it is starting, e.g., “can connect locally, can’t connect from outside the LAN”. More often than not, this is because you’ll need to set up port forwarding on your router.

Yes, that is changed in /etc/mineos.conf. Simply change 8080 to whatever you’d like, but this change requires further changes in the firewall (and router), likely.

Connecting locally is fine. I want to be able to connect to it using the external ip address. I already added the port forwarding on the router for 8080 but it still doesnt work. I have Comcast Business broadband and I heard they might be blocking certain ports?

Well, I changed the port and reflected the change on the router and that worked! I think my isp is blocking that 8080.

1 Like

I’m having a really hard time with the syntax when it comes to changing the port allowed to access the web-ui. I really need some help with it and I am not comfortable modifying it on my own. I want to change the default port to access the web-ui to 10000.

@hexparrot
Would the command

iptables -A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT

add port 10000 to the ports able to be used by the server? Then I would finish off with

iptables-save > /etc/iptables-rules

and

iptables-restore < /etc/iptables-rules,

right? (sorry if that looks weird, just thought I’d make it easier to read, perhaps)

-the Nerd Herd

PS. I went ahead and did it anyway against my better judgement. Now I can access the WebUI locally from port 10000, instead of 8080. This did not fix my connection problems. What should I do to allow others to get connected to my WebUI?

1 Like

If you want others to connect to your web-ui, I’m assuming you mean from outside your network. Well, getting the firewall from the server open was half the battle, so the remaining half is letting the router know that all traffic inbound should be forwarded there.

Thus, the final step is to set up port forwarding in your router configuration to redirect traffic to your server’s ip.

But… D: I was almost certain I’d forwarded all the ports I needed to forward.

Isn’t that all the stuff?

HTTP is… HTTP. I don’t really know why I put that one there. I thought it would help.
MCServ is the server itself, running on port 25565. People can connect to the Minecraft game externally.
Self-Serv was me trying to think of a clever name for the WebUI, weeks ago. I set the port to 10000 from 8080 a few hours ago. (see my last post) No difference in level of connection AFAIK.
The Webmin is perhaps only less obvious to HTTP. I’d really like to be able to access the Webmin externally as well, for shutdown/startup/FTP purposes. (I really really really really don’t get SSH. I haven’t learned how to code and I am regretting it big-time.)

Hrm, so you are able to successfully connect to your web-ui via 10000? If so, that means your firewall (on the server) is 100% correct. And from this screenshot, it appears your port forwarding is correct as well.

I can’t think of any good reason why it wouldn’t work now, perhaps it’s something glitchy in your router itself, that a reboot might be a good first step?

At any rate, it all looks appropriately configured from what you’re showing… I’ll continue pondering over this but I can’t imagine why it wouldn’t work, seeing as how it works locally and how your server even works externally.

Does the webmin work externally? I’m really thinking you perhaps just need to disable the rule and re-create it for 10000. That said, you can also try DMZ temporarily, making sure that all unforwarded traffic gets caught and sent to your 192.168.1.148. That might be a worthwhile testing route.

Remember the webui uses https so you actually have to write it https://blahblah.blah

1 Like

An excellent point. What URL are you using in your address bar to connect externally?

https://ipaddress:10000

I’m almost certain that I have been using HTTPS when trying to connect to my server externally every time. I stored the address in my bookmark bar so I truly don’t know just yet; I’m writig from my iPad and won’t be back at my house until Thursday. I probably won’t be able to check anything until Friday.

On a…somewhat different note, our DSL company forwarded ports 10000, 12321, and 25565 “officially and completely”, they say. There was also an issue with the cable connecting our modem to the DSL service, which they fixed; it was just a bad cord evidently. Not that you knew there was an issue with our internet connections in the first place; we didn’t have access the the WWW for the weekend.

Anyway, I’ll keep you in the loop. I’ll try connecting the the server when I get home today; it could be fixed, I don’t know. The server has been rebooted since the reconnection of our internet service, so there shouldn’t be any IP address problems.

Cheers!
-the Nerd Herd

You might also consider to map your source and destination ports on different numbers.

For example, your internal server is running on let’s say port 8080.
From the internet you want people to access it on port 9000.

Now you should add port 9000 to the “External port” list and 8080 as the “Internal Port” these ports can be different from each other. If you do it this way, you don’t have to change anything on your webserver.

For now, I would not know why you would want to change the port name locally.
The only thing you want to change is the “External port”, because you can’t run two services on the same port.
The reason for this, is because you will only have one external IP address, which only allows you to use each of the 65536 ports only once, I do recommend to ONLY use the so called “dynamic” ports of the TCP range, because the lower number ports are reserved for “standard” services.

@Niels_Hanssen I’m not quite sure if I get what you’re saying.

Are you saying that I should add a new rule to my firewall and allow… No, still don’t get it.

Specifically, I am having trouble understanding what you mean by “source” and “destination” ports. It seems (just hypothesizing) that source would be where it originates and destination would be wherever the user is accessing from… but I don’t have full control over all users’ methods of access.

This is really escaping me. Sorry.

Anyway, moment of truth: I’m at my dad’s house, the server is at my mom’s, and the places aren’t on the same network. Here goes!

Results: (images)

The IP I edited in isn’t my real one. I’m not gonna disclose it; I value my privacy. Maybe to @hexparrot… the admin, right?

Anyway, it clearly didn’t work. I will try using my domain name thingies to connect to the server’s… doodad.
…WebUI!

Right. Until then. -the Nerd Herd

@Nerd, look at it this way…

You are a user on the internet, who wants to access a specific server.
In order to be able to access an server, you would need to know a couple of things.

first the DNS name or the IP address.
second the port.

to the end user that you are on the internet this would be the destination.


Now if you look at it from a “routers” perspective, it would be different.
The router is waiting for someone from the internet to send a request to it for a certain port.
Once it receives a request on the specified port, it will forward traffic from that, to his understanding “source” port to the final destination port.
So to the router the source port is what is the destination port to the end user on the internet. :smile:

User <–> Internet <–> Router <–> Server
User:port:5555 <–> Internet <–> Router:port:5555 <–> Server:port:6666
User: destination <–> Internet <–> Router:Source <–>Server:destination

Lol… i don’t know if it helps to make things more clear or to make even more vague :smiley:

No, I think I’m beginning to understand actually! The source/destination explanations were really helpful. If you haven’t already, maybe you should write a wikiHow page or something, relating to that. :slight_smile:

Do you have the know-how to explain what I might do to redirect a destination port to a source port in my router? My router is a Cisco/Linksys E1200, and there’s a picture of the port forwarding screen in post 9.

WAIT. IT CAME TO ME.

Does it go like this? In reference to the picture in post 9:

Application name:
Self-Serv

External port:
destination

Internal port:
source

protocol:
both

to ip address:
192.168.1.148

enabled:
(check)

Right?

Correct, the only other thing I would change, would be “protocol:”.
There is no reason to set it to both, change it to TCP.

I noticed you said that you can access the server on port: 10000 from the internal network.
Is still still the situation?

Yeah, the server’s internal WebUI port is still 10000. I haven’t been around to change it. I might be able to do something about it Friday. (today, I forgot to post this last night) I don’t really understand the syntax to adjust the firewall WebUI communication port, so we’ll see about that.

This firewall stuff is still beyond me.

I need help constructing a command using the syntax here to:

-disallow/ban communication with the WebUI on port 10000 as the source (locally)

-allow/admit communication with the WebUI on port 8080 as the source (locally)

I saw on the Iptables page there was a command that “[allows] webui on HTTPS”,

iptables -A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT,

but I am unsure if it would simultaneously disallow communication with the WebUI on port 10000 while allowing communication with the WebUI on port 8080. Basically, I’m asking, does it shift the WebUI port from 10000 to 8080, or open a new port (8080) while keeping 10000? I’m not interested in sloppy stuff like that. I’d like to allow (internal, local, w/e) communication over 8080, and no further (internal) communication over 10000.

I do understand that I will need to “remap” the source to the destination in my router by “remapping”
source:10000 <-> destination:10000
to
source:8080 <-> destination:10000,
and also set this port-forwarding configuration to only use TCP.

My apologies, this thread has clearly taken and is still taking a really long time to resolve. I hope to solve this soon and let you both back to business as usual.
@hexparrot
@Niels_Hanssen