AntiMomentum

When running the ufw rules in that order on the github the port is open. With 0.0.0.0 replaced with a specific ip address of course. iptables is sequential, and the first ufw rule (ufw allow 5901/tcp) already accepts all for 5901 To whitelist that port for a static ip adress (when used with your other rules) replace this rule: ufw allow 5901/tcp with this rule (the ip address here is just an example of course): ufw allow from 45.56.67.78 proto tcp to any port 5901 On a side note: ufw default reject incoming will still send an icmp destination unreachable response back to whatever ip sent the packet. Which can be useful for troubleshooting purposes. However this will just silently drop the packet: ufw default deny incoming

This is a great tutorial for users to begin learning how setup a linux vps. I will say that VNC being less secure than SSH it would probably be good to add more security to it. Perhaps with a firewall rule to whitelist the ip or ips allowed to the 5901 port. Especially running it as root.

2/24 Keepalive has been added to the gateway guided installer scripts for clients. If a wireguard client was able to handshake with the gateway but still having issues despite using halo on port 2302 or default rdp, this Keepalive wireguard setting should fix that. Already made client.conf files can just have this line added to the bottom under the Endpoint line if needed (if you weren't having issues this isn't required): PersistentKeepalive = 10 2/18 update **RDP for Windows** RDP for Windows is finally fixed. RDP to the gateway ip on default rdp port (3389). Currently, RDP will only work for the client peer you use the client1.conf file for (10.0.0.2). To be able to RDP to multiple different Windows peers may involve adding more rules for different rdp ports. However, using a another wireguard client yourself should give access to to any windows peer default rdp port as well. Either method would work, but is not currently tested so I can't say that's support just yet. Eventually I'll have a private halo server version where clients use wireguard to see the Halo server in the LAN list, once that's working being able to RDP to multiple different peers will certainly be working by then. 2/15 update **guided installers for both the gateway and Linux clients.** https://github.com/antimomentum/haloce/tree/master/firewalls/vpngateway/guidedinstall client1.conf is 10.0.0.2 and default halo port 2302. the 2nd client file using 10.0.0.4 can host up to 200 halo servers through its connection. The Wireguard client works on a variety of operating systems, including Windows, and can be integrated with existing setups : https://www.wireguard.com/install/ Concept: Basically one Linux gateway server acts as the public ip for the vpn client halo server. This would be like if you connected to a vpn service, started the halo server, and the halo server showed in the list with the ip of the vpn server and not the machine you actually run halo from. Except in this case it would actually work since you control the firewall of the vpn server Wireguard is a vpn protocol like OpenVPN. VPN providers like NordVPN often use these open source protocols for their services. OpenVPN is more robust and has more developement and setups behind it. However the newer Wireguard protocol performs better (important for fps games) and is more secure on basic setups. It's also pretty quiet by itself. I've personally tested this for halo with both linux and windows clients and these do indeed work through the tunnel Last time I checked the Wireguard client for Android does indeed work as well. I've never hosted a halo server through a phone though, and I wouldn't even consider it without an unlimited data plan, and I would still not recommend it anyways. It would be important that the host you chose for the vpn gateway server is close to the actual halo server. Obviously, the further away the halo server the more latency will increase. I have left a notes page that gets into more of the required information to set this up. IPs you need to allow go in MDNS, ports you need to forward to the client server running halo go in the nat PREROUTING table like the example halo client ports are. https://github.com/antimomentum/haloce/tree/master/firewalls/vpngateway Windows clients will need the master server ip in the hosts file. For Windows this files is at: c:\windows\system32\drivers\etc\hosts add these two lines to the bottom of hosts: 34.197.71.170 hosthpc.com 34.197.71.170 s1.master.hosthpc.com Please read notes carefully, especially the client whitelisting section near the bottom if you decide to give this setup a go. I'd be glad to help answer any questions. Post them here, in DM, or message me on Discord. If asking questions be sure to remove any keys or client ip info.

Oh yeah I already understood that, np though, I was just making the point that that the alternatives would still require something extra such as your Python script anyways. So like in terms of multiple halos on a single vps that's just totally up to preference. Docker in itself is going to be any more useful for halo than writing your own scripts. About literally the only benefit in this case would be that Docker can "pause" containers, but even then only useful if you want to preserve the state of the game while it's empty without using as much resources to keep the container open. And even then I'm not sure how long it can stay paused before something goes wrong with halo. But anyways you're probably already aware of this but regardless of the method for multiple vps: I'd be sure to have a unique identifier for your vps query responses. Like if you did this all via python, a unique key/string personal to your own servers. Or sent through ssh. That way the master controller (especially if it has the ability to spin up a vps and not just halo) isn't simply requiring the source ip to assume the query response is legit.

Yeah Docker would still require a script or two since it has no built in way to tell when Halo servers are full/empty. (Chalwk made a lua script that simply outputs the player count to a file, a separate script on the host such as Python or Bash would still have to watch that/those output files to start new containers/servers based on that. The same would be true for a query approach rather than watching a file). As for shutdowns, maybe I'm a little confused but couldn't you have a tmux session for the script itself in order to kill it without killing the primary server? Or is that not even the issue for shutdowns?

No problem! Are these actual high traffic floods to your server? If so, unfortunately blocking any vpn connection won't stop someone from getting the ip of any public halo server anyways. In order for floods to not happen towards the ip address of your halo server it would have to be a private halo server, and if someone leaks the ip it could get flooded anyways. I haven't used Azure specifically. But pretty much every cloud provider has some type of outside/edge firewall you can put your azure server behind. If it's free to use I recommend using that to block everything except for UDP to the port of your Halo server (default is port 2302) and whatever port you need open access your Azure server (default Linux ssh is TCP to port 22). The provider's outside/edge firewall will filter more efficiently than any firewall running inside a cloud vps. My firewall will still be useful though, just be sure to add your ip to MDNS in my firewall before you run my firewall: ipset add MDNS yourip otherwise my fw would lock you out. You can reboot your server to flush my entire firewall though if needed.

Almost done editing. But for now, this would install Wine on Debian 9 and Ubuntu 18.04 LTS (or higher). All command line no gui, allowing you to host the haloceded.exe server console in Linux. If installing in Ubuntu and not Debian, be sure to comment out/remove this line: echo 'deb http://deb.debian.org/debian stretch-backports main' >> /etc/apt/sources.list Anyways here's the WIne install script: https://github.com/antimomentum/haloce/blob/master/wine/Debian9wineinstall.sh I also have Linux compatible Docker stuff on that Github if you want to containerize your Halo server Now as for Windows no gui I can't say I'm used to Powershell but it should be possible provided you upload working halo server files to the server. And actually I don't think the Halo server even uses an install like the client. So once you have the files on it, the halo server should run. But there is one last nuance to all this regardless of Linux or Windows and that's the file path you start haloceded.exe from. So a Windows CMD or .bat command to open Halo might be: haloceded -path C:\Halo but in the CMD (or Powershell) command line you could cd (change directory) into that Halo folder and use : halocded.exe -path . But what most would do in this case is just put halocded.exe -path . into a .bat file that's located next to haloceded.exe in the same directory because: the dot means relative to whatever folder the command is run from. And the dot is relative in Linux as well. Docker: The github Docker stuff is only tested in Linux. But provided you install Docker and upload your halo server files, the "Dockerfile" placed next to your Halo server folder will build the whole thing into a container. In Ubuntu 18.04 LTS or higher Ubuntu, Docker can usually be install just by doing: apt update apt-get install docker.io In Debian 9 this script uses Docker's official documented way of installing: https://github.com/antimomentum/haloce/blob/master/InstallDockerDebian.sh Here's more on Docker docs: https://docs.docker.com/engine/install/debian/ So an example build (with docker install and halo files ready): docker build -t gussil/haloce . If you make a username on Docker hub (free is fine) you can then upload your containers to the Docker Hub. This way on a new fresh vps all you'd have to do is get Docker install and you'll be able to start your Halo container just by doing a docker run command, and that will even auto download the container too.

classic

Halo Custom Edition in Wine (and probably any version of the h1 gearbox port's server in Wine) are vulnerable to being crashed remotely via a DoS (not DDoS) attack. This effects Halo servers running in Wine. So likely any type of halo server regardless if it's using sapp, phasor, ect but certainly sapp. It does not appear to effect Halo servers in Windows. Thankfully it can be stopped with an iptables rule. Iptables comes with most versions of Linux. Firewalls such as ufw are often just frontends for iptables so if you're using a tool like ufw or firewalld you can always google it to see it's really just using iptables anyways. If you are using different software you'll need to drop packets with a source port of 0. I won't go into exactly how the attack is done but hey, here's a way that will certainly stop it which I'll breakdown in case you're not used to iptables. Here's the rule: iptables -t raw -I PREROUTING -i eth0 -p udp --sport 0 -j DROP Breakdown: -t raw -I PREROUTING will Insert (-I) the rule rather than Append (-A) the rule at the very top of iptables (1st rule). That is to say, it will be the very first rule incoming packets will have to go through regardless of whatever iptables rules you may have. It doesn't matter if you're using ufw, firewalld, Docker, etc. -t raw -I PREROUTING will ensure it is always above the rest of the iptables rules to keep from interfering with or get bypassed by other iptables rules you may already have. As a side note it's now included in the firewall on my github. -i eth0 means packets incoming to interface eth0 (being sent to your server from the internet). Keep in mind, your public facing interface may have a different name than eth0, like enp0s3. A few common commands to find out your interface names: ifconfig ip a Make sure the iptables rule has the correct public interface name if yours is not eth0. -p udp --sport 0 -j DROP Means protocol udp with a source port of 0 drop it. Should you need to receive packets with a source port of 0 to another port for some reason, but still want to protect Halo, you could do a more precise rule such as: iptables -t raw -I PREROUTING -i eth0 -p udp --sport 0 --dport 2302 -j DROP assuming Halo is using port 2302, if not change the dport accordingly.

Go to it in Device Manager, right click, click Scan for Hardware Changes

It has dead hours. Players are typically on about 14 hours before your post up to about the time of your post, so about just over half of each day. Give or take a few hours on either end.

Strange, I use the same install script for Debian 9, Ubuntu 20.04 LTS, Ubuntu 21.04 and Ubuntu 18.04 LTS to install Wine and it runs sapp 10.2.1 with or without UPX. This script installs Wine 5.0 on Ubuntu 20.04, Wine 3.0 in Ubuntu 18, and Wine 1.8.7 on Debian 9 Stretch. But it does correctly run my halo server. https://github.com/antimomentum/haloce/blob/master/Debianwineinstall.sh You may want to remove/comment out the first line if you run this on Ubuntu. Tbh I've forgotten to do that and it still worked in Ubuntu anyways xD In Ubuntu 18.04 LTS I did have to do apt install wine32 manually after running the script. This installs 32bit Wine on 64bit Alpine. This is the only version of 64bit Alpine I've found that would run my halo server correctly: https://github.com/antimomentum/haloce/blob/master/Alpine64bit-3.12-Wine32bitinstaller.sh However i386 versions of Alpine do tend to work too, like the one pulled in the Dockerfile. No UPX sapp files, at the bottom of the page http://halopc.com/sv_extensions/ smol bitmaps.map file if you want it (I use this personally, not required) I also just went ahead and uploaded my server files as an example. halopull.zip *Edit* When Halo server starts it will ask the OS to do dns lookups in both Windows and Linux by default for the master server ip. These two commands will allow the Halo server to skip the dns lookup in Linux, only needs to be run once on a fresh OS: echo "34.197.71.170 hosthpc.com" >> /etc/hosts echo "34.197.71.170 s1.master.hosthpc.com" >> /etc/hosts As a side note Windows has a hosts file as well. **Edit 2** UFW might also be automatically installed on your Linux VPS. UFW (uncomplicated firewall) is a frontend for iptables. This could end up blocking Halo from reaching the master server by default and preventing Halo from booting properly/showing in the list. Try: ufw stop to stop it until reboot or manually started ufw disable to persistently disable it. As a side note the firewall.sh script on my Github requires ufw to be stopped/disabled and to have the master server in hosts (the two echo commands above). More details about my fw are at the top of the firewall sript.

Yeah so mostly/completely just sounds like a path issue. So here's a tip for both Windows and Linux you might already know when starting haloceded.exe, you can add a -path switch to it to force Halo to use one directory, rather than the Documents\My Games\Halo CE it defaults to without a -path switch for sapp files and the mapvotes, commands,etc. So: You have 1 folder named halopull In halopull: A folder named maps A folder named sapp <--alias.txt, commands.txt, events.txt, init.txt (sapp's init), mapcycles.txt ,mapvotes.txt are in this sapp folder. --in the sapp folder there's also the lua folder. You put lua scripts in the lua folder A folder named savegames <---gametypes A folder named saved Then files: haloceded.exe banned.txt init.txt motd.txt sapp.dll Strings.dll All in halopull. You may have more files, that's just a barebones example. As long as "halopull" is in the same directory as "Dockerfile" it will build correctly, as long as your halo paths aren't still mistaken somehow or there isn't something wrong with the files themselves. Also assuming you are using 10.2.1 sapp. In Wine without Docker: you cd into halopull and start halo like this: wineconsole haloceded.exe -path . The Dockerfile essentially starts halo in the container this way too. The dot is relative (for Linux, in Windows i think it's \ for relative path I could be wrong about WIndows though). **Edit 2, Lua** In sapp's init.txt you must have: lua 1 lua_load thescript lua_load race Assuming the lua scripts' file names are thescript.lua and race.lua But I also recommend this in sapp's init too: auto_update 0 network_thread 0 There's also some way to use lua scripts specific to a map in the mapcycle. I'm not sure how exactly that works though maybe there's a post or something about it. Anyways if your issues were just path and lua that all should at least get it to running without crashes. In past experiments I've sometimes had to use this in the sapp init too: max_idle 0 But that's a last resort sort of thing. And I'm not sure how that works either. *Edit* If you want to run multiple halos with just Wine (no Docker) from the same server without having to use an ssh screen for each Halo, you can install "screen". This will allow you to start haloceded.exe detached and you can attach to the halo console later or even make scripts to give halo commands without having to attach to any halo console. Once you have your Halo server working you can do this: apt install screen <--assuming Debian/Ubuntu Here's an example script that would start 2 halo servers from the same files, but on different ports 2302 and 2304: screen -S "halo" -d -m screen -r "halo" -X stuff "cd halopull^M" screen -r "halo" -X stuff "wineconsole haloceded.exe -path .^M" screen -S "2halo" -d -m screen -r "2halo" -X stuff "cd halopull^M" screen -r "2halo" -X stuff "wineconsole haloceded.exe -path . -port 2304^M" You can then attach to them: screen -xr halo or screen -xr 2halo Hold Ctrl A and D to detach. You can even remotely detach another screen if you can't Ctrl A and D, provided you run this from a terminal or screen not already attached to a halo console: screen -d 2halo Or make a script to automatically turn on afk kick after an hour without attaching at all: sleep 3600 screen -r "halo" -X stuff "afk_kick 300^M" The ^M basically means "press enter" to screen. "stuff" is actually part of the screen command.