Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 4949 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Ark survival dedicated server behind UTM problems

Koetje Boe

I migrated this weekend to the UTM 9 in my home network.

Although the learning curve was steep in the beginning i managed to get almost everything working beside 1 problem that is starting to drive me crazy.

I got a Ark Survival server behind my firewall that was working before. I had forward rules in my iptables firewall that was directly connected to the internet (and served as router/gateway/firewall) and everyone could connect to it and the server itself was able to update through steam services. (steamcmd from the server to steam cloud)

I almost tried about everything by now but 2 things keep being a pain in the below part.

- The server itself cannot update

- Nobody from outside can connect to the server

 

I will explain here what i did and how i troubleshooted the problem.

First of all what is working:

- I can connect to the server from my lan

- I can update on my pc (so not the server but my client) from steam cloud.

 

I created a nat DNAT rule (and also tried SNAT) for port 7777, 7778 and 270000:27050 to be forwarded to the server ip on the inside with all tcp/udp with automatic firewall rule added.

i have a masq rule that everything from inside can access the outside (the ark server is on the inside)

I have tried with and without webfilter/IPS and other services but nothing seems to change.

I did test from the outside (remote ip) to the udp port and they seem to be open. I also tried to see if the ports were open from the inside to the server mentioned in the logs but they said they were open too.

I created a pcap of the server trying to connect but didnt get any wiser from it.

In the logs there is no mention of the server anywhere (on the UTM) being dropped or doing something it is not liked. It does not appear in any of the statistics that it is doing something with the datasteam.

 

This is the log from the server side of port 7777 (game port) (it repeats the connection disconnected on a timeout base)

[2017-04-11 10:59:33] [0,0] StartAutoReconnect() will start in 0 seconds^M
[2017-04-11 10:59:33] [1,4466] Connect() starting connection (eNetQOSLevelLow, 162.254.197.40:27017, UDP)
[2017-04-11 10:59:34] [1,4466] ConnectionCompleted() (162.254.196.40:27018, UDP)^M
[2017-04-11 10:59:34] [1,4466] RecvMsgClientLogOnResponse() : [A:1:2323342340:8396] 'OK'^M
[2017-04-11 10:59:59] [0,0] ConnectionDisconnected('I/O Operation Failed') : 'OK' (162.254.196.40:27018, UDP)^M
[2017-04-11 10:59:59] [0,0] (null)^M
[2017-04-11 10:59:59] [0,0] StartAutoReconnect() will start in 0 seconds^M
[2017-04-11 10:59:59] [1,4468] Connect() starting connection (eNetQOSLevelLow, 162.254.197.40:27017, UDP)
[2017-04-11 10:59:59] [1,4468] ConnectionCompleted() (162.254.196.41:27019, UDP)^M
[2017-04-11 11:00:00] [1,4468] RecvMsgClientLogOnResponse() : [A:1:2323342340:8396] 'OK'^M

 

This is from the ark server update:

[2017-04-10 22:12:38] Log session started
[2017-04-10 22:12:38] [0,0] SetSteamID( [U:1:0] )
[2017-04-10 22:12:38] [0,0] SetSteamID( [U:1:0] )
[2017-04-10 22:12:38] [0,0] SetSteamID( [a:1:0] )
[2017-04-10 22:12:38] [1,2] Connect() starting connection (eNetQOSLevelHigh, 162.254.197.42:27021, UDP)
[2017-04-10 22:12:38] [1,2] ConnectionCompleted() (162.254.197.42:27020, UDP)
[2017-04-10 22:12:39] [1,2] RecvMsgClientLogOnResponse() : [a:1:1165940759] 'OK'
[2017-04-10 22:13:00] [0,0] ConnectionDisconnected('I/O Operation Failed') : 'OK' (162.254.197.42:27020, UDP)
[2017-04-10 22:13:00] [0,0] StartAutoReconnect() will start in 0 seconds
[2017-04-10 22:13:00] [1,6] Connect() starting connection (eNetQOSLevelLow, 162.254.197.42:27021, UDP)
[2017-04-10 22:13:01] [1,6] ConnectionCompleted() (162.254.196.43:27017, UDP)
[2017-04-10 22:13:02] [1,6] RecvMsgClientLogOnResponse() : [a:1:1166425197] 'OK'

 

My deduction is that it is trying to connect with UDP to the steam cloud (162.x.x.x range) but somehow cannot get a good connection. I manual tried these port with nmap and they seem to be open. So my guess is that the stream it is trying to set up is blocked on the UTM for some reason.

Any help is really appropriated. I got some experience with paulo alto and other state-full firewalls but htis one is getting a bit over my head as I don't have any logging to work with.

Koetje

 

 

 



This thread was automatically locked due to age.
Parents
  • 0

    Here is a screenshot of the pcap i made. you see connections from inet to the server and from server to inet without a problem (at least to me it seems that way)

  • 0 in reply to Koetje Boe

    Not giving up I installed the game at a remote location and finally got lucky.

     

    It bounches on a default drop just at them moment the client gets its information.

    Now for the big question ... where is the "steam" protocol mentioned here stored and how do i make an exception to it.

    AFAIK there is no "steam" definition available when i try to make an exception but please proof me wrong.

  • 0 in reply to Koetje Boe

    Okay I fixed it.

    Before revealing how I need to say that this is one of those problems that you overlook easily.

    I got triggered on an artical on this forum about MTU sizes and checked my outgoing finding it was 576. This was caused by the DHCP asking the MTU size from the provider which replies this value. Changing it to 1500 doesnt work in the gui as with the next dhcp it will just move back to to old value.

    So I found this thread with the explanation on how to change this annoying behavior in the UTM.

    I will paste here below but credits go to the original creator.

     

    This is what you need to do to disable the usage of MTU from DHCP. Beware, you will be touching the system, and also.. it will not update MTU based on any DHCP.

    (I'm not telling you how to get into the UTM, if you don't know... you have no business being there... better wait for the fix.)

    In the 

    /var/chroot-dhcpc/etc

    There is a file named: default.conf

    cat default.conf

    interface "[<INTERFACE>]" {
    timeout 20;
    retry 60;
    script "/usr/sbin/dhcp_updown.plx";
    request subnet-mask, broadcast-address, time-offset,
    routers, domain-name, domain-name-servers, host-name,
    domain-search, nis-domain, nis-servers,
    ntp-servers, interface-mtu;
    [<HOSTNAME>]
    }

    "interface-mtu" : If you remove that (not the following ;!!!), and take your interface down/up, your MTU is possible to edit by hand again in the GUI.

    AND ... it will use the number you give it, not the dumb MTU value one of your ISP's let be in their equipment because they did not bother to change it.

    There was only 1 difference with the upper guid and that was that the value interface-mtu had square brackets like it was now a parameter but because I couldnt fix it in the Gui i changed it anyway and removed the whole parameter including the square brackets

     

    Ark server is now working and this will propably also work beter with Netflix but I didnt test it yet.

     

Reply
  • 0 in reply to Koetje Boe

    Okay I fixed it.

    Before revealing how I need to say that this is one of those problems that you overlook easily.

    I got triggered on an artical on this forum about MTU sizes and checked my outgoing finding it was 576. This was caused by the DHCP asking the MTU size from the provider which replies this value. Changing it to 1500 doesnt work in the gui as with the next dhcp it will just move back to to old value.

    So I found this thread with the explanation on how to change this annoying behavior in the UTM.

    I will paste here below but credits go to the original creator.

     

    This is what you need to do to disable the usage of MTU from DHCP. Beware, you will be touching the system, and also.. it will not update MTU based on any DHCP.

    (I'm not telling you how to get into the UTM, if you don't know... you have no business being there... better wait for the fix.)

    In the 

    /var/chroot-dhcpc/etc

    There is a file named: default.conf

    cat default.conf

    interface "[<INTERFACE>]" {
    timeout 20;
    retry 60;
    script "/usr/sbin/dhcp_updown.plx";
    request subnet-mask, broadcast-address, time-offset,
    routers, domain-name, domain-name-servers, host-name,
    domain-search, nis-domain, nis-servers,
    ntp-servers, interface-mtu;
    [<HOSTNAME>]
    }

    "interface-mtu" : If you remove that (not the following ;!!!), and take your interface down/up, your MTU is possible to edit by hand again in the GUI.

    AND ... it will use the number you give it, not the dumb MTU value one of your ISP's let be in their equipment because they did not bother to change it.

    There was only 1 difference with the upper guid and that was that the value interface-mtu had square brackets like it was now a parameter but because I couldnt fix it in the Gui i changed it anyway and removed the whole parameter including the square brackets

     

    Ark server is now working and this will propably also work beter with Netflix but I didnt test it yet.

     

Children
No Data