Proxmox MineOS VM not accepting local client connections

[saunders1m]

Hi,

I really hate to ask though I cannot see my issue solved on google or within the forums here :o(

Problem: I am unable to join to my newly created MineOS server (running as a VM) from a local PC client.

Setup:
Client OS: Windows 10 running Minecraft
IP: 192.168.20.52

Guest Server: MineOS (latest version)
Host OS: Proxmox
IP: 172.16.0.2

The client is on a separate network to the MineOS server in a local home environment and a local FW is providing the Network Boundary between both LAN’s.

The FW has an open (permissive) rule running bi -directional between both LAN’s.

I am not trying to get port forwarding set up as at the moment as the server is hosted locally within a household.

Issue: Minecraft on the Client PC has been configured to join the VM MineOS server with the following details:
Server Name: foo
Server Address: 172.16.0.2
Port: 25565
RAM:6GB
HDD:20GB

Java Mods:
-Xmx - Set to 512MB
-Xms - Set to 512MB
Additional Commands: -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false

I have tried to force Java to not bind sockets to IPV6 which was happening originally and this seems to have taken effect as denoted in the netstat output example below.

Troubleshooting Steps:

MineOS Server Setup:

1. IPTables has been configured as follows. I have added UDP as a destination protocol for reasons explained shortly.

root@mineos ~# iptables -L
Chain INPUT (policy DROP)
_target prot opt source destination _
_ACCEPT all – anywhere anywhere _
ACCEPT tcp – anywhere anywhere tcp dpt:ssh
ACCEPT tcp – anywhere anywhere tcp dpt:8443
ACCEPT tcp – anywhere anywhere tcp dpt:25565
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
ACCEPT udp – anywhere anywhere udp dpt:25565

Chain FORWARD (policy ACCEPT)
_target prot opt source destination _

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

2. Netstat shows the following on the MineOS server. UDP:22565 is not bound to any socket as denoted by it’s absence below:

_root@mineos ~# netstat -a _
Active Internet connections (servers and established)
_Proto Recv-Q Send-Q Local Address Foreign Address State _
_tcp 0 0 *:ssh : LISTEN _
_tcp 0 0 localhost:smtp : LISTEN _
_tcp 0 0 *:8443 : LISTEN _
_tcp 0 0 *:25565 : LISTEN _
_tcp 0 0 localhost:12319 : LISTEN _
_tcp 0 0 *:12320 : LISTEN _
tcp 0 0 *:12321 : LIST

3. Running a TCPDUMP on MineOS whilst getting the client to try and connect shows the following:

root@mineos ~# tcpdump -i eth0 host 192.168.20.52
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:21:07.223192 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1464
11:21:07.223234 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556
11:21:07.732477 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1464
11:21:07.732507 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556
11:21:08.241406 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1464
11:21:08.241430 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556
11:21:08.751598 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1464
11:21:08.751621 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556
11:21:09.259937 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1172
11:21:09.259974 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556
11:21:09.768327 IP 192.168.20.52.62172 > 172.16.0.2.25565: UDP, length 1172
11:21:09.768366 IP 172.16.0.2 > 192.168.20.52: ICMP 172.16.0.2 udp port 25565 unreachable, length 556

Anaylsis

I have tried using different profiles and have copied profiles to the live server. The Server shows to be up and running with no issues and the log output shows the following:

[11:50:18] [Server thread/INFO]: Starting minecraft server version 1.12.2
[11:50:18] [Server thread/WARN]: To start the server with more ram, launch it as “java -Xmx1024M -Xms1024M -jar minecraft_server.jar”
[11:50:18] [Server thread/INFO]: Loading properties
[11:50:18] [Server thread/INFO]: Default game type: SURVIVAL
[11:50:18] [Server thread/INFO]: Generating keypair
[11:50:18] [Server thread/INFO]: Starting Minecraft server on *:25565
[11:50:18] [Server thread/INFO]: Using epoll channel type
[11:50:18] [Server thread/INFO]: Preparing level “world”
[11:50:18] [Server thread/INFO]: Loaded 488 advancements
[11:50:18] [Server thread/INFO]: Preparing start region for level 0
[11:50:19] [Server thread/INFO]: Preparing spawn area: 56%
[11:50:20] [Server thread/INFO]: Done (1.650s)! For help, type “help” or “?”
>

Server Properties are set as follows:

_Server:Port = 25565_
Server.IP = _

From what I can see, Layer 3 connectivity is correctly in place between client and server. The server see’s incoming UDP requests from the client to DST Port 25565 and responds with an ICMP unreachable stating UDP port 25565 is unreachable. This I think ties in with the output from the Netstat command above which does not show that UDP:25565 as being bound to a network socket.

I don’t really understand the inner workings of Minecraft or how it interacts with a server though I am trying to get this working for my kids and their friends as they are desperate to create a local server to play together.

I am sure I am overlooking something though just cannot see what I am missing other then suspecting Java is not setting up correctly and or creating the correct network socket to listen for incoming requests from a local Minecraft instance running on a Windows 10 machine.

Any pointers or help would be really appreciated !!

Cheers

Matt

[Serephucus]

I’ll admit my networking isn’t up to snuff, and it sounds like you know what you’re doing more than I do, but:

Is there a reason you have the server on a different network? It seems like this could be part of the issue. You mentioned that “a local FW is providing the Network Boundary between both LAN’s”, and I’ll admit I don’t know what this means, but I’m assuming it’s some sort of bridge to pass the comms over. Maybe try sticking the server on 192.168.20.x as well, if only to rule that out?

[saunders1m]

Hi Serephucus,

Yes that’s worth a shot to be honest as putting both client and server on the same LAN would in essence rule out any Layer 3 network boundaries.

The local network setup is quite complex in my scenario, though to answer your question as to why the server is on a different network, it’s because I have segregated some server equipment I use for other purpose.

In essence the setup comprises a pair a serves running Proxmox in a cluster.

Both servers are running Proxmox which contain a number of guest Operating Systems. I have created a number of different local Networks which are used purely within this virtualised environment, so I use a separate external FW to segregate this environment and the rest of the home network.

Notwithstanding this, the FW has a simple rule allowing all flows originating from the home Network to the new MineOS server. I can see traffic originating from the Minecraft client when I try to set up and join the MineOS server though it seems that the client is trying some sort of discovery using UDP.

MineOS see’s this from the client and is replying with an ICMP unreachable (which based on the ‘type’ of ICMP message, in this case it’s a type 3 code 3) implies that the server is not listening for this type of connection, as this particular message implies a destination port is closed.

This message is received back on the client as I ran a packet capture on the client which is why I am thinking the bit in the middle (FW) is not the culprit.

I will definitely give your suggestion a go as i think it would rule out the FW from the equation.

Interestingly I did see a reference on another forum somewhere that Minecraft actually performs a discovery technique prior to joining a server. I can see within Server Settings on MineOS that there is a system setting called ‘enable-query’. This is currently set to False though I have changed this to ‘True’ however it did not make a difference.

Any idea’s on how Minecraft actually joins a server and whether their is this discovery process as that might explain why Minecraft is sending out these UDP based queries. I can’t seem to find much on the internet about the actual session flow between Minecraft clients and hosting servers :o(

It will take a me a day or so to get the client moved on the same LAN as the MineOS server and will report back my finding.

Thanks again !

Matt

[Serephucus]

Ok, cheers. Your setup makes more sense now. Haven’t used Proxmox myself (though I’ve heard good things). I’ve only had basic exposure to ESXi and Server 2016 clustering.

As to what actually happens in terms of clients joining a server, I haven’t a clue. My networking knowledge is probably the weakest part for me - I’m mostly a hardware guy - and my Linux isn’t a lot better. I can just about manage moving around directories and changing firewall rules via terminal.

Since it seems like things are working on the Network layer but don’t get to Transport, maybe it’s the port rules? Have you tried simply restarting iptables? I doubt that’s it to be honest, but who knows? Easy fix if it is.

[gen_turgidson]

Whats with the underscores in the IPTABLES output before your line that is set to all – anywhere anywhere? You could also turn IPTABLES off long enough to see if that is still getting in the way.

Does the firewall not recognize the traffic coming back from the server as permited traffic? Is there and inbound rule set for the interface hosting the Proxmox server?

The idea of putting the Proxmox on the same network to test is a good one but I understand why you have the L3 seperation.

[saunders1m]

Hi gen_turgidson

So the underscores within IPTables represent the opt columns. The formatting itself is not great though parsing IPTABLES -L shows the following columns:

target prot opt source destination

The underscores denote no options are set…

I have turned IPTables off which made no difference. For reference this was achieved using the following guide:

http://forums.debian.net/viewtopic.php?t=112759

root@mineos ~# iptables-save > /root/firewall.rules
_root@mineos ~# _
_root@mineos ~# more /root/firewall.rules _
# Generated by iptables-save v1.4.21 on Mon Oct 16 22:09:38 2017
*filter
:INPUT DROP [552:35126]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [878126:64885258]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25565 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 25565 -j ACCEPT
COMMIT
# Completed on Mon Oct 16 22:09:38 2017

root@mineos ~# iptables -F
root@mineos ~# iptables -X
root@mineos ~# iptables -t nat -F
root@mineos ~# iptables -t nat -X
root@mineos ~# iptables -t mangle -F
root@mineos ~# iptables -t mangle -X
root@mineos ~# iptables -P INPUT ACCEPT
root@mineos ~# iptables -P OUTPUT ACCEPT
root@mineos ~# iptables -P FORWARD ACCEPT
root@mineos ~# iptables -L

Chain INPUT (policy ACCEPT)
_target prot opt source destination _

Chain FORWARD (policy ACCEPT)
_target prot opt source destination _

Chain OUTPUT (policy ACCEPT)
_target prot opt source destination _
_root@mineos ~#

In terms of FW rule’s, there is a bi directional rule both ways to cover any responses initiated from the server upon receipt of a packet from the client.

I have performed a check by putting the client onto the same LAN as the server so as to remove the FW fro the equation and I also disabled IPTables.

I can see the server receives the originating request from the client as follows:

root@mineos ~# tcpdump -i eth0 host 172.16.0.3 and not host 172.16.0.255
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:56:02.633654 IP 172.16.0.3.58467 > 172.16.0.2.25565: UDP, length 33
21:56:07.324694 ARP, Request who-has 172.16.0.2 (22:66:02:d2:28:7d (oui Unknown)) tell 172.16.0.3, length 46
21:56:07.324704 ARP, Reply 172.16.0.2 is-at 22:66:02:d2:28:7d (oui Unknown), length 28

I can see on the client using wireshark the following:

No. Time Source Destination Protocol Length Info
_ 18 4.103451 172.16.0.3 172.16.0.2 RakNet 75 Unconnected Ping_

Frame 18: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0
Ethernet II, Src: Universa_6f:bf:43 (00:24:7e:6f:bf:43), Dst: 22:66:02:d2:28:7d (22:66:02:d2:28:7d)
Internet Protocol Version 4, Src: 172.16.0.3, Dst: 172.16.0.2
_ 0100 … = Version: 4_
_ … 0101 = Header Length: 20 bytes (5)_
_ Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)_
_ Total Length: 61_
_ Identification: 0x634d (25421)_
_ Flags: 0x00_
_ Fragment offset: 0_
_ Time to live: 128_
_ Protocol: UDP (17)_
_ Header checksum: 0x0000 [validation disabled]_
_ [Header checksum status: Unverified]_
_ Source: 172.16.0.3_
_ Destination: 172.16.0.2_
_ [Source GeoIP: Unknown]_
_ [Destination GeoIP: Unknown]_
User Datagram Protocol, Src Port: 58467, Dst Port: 25565
_ Source Port: 58467_
_ Destination Port: 25565_
_ Length: 41_
_ Checksum: 0x5860 [unverified]_
_ [Checksum Status: Unverified]_
_ [Stream index: 2]_
RakNet game networking protocol, Offline message ID 0x1
_ RakNet Offline Message ID: Unconnected Ping (0x01)_
_ RakNet Time since start (ms): 277550567_
_ RakNet Offline message data ID: 00ffff00fefefefefdfdfdfd12345678_
_ RakNet Client GUID: 05b0004097f2616b_

No. Time Source Destination Protocol Length Info
_ 37 9.110427 172.16.0.3 172.16.0.2 RakNet 75 Unconnected Ping_

Frame 37: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0
Ethernet II, Src: Universa_6f:bf:43 (00:24:7e:6f:bf:43), Dst: 22:66:02:d2:28:7d (22:66:02:d2:28:7d)
Internet Protocol Version 4, Src: 172.16.0.3, Dst: 172.16.0.2
_ 0100 … = Version: 4_
_ … 0101 = Header Length: 20 bytes (5)_
_ Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)_
_ Total Length: 61_
_ Identification: 0x6352 (25426)_
_ Flags: 0x00_
_ Fragment offset: 0_
_ Time to live: 128_
_ Protocol: UDP (17)_
_ Header checksum: 0x0000 [validation disabled]_
_ [Header checksum status: Unverified]_
_ Source: 172.16.0.3_
_ Destination: 172.16.0.2_
_ [Source GeoIP: Unknown]_
_ [Destination GeoIP: Unknown]_
User Datagram Protocol, Src Port: 58467, Dst Port: 25565
_ Source Port: 58467_
_ Destination Port: 25565_
_ Length: 41_
_ Checksum: 0x5860 [unverified]_
_ [Checksum Status: Unverified]_
_ [Stream index: 2]_
RakNet game networking protocol, Offline message ID 0x1
_ RakNet Offline Message ID: Unconnected Ping (0x01)_
_ RakNet Time since start (ms): 277555574_
_ RakNet Offline message data ID: 00ffff00fefefefefdfdfdfd12345678_
_ RakNet Client GUID: 05b0004097f2616b_

No. Time Source Destination Protocol Length Info
_ 56 14.117034 172.16.0.3 172.16.0.2 RakNet 75 Unconnected Ping_

Frame 56: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0
Ethernet II, Src: Universa_6f:bf:43 (00:24:7e:6f:bf:43), Dst: 22:66:02:d2:28:7d (22:66:02:d2:28:7d)
Internet Protocol Version 4, Src: 172.16.0.3, Dst: 172.16.0.2
_ 0100 … = Version: 4_
_ … 0101 = Header Length: 20 bytes (5)_
_ Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)_
_ Total Length: 61_
_ Identification: 0x6358 (25432)_
_ Flags: 0x00_
_ Fragment offset: 0_
_ Time to live: 128_
_ Protocol: UDP (17)_
_ Header checksum: 0x0000 [validation disabled]_
_ [Header checksum status: Unverified]_
_ Source: 172.16.0.3_
_ Destination: 172.16.0.2_
_ [Source GeoIP: Unknown]_
_ [Destination GeoIP: Unknown]_
User Datagram Protocol, Src Port: 58467, Dst Port: 25565
_ Source Port: 58467_
_ Destination Port: 25565_
_ Length: 41_
_ Checksum: 0x5860 [unverified]_
_ [Checksum Status: Unverified]_
_ [Stream index: 2]_
RakNet game networking protocol, Offline message ID 0x1
_ RakNet Offline Message ID: Unconnected Ping (0x01)_
_ RakNet Time since start (ms): 277560580_
_ RakNet Offline message data ID: 00ffff00fefefefefdfdfdfd12345678_
_ RakNet Client GUID: 05b0004097f2616b_

I think Wireshark is interpreting the response using Raknet’s interpretation (Unconnected Ping) though I cant’ be sure if Wireshark is masking the ICMP response or not.

Raknet have the following info which describes an unconnected ping as:

_Ping from an unconnected system. Only reply if we have open connections. Do not update timestamps. (internal use only)

http://www.raknet.net/raknet/manual/networkmessages.html

If anybody can run a packet capture on their MineOS server to see what requests are received / responses sent back then I can figure out if their is a protocol mismatch at the transport layer ?

Thanks again…

Matt

[gen_turgidson]

Another question about your setup. What is the version of Minecraft you are using in Windows 10? It should be the java version and not the Windows 10 version which uses the communication stack that is used in MCPE aka Bedrock Edition from my quick reading.

Minecraft doesn’t talk on udp so I don’t think that line is needed in iptables. MCPE does talk on udp which is another flag.

I run a couple of small servers, monitored through SNMP (udp/161) and a dynmap (tcp/8123) on one VM instance so I have a few extra ports open.

My iptables-rules file

# Generated by iptables-save v1.4.21 on Sun Jan 15 01:30:54 2017
:INPUT DROP [56:4115]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10914:3351356]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p udp -m udp --dport 161 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25565 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25566 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25567 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sun Jan 15 01:30:54 2017

Can you run nmap against the minecraft server and see what ports it responds on?

command line

nmap -p 22,8443,25565 -sV -sS -T4 172.16.0.2

Does Proxmox have a host server firewall that protects the virtualized host that are on the server?

[saunders1m]

Ah ok - I wasn’t aware of the different flavours of Minecraft tbh. The household are running Minecraft on two x Windows Laptops (running Windows 10) and an Xbox one.

Having just fired Minecraft up on the laptop it states it is Version 1.2.2. I did purchase this from the windows 10 store which simply stated it was (Minecraft for Windows 10).

Given what you have stated above it does look like Minecraft for Windows 10 was indeed a port of the pocket edition though I had no idea their were cross platform barriers :o(

Differences between Minecraft: W10 EB and Java Minecraft

I thought the inclusion of the server option meant it would simply work with MineOS as a server though that is my lack of knowledge :o(

I have run nmap as requested (thanks for that) which produces the following:

Starting Nmap 7.00 ( https://nmap.org ) at 2017-10-17 21:50 BST
Nmap scan report for 172.16.0.2
Host is up (0.015s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
8443/tcp open ssl/http Node.js Express framework
25565/tcp open minecraft Minecraft 1.12.2 (Protocol: 127, Message: Icecold JJS World of War, Users: 0/20)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

It looks like your on the right lines I think given my port is listening on TCP 25565 and not UDP.

A real shame tbh though I have just run a cursory search for Win10 Minecraft (java edition) and it looks like that edition also allows the purchaser to run Windows 10 Pocket Edition.

I guess I will need to convince Microsoft to let me buy the right version now :o)

Thanks again gen_turgidson I think you have probably solved this for me :o)

[gen_turgidson]

I believe there are some threads on here about running a Bedrock/MCPE compatible server in MineOS.
See here.

Good luck!

[Serephucus]

As far as I’m aware, Win10 Minecraft is incompatible with the “Java Edition” of Minecraft. You might be able to get a server going with MineOS, but none of your PCs running Minecraft (with the exception of the Win10 versions) will be able to see it.

[saunders1m]

Thanks I will give that a review !

Cheers

Matt

[iMelsom]

The pocketmine style servers work with the Pocket Edition style clients (win10 ver, smartphones, pads, consoles etc…). With the exeption of PS4, these are cross platform. The pocket edition servers are not official, and lack a lot of functionality, like an AI for mobs (which also means that mobs are disabled and do not generate). Pocketmine is basically only for creative. Since pocketmine servers need to reverse engineer pocket edition clients each time Mojang/Microsoft updates, the servers are usually released a while after an client update is released. This also means these types of servers never really comes out of any sort of “alpha”-test phase, and are prone to (no, let me refrase: are riddled with) bugs of variable seriousness.

Minecraft server only works with the java versions of minecraft ( Windows PC, Mac, Linux), but are official, and comes with all bells and whistles attached. The different plugin and mod based servers are based on the official minecraft java server.