Getting a Reverse Proxy to Work

[zombibly]

hey everyone, in preparation for the 1.0 launch I've decided to prepare a dedicated server for me and my friends to play on when the game does release. I've got the server running in docker no problem and I'm able to hit it using my internal network IP (192.168.X.X). I was even able to get friends to be able to join when I opened up my router for all ports towards that internal IP. However I don't want to have those ports open all the time and wanted to limit the exposure by using nginx as a reverse proxy on an digital ocean vm.

I know that I've gotten the nginx setup for the most part as when I stop the docker container and run nc on the server for the 15777 port and try to add the server to the server manager using the digital ocean IP I can see that the traffic is making it's way to the server vm. The issue is that if I have the docker container running and try adding the server using the digital ocean IP then I just get a "Server appears to be offline" message. I'm not really sure what could be causing the issue.

TL:DR;
using public vm as a reverse proxy for server.
client -> public proxy -> server
confirmed that traffic is flowing to the server but getting a "server offline" message.

client -> server (using internal IP) OR (using public IP with port forwarding)
server appears online and everyone can connect without issues.

EDIT: I found my issue........ I had proxy_responses 0; set in the nginx facepalm

[o10s]

hey everyone, in preparation for the 1.0 launch I've decided to prepare a dedicated server for me and my friends to play on when the game does release. I've got the server running in docker no problem and I'm able to hit it using my internal network IP (192.168.X.X). I was even able to get friends to be able to join when I opened up my router for all ports towards that internal IP. However I don't want to have those ports open all the time and wanted to limit the exposure by using nginx as a reverse proxy on an digital ocean vm.

I know that I've gotten the nginx setup for the most part as when I stop the docker container and run nc on the server for the 15777 port and try to add the server to the server manager using the digital ocean IP I can see that the traffic is making it's way to the server vm. The issue is that if I have the docker container running and try adding the server using the digital ocean IP then I just get a "Server appears to be offline" message. I'm not really sure what could be causing the issue.

TL:DR; using public vm as a reverse proxy for server. client -> public proxy -> server confirmed that traffic is flowing to the server but getting a "server offline" message.

client -> server (using internal IP) OR (using public IP with port forwarding) server appears online and everyone can connect without issues.

EDIT: I found my issue........ I had proxy_responses 0; set in the nginx facepalm

@zombibly can you share your implementation details please ? I am trying to do the same with traefik

[ShapeShifter499]

Because I found this while searching and actually found a solution that works for me. I might as well help people out and post what works for me. Although I run my Satisfactory on bare metal, I believe it should work just the same here.

At the time of writing this was tested with nginx version: nginx/1.27.4. You must make sure your nginx has the 'stream' module enabled. For Arch Linux it requires an extra package to download, nginx-mainline-mod-stream at the time of writing. It might be different for the OS you use.

Then I added this block, this is outside of the 'http' directives you might set for websites.

# Redirect actual game client to dedicated server 
stream {
# Send the real IP of the client connecting to the game server for logging perposes 
   proxy_bind $remote_addr transparent;

# Backend where Satisfactory is running 
   upstream satisfactory {
      server 10.0.10.21:7777;
   }

# Pass all TCP connections to the backend
   server {
      listen 7777;
      listen [::]:7777;
      proxy_pass satisfactory;
   }

# Pass all UDP connections to the backend
# 'reuseport' for listening on the same port number with different protocols
   server {
      listen 7777 udp reuseport;
      listen [::]:7777 udp reuseport;
      proxy_pass satisfactory;
   }
}

[Unfaehig]

Hey guys,

may be i am a bit late to the party. But i think it will help some other folks. Looking for an answer how to get the server working behind a reverse proxy.

Satisfactory Dedicated Server

networks:
  backend:
    external:
        backend

services:
    satisfactory-server:
        container_name: 'satisfactory'
        hostname: 'satisfactory'
        image: 'wolveix/satisfactory-server:latest'
        volumes:
            - 'YOUR_SERVER_DATA/config:/config'
        environment:
          - MAXPLAYERS=4
          - PGID=...
          - PUID=...
          - STEAMBETA=false
        labels:
          # Only necessary if you not enroll automatically containers
          - "traefik.enable=true"
          # Only necessary if you attach the container to multiple networks
          - "traefik.docker.network=backend"
          - "traefik.http.services.satisfactory.loadbalancer.server.port=7777"
          # Note the dedicated satisfactory server is always running on HTTPS with a self sign cert so use https as sheme
          - "traefik.http.services.satisfactory.loadbalancer.server.scheme=https"
          # Ignore self sign certs when proxy from traefik to dedicated satisfactory server
          - "traefik.http.services.satisfactory.loadBalancer.serverstransport=satisfactory@file"
          # Sadly the next line is not supported as of traefik 3.3.4 and you need instead work with a file based definition
          #- "traefik.http.serverstransports.satisfactory-serverstransports.insecureskipverify=true"
          - "traefik.http.routers.satisfactory.entrypoints=satisfactory-tcp"
          - "traefik.http.routers.satisfactory.rule=Host(`example.com`)"
          - "traefik.http.routers.satisfactory.tls=true"
          - "traefik.http.routers.satisfactory.tls.certresolver=myresolver"
          - "traefik.udp.services.satisfactory.loadbalancer.server.port=7777"
          - "traefik.udp.routers.satisfactory.entrypoints=satisfactory-udp"
        restart: unless-stopped
        deploy:
          resources:
            limits:
              memory: 16gb
        networks:
          - backend

Traefik

services:
  traefik:
    image: traefik:v3.3.4
    container_name: traefik
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
      # We need to expose both protocols here
      - '7777:7777/tcp'
      - '7777:7777/udp'
    command:
      ...
      # Expose the two enpoints for traefik you can also do it in traefik.yaml 
      - "--entryPoints.satisfactory-tcp.address=:7777/tcp"
      - "--entryPoints.satisfactory-tcp.http.redirections.entryPoint.to=satisfactory-tcp"
      - "--entryPoints.satisfactory-tcp.http.redirections.entryPoint.scheme=https"
      - "--entryPoints.satisfactory-udp.address=:7777/udp"
      ....
      # need for server transport defintion
      - "--providers.file.directory=/etc/traefik/conf"
      
      volumes:
        # need for server transport defintion
        - PATH_TO_YOU_CONFS/conf:/etc/traefik/conf:ro
      ...

Transport

We need to define a customized server transport, because we try to proxy from Traefik to Satisfactory dedicated server via https and this will run into issues. Internally it uses an self sign certificate so we need to ignore that.
Sadly as of Traefik 3.3.4 it is only possible to define this server transports via file or Kubernetes. So lets create a file provider (if you not already done it) like shown in the Traefik compose file above.
Now create a file like this and put it into the conf folder we mounted into Traefik:

satisfactory.yaml

http:
  serversTransports:
    satisfactory:
      insecureSkipVerify: true

If you do not want to create a file provider, you can also disable insecureSkipVerify as global config for traefik by adding --serverstransport.insecureskipverify to the commands of Treafik docker compose file.

So now you have a server running with valid certificates. Have fun!

[laurayco]

the hero we needed, I'm trying to get this running on k3s and it's crashing my client (??!) with the stock configuration, going to give this a try.

[Unfaehig]

There is one thing i forget to update in this post since traefik version 3.3.5
You need to do a redirect "--entryPoints.satisfactory-tcp.http.redirections.entryPoint.to=satisfactory-tcp" for the entry point, on you traefik conf. I updated my post above to include this config.
May be this also fix your crash? I haven't tried it with k8s/k3s myself yet.

[laurayco]

Did a lot of trial and error today. To start with, what was happening with the default deployment mentioned in the readme was that I could manage the server just fine but trying to log in and play resulted in an immediate crash on experimental branch. After a bit of digging, I figured out how to get additional ports added to my traefik deployment, and then used the following ingress definitions.

ingress:

# ---
# apiVersion: traefik.io/v1alpha1
# kind: IngressRouteUDP
# metadata:
#   name: satisfactudp
#   namespace: satisfactory
# spec:
#   entryPoints:
#     - satisfactudp
#   routes:
#     - services:
#       - name: satisfactory-udp
#         port: 7777
#         weight: 10

# ---
# apiVersion: traefik.io/v1alpha1
# kind: IngressRouteTCP
# metadata:
#   name: satisfactcp
#   namespace: satisfactory
# spec:
#   entryPoints:
#     - satisfactcp
#   routes:
#   - match: HostSNI(`*`)
#     priority: 10
#     services:
#     - name: satisfactory
#       port: 7777

# ---
# apiVersion: traefik.io/v1alpha1
# kind: IngressRouteTCP
# metadata:
#   name: satisfactmsg
#   namespace: satisfactory
# spec:
#   entryPoints:
#     - satisfactmsg
#   routes:
#   - match: HostSNI(`*`)
#     priority: 10
#     services:
#     - name: satisfactory
#       port: 8888

entry points for traefik

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    additionalArguments:
      #- "--entryPoints.satisfactudp.address=:7777/udp"
      #- "--entryPoints.satisfactcp.address=:7777/tcp"
      #- "--entryPoints.satisfactmsg.address=:8888/tcp"
      #- "--serverstransport.insecureskipverify=true"
      - "--api"
      - "--api.dashboard=true"
      - "--api.insecure=true"
    #ports:
      #satisfactmsg:
      #  port: 8888
      #  expose:
      #    default: true
      #  exposedPort: 8888
      #  protocol: TCP
      #satisfactcp:
        #port: 7777
        #expose:
          #default: true
        #exposedPort: 7777
        #protocol: TCP
      #satisfactudp:
        #port: 7777
        #expose:
          #default: true
        #exposedPort: 7777
        #protocol: UDP

service (similar existed for TCP/7777 & 8888):

# ---
# apiVersion: v1
# kind: Service
# metadata:
#   name: satisfactory-udp
#   namespace: satisfactory
#   labels:
#     app: satisfactory
# spec:
#   ports:
#     - name: "game"
#       port: 7777
#       protocol: UDP
#       targetPort: 7777
#   selector:
#     app: satisfactory

I'm not entirely sure if the 8888 port is still used? wiki says only 7777 is used, this project's documentation and examples still use 8888. But I digress, with this configuration I could not at all get a connection (the game client would exclusively indicate the server is offline / unreachable).

This is all commented out because it's the current state of my files and for tonight I have given up, but if someone else has insights, they would be welcomed, as things get a bit stranger.

Out of curiosity to see if the issue was my kubernetes orchestration or that I'm running the game client in a VM, I used the built-in app store on my truenas scale to deploy a server instance (also experimental branch) - this one works without issue. But the reason I want a server is to play with friends and I don't wish to expose NAS to the internet, so I looked at renting a server. This server also crashed my client upon trying to connect. So of the three deployments of the server, only one worked which is my NAS. Is the game particularly sensitive to latency? Does this sound like the UDP ports might just not be connecting? I'm a bit at my wit's end here. The crash in question triggers an unreal engine crash report prompt and it seems to be a segfault in some network code that I can only speculate about.

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x00000000000000c0

FactoryGameSteam_ReliableMessagingTCP_Win64_Shipping!FReliableMessageProtocolTCPConnection::Tick() [D:\BuildAgent\work\1\UE4\FactoryGame\Plugins\ReliableMessaging\Source\ReliableMessagingTCP\Private\ReliableMessageProtocolTCPServer.cpp:260]
FactoryGameSteam_ReliableMessaging_Win64_Shipping!UReliableMessagingPlayerComponent::TickConnection() [D:\BuildAgent\work\1\UE4\FactoryGame\Plugins\ReliableMessaging\Source\ReliableMessaging\Private\ReliableMessagingPlayerComponent.cpp:67]
FactoryGameSteam_ReliableMessaging_Win64_Shipping!UReliableMessagingSubsystem::Tick() [D:\BuildAgent\work\1\UE4\FactoryGame\Plugins\ReliableMessaging\Source\ReliableMessaging\Private\ReliableMessagingSubsystem.cpp:89]
FactoryGameSteam_Engine_Win64_Shipping!FTickableGameObject::TickObjects() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Engine\Private\Tickable.cpp:153]
FactoryGameSteam_Engine_Win64_Shipping!UGameEngine::Tick() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Engine\Private\GameEngine.cpp:1864]
FactoryGameSteam_FactoryGame_Win64_Shipping!UFGGameEngine::Tick() [D:\BuildAgent\work\1\UE4\FactoryGame\Source\FactoryGame\Private\FGGameEngine.cpp:15]
FactoryGameSteam_Win64_Shipping!FEngineLoop::Tick() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:5864]
FactoryGameSteam_Win64_Shipping!GuardedMain() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Launch\Private\Launch.cpp:188]
FactoryGameSteam_Win64_Shipping!GuardedMainWrapper() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:118]
FactoryGameSteam_Win64_Shipping!LaunchWindowsStartup() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:258]
FactoryGameSteam_Win64_Shipping!WinMain() [D:\BuildAgent\work\1\UE4\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:298]
FactoryGameSteam_Win64_Shipping!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll```

Perhaps this is something that needs its own issue or a bug report to the questions site?