Jeremy Gamble
Assigned
Reported
Comments
Okay, I have to take back my original statement about the ports being open for TCP vs. UDP. I just ran another test running two instances of the bedrock_server.exe on my local machine, then took a new netstat -ano snapshot. All eight ports - the two specified in each of the two server.properties files, as well as the two "random" ports automatically assigned by BDS - are listed as UDP ports. I must've looked at it wrong the first time, so I apologize for the confusion.
Here's what I'm seeing:
SERVER 1
D:\Minecraft>D:\Minecraft\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:06 INFO] Starting Server
[2020-04-02 12:29:06 INFO] Version 1.14.20.1
[2020-04-02 12:29:06 INFO] Session ID a97a1c4b-8f9b-4f08-bfd7-e5266fbf1d52
[2020-04-02 12:29:06 INFO] Level Name: Testing World 1
[2020-04-02 12:29:06 INFO] Game mode: 0 Survival
[2020-04-02 12:29:06 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:07 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_07
[2020-04-02 12:29:07 INFO] opening worlds/Testing World 1/db
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 19132
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 19133
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 57850
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 57851
[2020-04-02 12:29:16 INFO] Server started.
SERVER 2
D:\Minecraft>D:\Minecraft\Testing\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:29 INFO] Starting Server
[2020-04-02 12:29:29 INFO] Version 1.14.32.1
[2020-04-02 12:29:29 INFO] Session ID e33ef792-2521-4868-8670-a5f6d2d9d975
[2020-04-02 12:29:29 INFO] Level Name: Testing World 2
[2020-04-02 12:29:29 INFO] Game mode: 0 Survival
[2020-04-02 12:29:29 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:30 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_30
[2020-04-02 12:29:30 INFO] opening worlds/Testing World 2/db
[2020-04-02 12:29:35 INFO] IPv4 supported, port: 19134
[2020-04-02 12:29:35 INFO] IPv6 supported, port: 19135
[2020-04-02 12:29:36 INFO] IPv4 supported, port: 54240
[2020-04-02 12:29:36 INFO] IPv6 supported, port: 54241
[2020-04-02 12:29:37 INFO] Server started.netstat -ano (heavily redacted)
C:\Windows\system32>netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
UDP 0.0.0.0:19132 *:* 23584
UDP 0.0.0.0:19134 *:* 37028
UDP 0.0.0.0:54240 *:* 37028
UDP 0.0.0.0:57850 *:* 23584
UDP [::]:19133 *:* 23584
UDP [::]:19135 *:* 37028
UDP [::]:54241 *:* 37028
UDP [::]:57851 *:* 23584
So, again, I deeply apologize for spreading inaccurate information without fully testing and reviewing it first.
As for running multiple instances of bedrock_server.exe from the same hardware, as I stated above, these results are on the same machine (my local computer) at the same time. As the copy/paste should indicate, there are two complete copies of the BDS directory structure - including individual copies of the bedrock_server.exe and server.properties files - both running different versions of the BDS software and with different ports specified for communication.
SERVER 1 - server.properties
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
SERVER 2 - server.properties
server-port=19134
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19135
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
I believe that, as long as you have the complete directory structure duplicated for each instance of BDS you want to run, the only time you'd run into a problem running multiple instances would be if the randomly selected ports were the same as the specific ports set in the server.properties file of another instance.
For example, if I started SERVER 2 first - where the ports in the server.properties file are set to 19134/19135 - as mentioned by @MiHu and @David Fidler have noted in their comments above, the "random" ports selected and opened by BDS actually end up being the "default" ports of 19132/19133.
If I then tried to start SERVER 1 - where the ports in the server.properties file are still the "default" - the BDS startup would fail because those ports are already in use by the first instance.
Here's what I got when I tested this scenario:
SERVER 2
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:29 INFO] Starting Server
[2020-04-02 13:23:29 INFO] Version 1.14.32.1
[2020-04-02 13:23:29 INFO] Session ID dd414afe-fe12-4318-8eba-6ad4eabd9d02
[2020-04-02 13:23:29 INFO] Level Name: Testing World 2
[2020-04-02 13:23:29 INFO] Game mode: 0 Survival
[2020-04-02 13:23:29 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:29 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_29
[2020-04-02 13:23:29 INFO] opening worlds/Testing World 2/db
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19134
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19135
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19132
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19133
[2020-04-02 13:23:31 INFO] Server started.SERVER 1
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:53 INFO] Starting Server
[2020-04-02 13:23:53 INFO] Version 1.14.20.1
[2020-04-02 13:23:53 INFO] Session ID 06e47362-329e-4f3f-ae98-33eca8e8db0d
[2020-04-02 13:23:53 INFO] Level Name: Testing World 1
[2020-04-02 13:23:53 INFO] Game mode: 0 Survival
[2020-04-02 13:23:53 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:53 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_53
[2020-04-02 13:23:53 INFO] opening worlds/Testing World 1/db
[2020-04-02 13:23:55 INFO] IPv4 supported, port: 0
[2020-04-02 13:23:55 INFO] IPv6 supported, port: 0
[2020-04-02 13:23:55 ERROR] Network port occupied, can't start server.Exactly as expected. So, the moral of the story there is to start up any BDS instance that's using the default ports before any instances that are using "custom" ports.
Of course, all of that still doesn't address why BDS is opening these extra ports in the first place. Especially now that I've gone back and looked more closely at the information and found that all of the ports are opening over UDP. As @SupremeMortal mentioned, I'm guessing that it has something to do with UPnP, but that's still not really an acceptable answer. The application is opening up ports that haven't been explicitly set by the admin, and, as @Rebecca Reed has pointed out a couple of times, that opens up the potential for all sorts of dangerous activity "piggy-backing" on connections over which the admin has no direct control.
Of course, the "goal" of this post is to ensure that BDS doesn't open random ports without explicit permission from the server admin. Perhaps there should be an additional option in the server.properties file to enable/disable UPnP?
I've not encountered that in my testing. Admittedly, that testing has been extremely limited, but as long as I've got two separate copies of the entire BDS directory structure - including a separate copy of bedrock_server.exe - in individual folders and set the specific ports to different values in each of their respective server.properties files, I was successfully able to get two instances running concurrently on my machine.
UPnP may indeed be the "culprit" here. However, without documentation of any UPnP "requirements" for BDS, this remains a potentially significant security issue and a problem for some BDS admins. If the admin's router/firewall does not support UPnP, they will have to manually open the randomly chosen/assigned UDP ports for IPv4 and IPv6. Without knowing how BDS is choosing these port numbers or the ability to manually assign them, such users would possibly have to open a wide range of ports for UDP traffic, or be forced to close/open these ports for each BDS restart. Inexperienced admins may open a much wider range of ports than necessary, and may even open both TCP and UDP traffic on those ports.
Agreed. I over-simplified and unintentionally down-played the issue in my previous comments, but randomly opening arbitrary ports of communication absolutely presents an unnecessary security risk. It may be mitigated through other security measures, but not having clear documentation of what ports are being used, how they are "selected", and their purpose makes doing even that difficult. Not to mention the fact that there are likely a significant number of users who would be unaware of the potential risks involved in simply opening up a range of ports - possibly to both TCP and UDP traffic, "just to be sure" - which could result in even more damage done.
To be fair, a "bug" is, by definition, any programming "flaw" - whether intentional or not - resulting in behavior that is unintended or unexpected and the term can be applied to include anything from a simple typo on a dialog box to a severe memory leak, etc. Because the UDP ports are not explicitly configurable, nor is there any indication of what they are in the current console display, I would suggest that this would be considered both a bug and a documentation issue. I believe it's a good thing that this information is displayed to the user so that the ports that are actively in use by BDS can be seen, but not clarifying the intention and/or implementation for the use of these ports is, perhaps, an oversight that can cause confusion, as well as potential connectivity issues since the "random" UDP ports have to be open/forwarded in addition to the TCP ports in order for the client to properly and fully communicate with the server.
More complete documentation - both "internally" (displaying the protocol in the console) and externally (in the "HOWTO" or other implementation guide(s)) - would help to clarify the issue and take it from a "bug" to a "feature", but as there is currently no such documentation (that I've seen), this behavior is "unexpected" and potentially "breaking" for new BDS administrators.
While I agree that this would likely be better addressed on the feedback site as a suggestion, to be fair, a "bug" is, by definition, any programming "flaw" resulting in behavior that is unintended or unexpected and the term can be applied to include anything from a simple typo on a dialog box to a severe memory leak, etc. I think most first-time users of BDS expect to see a chat log of some sort available for review, whether in the console or in a flat file/database somewhere, so it would probably be beneficial to indicate that such functionality is not included in the BDS platform (at this time?) in the documentation somewhere unless and until the feature is added.
Also, there is currently an open suggestion on the feedback page for this feature for anyone wishing to contribute there: https://feedback.minecraft.net/hc/en-us/community/posts/360027682372-Bedrock-Dedicated-Server-log-chat-to-output-stdout?page=1#community_comment_360009730532
I had the same question about the "extra" ports that show up in the console. Looking at a "netstat -ano" on my machine after starting the server, the two ports (19132 and 19133) defined in my server.properties file are open as TCP ports, while the two other, random ports (usually "5XXXX" or "6XXXX") are open for UDP.
It might be useful to at least indicate this in the console to clear up any confusion. For example:
[2020-03-17 16:07:58 INFO] IPv4 supported, port: 19132 (TCP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 19133 (TCP)[2020-03-17 16:07:58 INFO] IPv4 supported, port: 60896 (UDP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 60897 (UDP)
or some other arrangement of the information, but at least showing what protocol each port is using would be helpful.
As for firewall configuration, if these UDP ports are at least selected from a specific, defined range (i.e., 50000-65535), you may be able to set up your port forwarding for that range for just UDP traffic while setting up a TCP-only forwarding rule for just the ports specified in your server.properties file.
@David Fidler - I'm glad the information was useful/helpful. I'm a firm believer that the more detail we can provide, the better the bug report will be received. Even if the information is superfluous, for a programmer (like me), the more detailed the explanation and definition of the problem, the easier it is to find a solution.
Well, that makes sense, actually. For an extremely simplified example, I liken it to trying to host a Web server on a residential Internet connection. Many ISP's have port 80 blocked to prevent their customers from doing that for a variety of reasons (excess traffic, security concerns, etc.). Still, with a bit of creative port forwarding and communication, one can host a simple Web site on a non-standard port. Since pretty much every Web client defaults it's communication to port 80 for HTTP, the client has to be explicitly told to use a different port (for example, 8080) when trying to access that particular resource. Obviously, with DDNS and even more creativity, it's possible to even get around that, but that goes well beyond the scope of this example.
This is basically what I am assuming (yep 😉) is going on with the Minecraft client. It will only look for servers on the default ports when trying to auto-discover servers. If the server is running on a "non-standard" port, the game client must be explicitly told which port(s) to use for the connection. An admin that wants to run the server on a different port will require the player to go through the "Add Server" dialog to actually connect. Personally, I'm okay with that. I'm not sure how the client would be able to automatically detect servers running on non-standard without scanning all 65K ports in existence (which would open up a whole different set of potential security issues).
Now, it's just a matter of identifying the purpose and function of the two extra "random" ports.