starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 06:05:57 +03:00

[GH-ISSUE #1099] Rust server port 28015 refused but 28016 open (despite not being port forwarded) #862

New issue

Closed

opened 2026-02-27 02:53:58 +03:00 by kerem · 18 comments

kerem commented

2026-02-27 02:53:58 +03:00

Owner

Originally created by @LordNicoll on GitHub (Oct 5, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1099

I'm pretty sure there must be something I've missed, but external connection to my LGSM server is being refused by the rust server. I switched the ports around the 28015 became open (RCON) and the game port became closed. My server is in the DMZ zone on my router and it's ported forward for most commonly used connection and still doesn't work. I used canyouseeme to test the ports and it comes back closed for 28015 and open for 28016, I tried a few other ones and ditto. Minecraft and SSH work fine. I've tried a few other forums but nobody replied or the replies where asinine so I decided to come here were I've usually had stuff sorted before.
Joshua

Originally created by @LordNicoll on GitHub (Oct 5, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1099 I'm pretty sure there must be something I've missed, but external connection to my LGSM server is being refused by the rust server. I switched the ports around the 28015 became open (RCON) and the game port became closed. My server is in the DMZ zone on my router and it's ported forward for most commonly used connection and still doesn't work. I used canyouseeme to test the ports and it comes back closed for 28015 and open for 28016, I tried a few other ones and ditto. Minecraft and SSH work fine. I've tried a few other forums but nobody replied or the replies where asinine so I decided to come here were I've usually had stuff sorted before. Joshua

kerem closed this issue

2026-02-27 02:53:58 +03:00

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

TCP and UDP protocols act very differently with regard to external testing. canyouseeme is likely doing a full SYN connect on the TCP port, whereas it thinks the UDP port is closed because it doesn't talk Rust's protocol.

tl;dr: Post your details:

./rustserver uf
./rustserver pd

@cedarlug commented on GitHub (Oct 5, 2016): TCP and UDP protocols act very differently with regard to external testing. canyouseeme is likely doing a full SYN connect on the TCP port, whereas it thinks the UDP port is closed because it doesn't talk Rust's protocol. tl;dr: Post your details: ``` bash ./rustserver uf ./rustserver pd ```

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

The server specified both protocols in the details, so I set it to both TCP and UDP. I am aware of how canyouseeme operates, but since you can't test a UDP protocol from a different machine, I use Port Forward's test to confirm it's not open, it confirmed the port 25565 (minecraft) was open on another machine but that port 28015 was not. Given the RCON is open without forwarding I suspect the server has some setting somewhere. I'm rather quite baffled by this, I've never seen this before. There might be some updates to do but I doubt that would prevent the server from being port forwarded correctly. Needless to say all firewalls are off while I trouble shoot this.

./rustserver uf
fetching command_update_functions.sh...OK
[ .... ] Update LGSM rust-server: Updating functions
checking alert.sh...OK
checking check_config.sh...OK
checking check_deps.sh...OK
checking check_glibc.sh...OK
checking check_ip.sh...OK
checking check_logs.sh...OK
checking check_permissions.sh...OK
checking check_root.sh...OK
checking check.sh...OK
checking check_status.sh...OK
checking check_steamcmd.sh...UPDATE
fetching check_steamcmd.sh...OK
checking check_system_dir.sh...OK
checking check_system_requirements.sh...OK
checking command_details.sh...OK
checking command_install.sh...OK
checking command_monitor.sh...OK
checking command_restart.sh...OK
checking command_start.sh...OK
checking command_stop.sh...OK
checking command_update_functions.sh...OK
checking command_update.sh...OK
checking core_dl.sh...OK
checking core_exit.sh...OK
checking core_functions.sh...UPDATE
fetching core_functions.sh...OK
checking core_getopt.sh...UPDATE
fetching core_getopt.sh...OK
checking core_messages.sh...OK
checking core_trap.sh...OK
checking fix.sh...OK
checking fix_steamcmd.sh...OK
checking gsquery.py...OK
checking info_config.sh...UPDATE
fetching info_config.sh...OK
checking info_distro.sh...OK
checking info_glibc.sh...OK
checking info_parms.sh...OK
checking install_complete.sh...OK
checking install_config.sh...OK
checking install_header.sh...OK
checking install_logs.sh...OK
checking install_server_dir.sh...OK
checking install_server_files.sh...UPDATE
fetching install_server_files.sh...OK
checking install_steamcmd.sh...OK
checking logs.sh...OK
checking monitor_gsquery.sh...OK
checking update_steamcmd.sh...OK
[ OK ] Update LGSM rust-server: Updating functions

./rustserver pd
fetching command_postdetails.sh...OK
[ OK ] Postdetails rust-server: Posting details to hastebin.com for 1W

url: http://hastebin.com/qexidiwule

@LordNicoll commented on GitHub (Oct 5, 2016): The server specified both protocols in the details, so I set it to both TCP and UDP. I am aware of how canyouseeme operates, but since you can't test a UDP protocol from a different machine, I use Port Forward's test to confirm it's not open, it confirmed the port 25565 (minecraft) was open on another machine but that port 28015 was not. Given the RCON is open without forwarding I suspect the server has some setting somewhere. I'm rather quite baffled by this, I've never seen this before. There might be some updates to do but I doubt that would prevent the server from being port forwarded correctly. Needless to say all firewalls are off while I trouble shoot this. ./rustserver uf fetching command_update_functions.sh...OK [ .... ] Update LGSM rust-server: Updating functions checking alert.sh...OK checking check_config.sh...OK checking check_deps.sh...OK checking check_glibc.sh...OK checking check_ip.sh...OK checking check_logs.sh...OK checking check_permissions.sh...OK checking check_root.sh...OK checking check.sh...OK checking check_status.sh...OK checking check_steamcmd.sh...UPDATE fetching check_steamcmd.sh...OK checking check_system_dir.sh...OK checking check_system_requirements.sh...OK checking command_details.sh...OK checking command_install.sh...OK checking command_monitor.sh...OK checking command_restart.sh...OK checking command_start.sh...OK checking command_stop.sh...OK checking command_update_functions.sh...OK checking command_update.sh...OK checking core_dl.sh...OK checking core_exit.sh...OK checking core_functions.sh...UPDATE fetching core_functions.sh...OK checking core_getopt.sh...UPDATE fetching core_getopt.sh...OK checking core_messages.sh...OK checking core_trap.sh...OK checking fix.sh...OK checking fix_steamcmd.sh...OK checking gsquery.py...OK checking info_config.sh...UPDATE fetching info_config.sh...OK checking info_distro.sh...OK checking info_glibc.sh...OK checking info_parms.sh...OK checking install_complete.sh...OK checking install_config.sh...OK checking install_header.sh...OK checking install_logs.sh...OK checking install_server_dir.sh...OK checking install_server_files.sh...UPDATE fetching install_server_files.sh...OK checking install_steamcmd.sh...OK checking logs.sh...OK checking monitor_gsquery.sh...OK checking update_steamcmd.sh...OK [ OK ] Update LGSM rust-server: Updating functions ./rustserver pd fetching command_postdetails.sh...OK [ OK ] Postdetails rust-server: Posting details to hastebin.com for 1W - url: http://hastebin.com/qexidiwule

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

Minecraft is TCP. So you might have an issue with just forwarding UDP packets into your DMZ.

To tell, fire up tcpdump and try connecting:

tcpdump -i any udp and port 28015 -n

If you don't see any packets, then the issue is upstream from your server.

@cedarlug commented on GitHub (Oct 5, 2016): Minecraft is TCP. So you might have an issue with just forwarding UDP packets into your DMZ. To tell, fire up tcpdump and try connecting: ``` bash tcpdump -i any udp and port 28015 -n ``` If you don't see any packets, then the issue is upstream from your server.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

I'm afraid my system didn't accept that command listed there, instead returning syntax error. The closed command that would work was sudo tcpdump src port 28015 and udp to which the following output was given.

joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo tcpdump src port 28 015 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes

03:43:52.966597 IP 192.168.1.15.28015 > 207.195.156.178-st-tel.net.65132: UDP, l 03:43:53.781603 IP 192.168.1.15.28015 > c-73-25-20-141.hsd1.or.comcast.net.51749 03:43:54.854802 IP 192.168.1.15.28015 > pool-173-79-110-72.washdc.fios.verizon.n 03:43:55.891536 IP 192.168.1.15.28015 > modemcable091.211-19-135.mc.videotron.ca 03:43:56.978478 IP 192.168.1.15.28015 > 50-245-139-110-static.hfc.comcastbusines 03:43:57.447158 IP 192.168.1.15.28015 > modemcable014.46-56-74.mc.videotron.ca.5 03:43:57.956695 IP 192.168.1.15.28015 > 71-35-127-61.tukw.qwest.net.58846: UDP, 03:44:03.447970 IP 192.168.1.15.28015 > 185.57.30.217.26885: UDP, length 03:44:04.335172 IP 192.168.1.15.28015 > 17.133.dsl.syd.iprimus.net.au.58482: UDP 03:44:04.776264 IP 192.168.1.15.28015 > mat-router1.tisd.net.60946: UDP, length 03:44:05.165166 IP 192.168.1.15.28015 > 223.96.150.250.24233: UDP, length 03:44:05.377607 IP 192.168.1.15.28015 > 171.215.42.184.14110: UDP, length 03:44:05.817418 IP 192.168.1.15.28015 > dynamic-ip-adsl-190.186.67.176.cotas.com 03:44:08.649334 IP 192.168.1.15.28015 > 122-60-209-7.jetstream.xtra.co.nz.64301: 03:44:14.936054 IP 192.168.1.15.28015 > 46-59-170-109.lsn5.wtnet.de.22157: UDP, 03:44:19.748797 IP 192.168.1.15.28015 > S010600fc8dc75193.va.shawcable.net.53336 03:44:20.094628 IP 192.168.1.15.28015 > 70.red-95-120-194.dynamicip.rima-tde.net 03:44:25.962050 IP 192.168.1.15.28015 > 110-174-145-69.static.tpgi.com.au.54358: 03:44:37.029676 IP 192.168.1.15.28015 > 181.174.106.9.34424: UDP, length 03:44:37.703689 IP 192.168.1.15.28015 > pppoe77-82-229-93.kamchatka.ru.64038: UD 03:44:37.894181 IP 192.168.1.15.28015 > 173-31-48-118.client.mchsi.com.60922: UD 03:44:38.301079 IP 192.168.1.15.28015 > cpe-74-76-157-144.nycap.res.rr.com.62786 03:44:40.866447 IP 192.168.1.15.28015 > pool-72-73-113-137.ptldme.east.myfairpoi 03:44:41.418356 IP 192.168.1.15.28015 > 69.156.213.56.60160: UDP, length 03:44:42.294684 IP 192.168.1.15.28015 > c-73-73-208-218.hsd1.il.comcast.net.5178 03:44:47.982858 IP 192.168.1.15.28015 > 217-211-98-77-no181.bredband.skanova.com 03:44:50.313710 IP 192.168.1.15.28015 > broadband-188-32-63-234.nationalcablenet 03:44:50.927172 IP 192.168.1.15.28015 > b1b4af13.virtua.com.br.51521: UDP, lengt 03:44:50.994749 IP 192.168.1.15.28015 > 128-74-46-205.broadband.corbina.ru.54215 03:44:51.516102 IP 192.168.1.15.28015 > 99-49-109-116.lightspeed.tblltx.sbcgloba 03:44:58.459900 IP 192.168.1.15.28015 > 202.sub-70-213-0.myvzw.com.6307: UDP, le 03:44:59.122570 IP 192.168.1.15.28015 > sbr22-h03-89-84-144-233.dsl.sta.abo.bbox 03:44:59.133832 IP 192.168.1.15.28015 > udp258191uds.hawaiiantel.net.54004: UDP, 03:44:59.481743 IP 192.168.1.15.28015 > nat.hi-link.ru.62895: UDP, length 03:45:00.298670 IP 192.168.1.15.28015 > ip-188-113-129-144.z1.ysk.scts.tv.61834: 03:45:00.690766 IP 192.168.1.15.28015 > S0106306023d519a3.wp.shawcable.net.61187 03:45:01.096003 IP 192.168.1.15.28015 > 184.212.151.122.sta.dodo.net.au.52771: U 03:45:01.365419 IP 192.168.1.15.28015 > 42.119.64.193.53529: UDP, length 03:45:02.606455 IP 192.168.1.15.28015 > 184-156-165-243.dyn.centurytel.net.59474 03:45:04.376171 IP 192.168.1.15.28015 > 173-18-64-127.client.mchsi.com.59677: UD 03:45:04.494209 IP 192.168.1.15.28015 > ip68-103-3-123.ks.ok.cox.net.58956: UDP, 03:45:04.848347 IP 192.168.1.15.28015 > udp054211uds.hawaiiantel.net.61090: UDP, 03:45:05.232895 IP 192.168.1.15.28015 > h093177007025.ys.dsl.sakhalin.ru.58822: 03:45:05.350664 IP 192.168.1.15.28015 > 71-218-161-140.hlrn.qwest.net.61290: UDP 03:45:13.432848 IP 192.168.1.15.28015 > user-109-243-47-83.play-internet.pl.6321 03:45:13.502549 IP 192.168.1.15.28015 > d137-186-248-58.abhsia.telus.net.62272: 03:45:16.326992 IP 192.168.1.15.28015 > 101.190.177.219.57748: UDP, length 03:45:18.847823 IP 192.168.1.15.28015 > c-73-254-228-149.hsd1.wa.comcast.net.563 03:45:19.151392 IP 192.168.1.15.28015 > 211.97.127.159.14762: UDP, length ^X^@03:45:19.201110 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 03:45:19.201223 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 9
03:45:19.201327 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 9
03:45:19.411383 IP 192.168.1.15.28015 > sky-78-19-57-73.bas512.cwt.btireland.net 03:45:27.863166 IP 192.168.1.15.28015 > 77.30.254.195.17053: UDP, length 111 ength 111
: UDP, length 111
et.58784: UDP, length 111
.61190: UDP, length 111
s.net.62938: UDP, length 111
9359: UDP, length 111
length 111
111
, length 111
111
111
111
.bo.55626: UDP, length 111
UDP, length 111
length 111
: UDP, length 111
.57290: UDP, length 111
UDP, length 111
111
P, length 111
P, length 111
: UDP, length 111
nt.net.63066: UDP, length 111
111
0: UDP, length 111
.52724: UDP, length 111
works.ru.60079: UDP, length 111
h 111
: UDP, length 111
l.net.50977: UDP, length 111
ngth 111
.fr.51764: UDP, length 111
length 111
111
UDP, length 111
: UDP, length 111
DP, length 111
111
: UDP, length 111
P, length 111
length 111
length 111
UDP, length 111
, length 111
8: UDP, length 111
UDP, length 111
111
64: UDP, length 111
111
111
.59744: UDP, length 111 03 :45:26.804843 IP 192.168.1.15.28015 > 66.sub-70-197-84.myvzw.com.5751: UDP, leng th 111 ^C C

55 packets captured
136 packets received by filter
75 packets dropped by kernel

@LordNicoll commented on GitHub (Oct 5, 2016): I'm afraid my system didn't accept that command listed there, instead returning syntax error. The closed command that would work was sudo tcpdump src port 28015 and udp to which the following output was given. joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo tcpdump src port 28 015 and udp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp5s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes 03:43:52.966597 IP 192.168.1.15.28015 > 207.195.156.178-st-tel.net.65132: UDP, l ength 111 03:43:53.781603 IP 192.168.1.15.28015 > c-73-25-20-141.hsd1.or.comcast.net.51749 : UDP, length 111 03:43:54.854802 IP 192.168.1.15.28015 > pool-173-79-110-72.washdc.fios.verizon.n et.58784: UDP, length 111 03:43:55.891536 IP 192.168.1.15.28015 > modemcable091.211-19-135.mc.videotron.ca .61190: UDP, length 111 03:43:56.978478 IP 192.168.1.15.28015 > 50-245-139-110-static.hfc.comcastbusines s.net.62938: UDP, length 111 03:43:57.447158 IP 192.168.1.15.28015 > modemcable014.46-56-74.mc.videotron.ca.5 9359: UDP, length 111 03:43:57.956695 IP 192.168.1.15.28015 > 71-35-127-61.tukw.qwest.net.58846: UDP, length 111 03:44:03.447970 IP 192.168.1.15.28015 > 185.57.30.217.26885: UDP, length 111 03:44:04.335172 IP 192.168.1.15.28015 > 17.133.dsl.syd.iprimus.net.au.58482: UDP , length 111 03:44:04.776264 IP 192.168.1.15.28015 > mat-router1.tisd.net.60946: UDP, length 111 03:44:05.165166 IP 192.168.1.15.28015 > 223.96.150.250.24233: UDP, length 111 03:44:05.377607 IP 192.168.1.15.28015 > 171.215.42.184.14110: UDP, length 111 03:44:05.817418 IP 192.168.1.15.28015 > dynamic-ip-adsl-190.186.67.176.cotas.com .bo.55626: UDP, length 111 03:44:08.649334 IP 192.168.1.15.28015 > 122-60-209-7.jetstream.xtra.co.nz.64301: UDP, length 111 03:44:14.936054 IP 192.168.1.15.28015 > 46-59-170-109.lsn5.wtnet.de.22157: UDP, length 111 03:44:19.748797 IP 192.168.1.15.28015 > S010600fc8dc75193.va.shawcable.net.53336 : UDP, length 111 03:44:20.094628 IP 192.168.1.15.28015 > 70.red-95-120-194.dynamicip.rima-tde.net .57290: UDP, length 111 03:44:25.962050 IP 192.168.1.15.28015 > 110-174-145-69.static.tpgi.com.au.54358: UDP, length 111 03:44:37.029676 IP 192.168.1.15.28015 > 181.174.106.9.34424: UDP, length 111 03:44:37.703689 IP 192.168.1.15.28015 > pppoe77-82-229-93.kamchatka.ru.64038: UD P, length 111 03:44:37.894181 IP 192.168.1.15.28015 > 173-31-48-118.client.mchsi.com.60922: UD P, length 111 03:44:38.301079 IP 192.168.1.15.28015 > cpe-74-76-157-144.nycap.res.rr.com.62786 : UDP, length 111 03:44:40.866447 IP 192.168.1.15.28015 > pool-72-73-113-137.ptldme.east.myfairpoi nt.net.63066: UDP, length 111 03:44:41.418356 IP 192.168.1.15.28015 > 69.156.213.56.60160: UDP, length 111 03:44:42.294684 IP 192.168.1.15.28015 > c-73-73-208-218.hsd1.il.comcast.net.5178 0: UDP, length 111 03:44:47.982858 IP 192.168.1.15.28015 > 217-211-98-77-no181.bredband.skanova.com .52724: UDP, length 111 03:44:50.313710 IP 192.168.1.15.28015 > broadband-188-32-63-234.nationalcablenet works.ru.60079: UDP, length 111 03:44:50.927172 IP 192.168.1.15.28015 > b1b4af13.virtua.com.br.51521: UDP, lengt h 111 03:44:50.994749 IP 192.168.1.15.28015 > 128-74-46-205.broadband.corbina.ru.54215 : UDP, length 111 03:44:51.516102 IP 192.168.1.15.28015 > 99-49-109-116.lightspeed.tblltx.sbcgloba l.net.50977: UDP, length 111 03:44:58.459900 IP 192.168.1.15.28015 > 202.sub-70-213-0.myvzw.com.6307: UDP, le ngth 111 03:44:59.122570 IP 192.168.1.15.28015 > sbr22-h03-89-84-144-233.dsl.sta.abo.bbox .fr.51764: UDP, length 111 03:44:59.133832 IP 192.168.1.15.28015 > udp258191uds.hawaiiantel.net.54004: UDP, length 111 03:44:59.481743 IP 192.168.1.15.28015 > nat.hi-link.ru.62895: UDP, length 111 03:45:00.298670 IP 192.168.1.15.28015 > ip-188-113-129-144.z1.ysk.scts.tv.61834: UDP, length 111 03:45:00.690766 IP 192.168.1.15.28015 > S0106306023d519a3.wp.shawcable.net.61187 : UDP, length 111 03:45:01.096003 IP 192.168.1.15.28015 > 184.212.151.122.sta.dodo.net.au.52771: U DP, length 111 03:45:01.365419 IP 192.168.1.15.28015 > 42.119.64.193.53529: UDP, length 111 03:45:02.606455 IP 192.168.1.15.28015 > 184-156-165-243.dyn.centurytel.net.59474 : UDP, length 111 03:45:04.376171 IP 192.168.1.15.28015 > 173-18-64-127.client.mchsi.com.59677: UD P, length 111 03:45:04.494209 IP 192.168.1.15.28015 > ip68-103-3-123.ks.ok.cox.net.58956: UDP, length 111 03:45:04.848347 IP 192.168.1.15.28015 > udp054211uds.hawaiiantel.net.61090: UDP, length 111 03:45:05.232895 IP 192.168.1.15.28015 > h093177007025.ys.dsl.sakhalin.ru.58822: UDP, length 111 03:45:05.350664 IP 192.168.1.15.28015 > 71-218-161-140.hlrn.qwest.net.61290: UDP , length 111 03:45:13.432848 IP 192.168.1.15.28015 > user-109-243-47-83.play-internet.pl.6321 8: UDP, length 111 03:45:13.502549 IP 192.168.1.15.28015 > d137-186-248-58.abhsia.telus.net.62272: UDP, length 111 03:45:16.326992 IP 192.168.1.15.28015 > 101.190.177.219.57748: UDP, length 111 03:45:18.847823 IP 192.168.1.15.28015 > c-73-254-228-149.hsd1.wa.comcast.net.563 64: UDP, length 111 03:45:19.151392 IP 192.168.1.15.28015 > 211.97.127.159.14762: UDP, length 111 ^X^@03:45:19.201110 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 111 03:45:19.201223 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 9 03:45:19.201327 IP 192.168.1.15.28015 > 5.62.103.147.36424: UDP, length 9 03:45:19.411383 IP 192.168.1.15.28015 > sky-78-19-57-73.bas512.cwt.btireland.net .59744: UDP, length 111 03 :45:26.804843 IP 192.168.1.15.28015 > 66.sub-70-197-84.myvzw.com.5751: UDP, leng th 111 ^C C 03:45:27.863166 IP 192.168.1.15.28015 > 77.30.254.195.17053: UDP, length 111 55 packets captured 136 packets received by filter 75 packets dropped by kernel

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

Okay - destination port would be better. Can you adjust accordingly and see if you have any ingress packets heading to port 28015?

@cedarlug commented on GitHub (Oct 5, 2016): Okay - destination port would be better. Can you adjust accordingly and see if you have any ingress packets heading to port 28015?

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

I'm sorry, it was a miracle I even managed to fumble my way to that command (I've never used that utility before so getting to grips with all the commands while I'm half asleep isn't easy) whats the command? If I appear to know what I'm doing it's because I've done it before, not because I know what I'm doing.

@LordNicoll commented on GitHub (Oct 5, 2016): I'm sorry, it was a miracle I even managed to fumble my way to that command (I've never used that utility before so getting to grips with all the commands while I'm half asleep isn't easy) whats the command? If I appear to know what I'm doing it's because I've done it before, not because I _know_ what I'm doing.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

tcpdump -i any dst 28015 and udp -n

@cedarlug commented on GitHub (Oct 5, 2016): ``` bash tcpdump -i any dst 28015 and udp -n ```

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

There doesn't seem to be anything in the output of that command.

joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo tcpdump -i any dst 28015 and udp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

@LordNicoll commented on GitHub (Oct 5, 2016): There doesn't seem to be anything in the output of that command. joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo tcpdump -i any dst 28015 and udp -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

That would indicate that your upstream firewall isn't forwarding UDP packets.

The outgoing packets of your previous post show that your server is actively making connections outbound, but the issue is getting packets to come back in.

You've already verified that TCP packets are being correctly forwarded, so dig into the config and either duplicate the rules for UDP, or set the existing rules to honor both TCP and UDP.

@cedarlug commented on GitHub (Oct 5, 2016): That would indicate that your upstream firewall isn't forwarding UDP packets. The outgoing packets of your previous post show that your server is actively making connections outbound, but the issue is getting packets to come back in. You've already verified that TCP packets are being correctly forwarded, so dig into the config and either duplicate the rules for UDP, or set the existing rules to honor both TCP and UDP.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.15:28016 0.0.0.0:* LISTEN 21865/RustDedicated
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1396/sshd
tcp6 0 0 0.0.0.0:25565 :::* LISTEN 21113/java
tcp6 0 0 :::22 :::* LISTEN 1396/sshd
udp 0 0 0.0.0.0:34604 0.0.0.0:* 1193/avahi-daemon:
udp 0 0 192.168.1.15:3309 0.0.0.0:* 21865/RustDedicated
udp 0 0 192.168.1.15:28015 0.0.0.0:* 21865/RustDedicated
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1193/avahi-daemon:
udp 0 0 0.0.0.0:68 0.0.0.0:* 1316/dhclient
udp6 0 0 :::5353 :::* 1193/avahi-daemon:
udp6 0 0 :::41715 :::* 1193/avahi-daemon:

I checked a lot of settings there and found no reason why it shouldn't work. The server hasn't been rebooted in a week though, the rust server hasn't been there that long but it's too noisy to reboot now (it's 0431 am where I am) because it's an actual HP ProLiant rack server, the POST takes like 90 seconds with a 30-40 second fan blast, so I'll reboot tomorrow and look through the buried settings. There are no firewalls active on the router or server to my knowledge, the router firewall is disabled and the servers iptable service is disabled.

@LordNicoll commented on GitHub (Oct 5, 2016): joshadmin@Demon-Sword-Ragnarok-Server-101-B:~/steamcmd$ sudo netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.1.15:28016 0.0.0.0:\* LISTEN 21865/RustDedicated tcp 0 0 0.0.0.0:22 0.0.0.0:\* LISTEN 1396/sshd tcp6 0 0 0.0.0.0:25565 :::\* LISTEN 21113/java tcp6 0 0 :::22 :::\* LISTEN 1396/sshd udp 0 0 0.0.0.0:34604 0.0.0.0:\* 1193/avahi-daemon: udp 0 0 192.168.1.15:3309 0.0.0.0:\* 21865/RustDedicated udp 0 0 192.168.1.15:28015 0.0.0.0:\* 21865/RustDedicated udp 0 0 0.0.0.0:5353 0.0.0.0:\* 1193/avahi-daemon: udp 0 0 0.0.0.0:68 0.0.0.0:\* 1316/dhclient udp6 0 0 :::5353 :::\* 1193/avahi-daemon: udp6 0 0 :::41715 :::\* 1193/avahi-daemon: I checked a lot of settings there and found no reason why it shouldn't work. The server hasn't been rebooted in a week though, the rust server hasn't been there that long but it's too noisy to reboot now (it's 0431 am where I am) because it's an actual HP ProLiant rack server, the POST takes like 90 seconds with a 30-40 second fan blast, so I'll reboot tomorrow and look through the buried settings. There are no firewalls active on the router or server to my knowledge, the router firewall is disabled and the servers iptable service is disabled.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

The problem exists upstream from your server. Your server setup is fine.

You need to lay hands on the system that's managing packets between your 192.168.1.0/24 network and the gateway to the world. That's where the issue lies.

(The issue lies in your router.)

@cedarlug commented on GitHub (Oct 5, 2016): The problem exists upstream from your server. Your server setup is fine. You need to lay hands on the system that's managing packets between your 192.168.1.0/24 network and the gateway to the world. That's where the issue lies. (The issue lies in your router.)

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

That would be the router then. It's a wireless access point gateway and router combi, there are like a million settings deep inside that thing, it's a Huawei HG658c and a pain to deal with but it's not a bad router, but it was free from the ISP (Vodafone)

@LordNicoll commented on GitHub (Oct 5, 2016): That would be the router then. It's a wireless access point gateway and router combi, there are like a million settings deep inside that thing, it's a Huawei HG658c and a pain to deal with but it's not a bad router, but it was free from the ISP (Vodafone)

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@cedarlug commented on GitHub (Oct 5, 2016):

Look for where you already have TCP packet rules. Then either use them as a template for the exact same rules with UDP, or augment the existing rules to apply to both TCP and UDP

@cedarlug commented on GitHub (Oct 5, 2016): Look for where you already have TCP packet rules. Then either use them as a template for the exact same rules with UDP, or augment the existing rules to apply to both TCP and UDP

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

I think this has reached the level of which I am not able to work out the issue, I am quite inexperienced and ignorant to networking at this level. Maybe I'm too tired for it. I'll have another look tomorrow but I don't think there are any TCP/UDP rules to edit beyond the settings, again I'm ignorant to a lot of that.

@LordNicoll commented on GitHub (Oct 5, 2016): I think this has reached the level of which I am not able to work out the issue, I am quite inexperienced and ignorant to networking at this level. Maybe I'm too tired for it. I'll have another look tomorrow but I don't think there are any TCP/UDP rules to edit beyond the settings, again I'm ignorant to a lot of that.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@testler2 commented on GitHub (Oct 5, 2016):

Hello, What is the cause of the problem?

[ OK ] Debug rust-server: Starting debug
/home/rustserver/lgsm/functions/command_debug.sh: line 103: ./RustDedicated: No such file or directory
rustserver@server:~$

@testler2 commented on GitHub (Oct 5, 2016): Hello, What is the cause of the problem? [ OK ] Debug rust-server: Starting debug /home/rustserver/lgsm/functions/command_debug.sh: line 103: ./RustDedicated: No such file or directory rustserver@server:~$

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@LordNicoll commented on GitHub (Oct 5, 2016):

I do not fully know, but it is likely on the router side of my set up, there must be some setting hidden in that hideous pile of settings.

@LordNicoll commented on GitHub (Oct 5, 2016): I do not fully know, but it is likely on the router side of my set up, there must be some setting hidden in that hideous pile of settings.

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@UltimateByte commented on GitHub (Nov 9, 2016):

Guessing this is solved now.
Come to discord or steam forum if you need more help, linking to this issue ;)

@UltimateByte commented on GitHub (Nov 9, 2016): Guessing this is solved now. Come to discord or steam forum if you need more help, linking to this issue ;)

kerem commented

2026-02-27 02:53:59 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 19, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 19, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:53:41 +03:00

[PR #944] [MERGED] Raminfo #3210