back to listing index

SUCCESS & DETAILS - Server ports to open/fwd :: ARK: Survival Evolved General Discussions

[web search]
Original source (steamcommunity.com)
Tags: port-forwarding ark
Clipped on: 2016-02-29

Login Store Community Support
Change language
View desktop website
Image (Asset 1/9) alt=
© Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries. Privacy Policy  |  Legal  |  Steam Subscriber Agreement  |  Refunds
login  |  language
ARK: Survival Evolved
KriegTiger Image (Asset 4/9) alt= Jun 8, 2015 @ 3:10pm
SUCCESS & DETAILS - Server ports to open/fwd
I've dug this forum six ways to Sunday trying to get it figured out. A dozen half/badly written wiki pages, various people with seemly random success stories, and etc. I've finally got it nailed down, working, and repeatable. Here's the scoop on how to have the ARK server running on your PC, along with a game session connected to it (from the same and/or different systems), and allowing external connections from both LAN and internet.

This post has been edited to make it current, the original experience/post can be found here[pastebin.com]. I will work on experimenting with the ports that have been forwarded to make sure they are the minimum needed to function, but if you see it in this post it is confirmed as functional.

HOW TO:
Original success on 171.74, still works on 190+.
Confirmed for both Windows 7 and Windows 10
iptables command section should work regardless of distro, so long as your IP's and devices are correct.

STEP 1

As other people have referenced around the web, having a server startup .bat file is helpful/essential. Here's mine, executed from:

$STEAM_INSTALL_DIR$\steamapps\common\ARK\ShooterGame\Binaries\Win64\ARKServerStart.bat

start ShooterGameServer.exe TheIsland?QueryPort=27015?SessionName=GenericSessionName?MaxPlayers=10?listen?ServerPassword=ConnectPass?ServerAdminPassword=AdminPass? -nosteamclient -game -server -log
exit

Sadly, I do NOT know what good the extra command options at the end mean, since they don't seem to have made much impact in previous attempts (-nosteamclient, -game, -server, -log). But for right now they don't make the setup fail so I'm leaving them in.

STEP 2 - Windows firewall

Accept it if prompted by windows to allow traffic through the firewall for shootergameserver's exe. Full disclosure - I'm not sure if this next step makes an impact but it certainly can't hurt, as mentioned earlier this is how I'm setup and it's functional for both LAN connections and internet.

Open windows firewall in the control panel and click 'Advanced settings' near the bottom of the left-side pane. Click on 'Inbound Rules' and then 'New Rule' on the right pane, select Port -> UDP -> Specific local ports (enter '4242, 7777, 7778, 26900-26905, 27015-27020, 27215') -> Allow the connection -> (check in all boxes) -> name it what you want (I did 'ARK: Server Ports' just so it gets grouped with the other game entries) ->FINISH

This much configuration allowed LAN connections to join my sessions just fine. So if all you want is LAN, you're done with configuration.

STEP 3 - Internet connection

This will vary depending on your equipment. I personally run a Linux server in my closet with iptables and masquerading/NAT, but the ports are still entirely relevant if not the exact instructions. ANYWAY..

While I was trying to figure out why my LAN connections worked but internet did not, I went through the trouble of doing tcpdump captures on the firewall box and wireshark on my windows system. What I found is that it seems like the game client does a port-knocking technique before the server answers. Ever time my LAN client would look for the server it would hit things in the following order :

$CLIENT QUERY SERVER$ -> 27015, 26900, 27016, 26901, 27017, 26902, 27018, 26903, 27019, 26904, 27020, 26905, 4242, 27215 -> $SERVER FINALLY RESPONDS$

After that last magical '27215' my server would talk back via 27015 and they'd negotiate the password/auth and login. Long story short - I enabled/forwarded these ports to my PC running the server (ALL UDP)

4242
7777-7778
26900-26905
27015-27020
27215

For a point/click interface on your average internet gateway device this should be fairly simple - read your manuals. For my fellow Linux admins out there, here's my iptables ruleset:

NOTE-1 - eth2 is my internet facing device, eth0 is my private network device. Obviously change whatever your own PC IP is out for the 192.168.1.15 down below.

NOTE-2 - my firewall is white-list only, so I have default traffic drop rule at the end. If yours is the other way around (accept all, black list specific things like http and telnet), make sure you don't have these ports blocked by one of your rules, modify accordingly.

iptables -A INPUT -i eth2 -p udp -m udp --dport 4242 -j ACCEPT
iptables -A INPUT -i eth2 -p udp -m udp --dport 7777:7778 -j ACCEPT
iptables -A INPUT -i eth2 -p udp -m udp --dport 26900:26905 -j ACCEPT
iptables -A INPUT -i eth2 -p udp -m udp --dport 27015:27020 -j ACCEPT
iptables -A INPUT -i eth2 -p udp -m udp --dport 27215 -j ACCEPT

NOTE-3 - the above just allows the traffic to hit your world-facing IP without getting dropped. Now we need to allow it to traverse networks with these 'FORWARD' rules (again, because I have a white-list only firewall, any traffic not explicitly allowed is dropped):

iptables -A FORWARD -i eth2 -p udp --destination-port 4242 -d 192.168.1.15 -j ACCEPT
iptables -A FORWARD -i eth2 -p udp --destination-port 7777:7778 -d 192.168.1.15 -j ACCEPT
iptables -A FORWARD -i eth2 -p udp --destination-port 26900:26905 -d 192.168.1.15 -j ACCEPT
iptables -A FORWARD -i eth2 -p udp --destination-port 27015:27020 -d 192.168.1.15 -j ACCEPT
iptables -A FORWARD -i eth2 -p udp --destination-port 27215 -d 192.168.1.15 -j ACCEPT

NOTE-4 - and finally - you need to setup NAT rules to mangle packets so they now how to travel properly to and then have a legitimate return path once they are done. Replace aa.bb.cc.dd with whatever your world-facing IP is.

iptables -t nat -A PREROUTING -p udp -d aa.bb.cc.dd --dport 4242 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A PREROUTING -p udp -d aa.bb.cc.dd --dport 7777:7778 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A PREROUTING -p udp -d aa.bb.cc.dd --dport 26900:26905 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A PREROUTING -p udp -d aa.bb.cc.dd --dport 27015:27020 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A PREROUTING -p udp -d aa.bb.cc.dd --dport 27215 -j DNAT --to-destination 192.168.1.15

ALMOST THERE!!!

Now - before you try to fire up a server and go to town, you'll want to do a couple things:

1 - start the game client, pick 'host/local' and set the server options how you want (difficulty, hardcore, PvE, map, etc). Then instead of picking 'local' you pick 'host' and your client will close and the server will start up. This is important because if you haven't done it before the game will spawn ini files and etc. Give it up to 10 minutes (check task manager for 'shootergameserver' and make sure it's got about 4-5gb memory taken up and that disk read calls are no longer hammering your drive) and then just close the window.

2 - NOW is when you can kick off that .bat file from way back at the beginning. Shortcut it to your desktop or something to save you digging through the folders to find it.

3 - For yourself and LAN folk, you should be able to just start the game client and choose 'Join ARK' and then find the little drop down in the lower left (official, unofficial, etc) and choose 'LAN'. Bingo, you're in. For internet it's a bit more fussy because the public server lists are horrid to search through. Give a link like this to your friends:

steam://connect/aa.bb.cc.dd:27015
(This can be used with LAN IP as well if you want for other LAN clients)

This will target them directly to your system. If they are using normal settings (not low memory) they can login and play immediately. If using one of the alternate bootstrap options is needed - have them login via the URL and create a throw-away character (just hit 'create' for the default caveman), then once they're in the game quit out completely and start through the steam interface and pick the necessary low mem/alt option.

When they want to get back to your system, pick 'My Survivors' rather than 'LAN' from the drop down and their session should be found - once they login just have them get eaten by a dino and they can create a new character on the spot.

I hope this helps a bunch of folk, because it's had me banging my head on the desk for nearly a week and cussing the devs out for not providing documentation. I am a sysadmin for a living so I wasn't going to let this crap defeat skills I've been honing for the past 15 years - :]

DEVS:
If you're reading this - I STILL WANT PROPER DOCUMENTATION but hopefully this will prove useful for getting other people up and running.
Last edited by KriegTiger; Aug 4, 2015 @ 9:35am
Showing 1-5 of 5 comments
CDB - BlackyeloowBR Image (Asset 6/9) alt= Jun 8, 2015 @ 5:31pm 
nice
#1
Inigo Montoya Image (Asset 8/9) alt= Jun 19, 2015 @ 8:36pm 
Thanks,

I've been trying to figure out how to run two servers on two different computers with one external ip address. Haven't been able to get it to work yet because I don't know if I'm able to use any other ports other than 7777-7778 on the external side. I would need to use 7779-7780 for the other server. Anyone have any idea?
#2
KriegTiger Jun 19, 2015 @ 8:58pm 
Originally posted by Inigo Montoya:
Thanks,

I've been trying to figure out how to run two servers on two different computers with one external ip address. Haven't been able to get it to work yet because I don't know if I'm able to use any other ports other than 7777-7778 on the external side. I would need to use 7779-7780 for the other server. Anyone have any idea?

I'm not sure this will be doable, but you could definitely try. The problem lies in the port-knock pattern, which I think is pre-set and initiated by the client. The network sniffing indicated it must complete the sequence (forwarded to the one server) before the server response and you get into a situation where the 'ip_conntrack' module can kick in and help you out with routing packets to similar ports to different destinations.

You could TRY changing step 1 for your second server to have different port arguments and then add rules in the iptables section relevant to the second server's IP/port combination. Perhaps the initial query gets some sort of packet response with the port knock pattern that the connection tracking module could figure out the rest?

To do so - modify the original 'step 1' command line to include this (modify QueryPort, and add Port). I've tested and verified that these two arguments work on the most recent server to do what you want. The tricky bit is the knock pattern destination, as mentioned.

-stuff goes here-?QueryPort=28015?Port=7779?-rest of the command goes here-
#3
Inigo Montoya Jun 19, 2015 @ 9:51pm 
Originally posted by KriegTiger:
Originally posted by Inigo Montoya:
Thanks,

I've been trying to figure out how to run two servers on two different computers with one external ip address. Haven't been able to get it to work yet because I don't know if I'm able to use any other ports other than 7777-7778 on the external side. I would need to use 7779-7780 for the other server. Anyone have any idea?

I'm not sure this will be doable, but you could definitely try. The problem lies in the port-knock pattern, which I think is pre-set and initiated by the client. The network sniffing indicated it must complete the sequence (forwarded to the one server) before the server response and you get into a situation where the 'ip_conntrack' module can kick in and help you out with routing packets to similar ports to different destinations.

You could TRY changing step 1 for your second server to have different port arguments and then add rules in the iptables section relevant to the second server's IP/port combination. Perhaps the initial query gets some sort of packet response with the port knock pattern that the connection tracking module could figure out the rest?

To do so - modify the original 'step 1' command line to include this (modify QueryPort, and add Port). I've tested and verified that these two arguments work on the most recent server to do what you want. The tricky bit is the knock pattern destination, as mentioned.

-stuff goes here-?QueryPort=28015?Port=7779?-rest of the command goes here-

Thanks for the response!

So, I got it to work but I have no idea why it works.

http://arkservers.net/1/search/?term=inflicted.org

Both of those servers are using the same external port 7777 but on the internal side they are on different machines/different internal ip addresses. I'll post what I did in case someone else wants to host two servers on two different machines using one external address.

This is what I have setup on my external firewall:

External firewall port: 7777 -> PVE Windows Machine (192.168.137.190:7777)
External firewall port: 27060 -> PVE Windows Machine (192.168.137.190:27060)

External firewall Port: 7778 -> PVP Linux Machine (192.168.137.195:7778)
External firewall Port: 27080 -> PVP Linux Machine (192.168.137.195:27080)
External firewall Port: 27215 -> PVP Linux Machine (192.168.137.195:27215)
External firewall Port: 4242 -> PVP Linux Machine (192.168.137.195:4242)
External firewall Port: 26900-26905 -> PVP Linux Machine (192.168.137.195:26900-26905)


Edit: I added ?Port=7778 to the command line for the linux server and it did change the external port. It was working with 7777 just fine but I'm going this route since it makes more sense to use different ports.

Thanks for your help KriegTiger

Last edited by Inigo Montoya; Jun 19, 2015 @ 10:38pm
#4
KriegTiger Jun 20, 2015 @ 8:16am 
Originally posted by Inigo Montoya:
Originally posted by KriegTiger:

I'm not sure this will be doable, but you could definitely try. The problem lies in the port-knock pattern, which I think is pre-set and initiated by the client. The network sniffing indicated it must complete the sequence (forwarded to the one server) before the server response and you get into a situation where the 'ip_conntrack' module can kick in and help you out with routing packets to similar ports to different destinations.

You could TRY changing step 1 for your second server to have different port arguments and then add rules in the iptables section relevant to the second server's IP/port combination. Perhaps the initial query gets some sort of packet response with the port knock pattern that the connection tracking module could figure out the rest?

To do so - modify the original 'step 1' command line to include this (modify QueryPort, and add Port). I've tested and verified that these two arguments work on the most recent server to do what you want. The tricky bit is the knock pattern destination, as mentioned.

-stuff goes here-?QueryPort=28015?Port=7779?-rest of the command goes here-

Thanks for the response!

So, I got it to work but I have no idea why it works.

http://arkservers.net/1/search/?term=inflicted.org

Both of those servers are using the same external port 7777 but on the internal side they are on different machines/different internal ip addresses. I'll post what I did in case someone else wants to host two servers on two different machines using one external address.

This is what I have setup on my external firewall:

External firewall port: 7777 -> PVE Windows Machine (192.168.137.190:7777)
External firewall port: 27060 -> PVE Windows Machine (192.168.137.190:27060)

External firewall Port: 7778 -> PVP Linux Machine (192.168.137.195:7778)
External firewall Port: 27080 -> PVP Linux Machine (192.168.137.195:27080)
External firewall Port: 27215 -> PVP Linux Machine (192.168.137.195:27215)
External firewall Port: 4242 -> PVP Linux Machine (192.168.137.195:4242)
External firewall Port: 26900-26905 -> PVP Linux Machine (192.168.137.195:26900-26905)


Edit: I added ?Port=7778 to the command line for the linux server and it did change the external port. It was working with 7777 just fine but I'm going this route since it makes more sense to use different ports.

Thanks for your help KriegTiger

Awesome! Happy to help :] Yeah the various workings are a bit of a mystery, but glad it worked.

I should try trimming out some of my firewall rules and experimenting. If ALL the ports were absolutely necessary, I would imagine that the PvE server you have wouldn't work (unless there's some magic going on with connection tracking that I didn't see with packet sniffer), although if that were true the explicit FORWARD and DNAT rules would (should?) have overridden it.

I may have found something... do you have a uPnP service running anywhere? (enabled on whatever your internet gateway device, or running on your firewall/router system if it's a linux box)?
#5
Showing 1-5 of 5 comments
Per page: 15 30 50

Date Posted: Jun 8, 2015 @ 3:10pm
Posts: 5
© Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries.
Some geospatial data on this website is provided by geonames.org.
Privacy Policy   |  Legal  |  Steam Subscriber Agreement