Houmi

I had another question for you -- when I used to run the Valheim dedicated server on a PC, it used to print a bunch of logs on stdout / cmd prompt where I ran the server. On the Docker logs, the logs are minimal. Is there a way to turn up the verbosity ? Thanks!

No other game servers, I just have your docker for Valheim + Plex going through Wireguard. Thanks for the 64319 port explanation, figured it might be something Steam related. Yes, it was outbound. I think Valheim connections were via TLS v1.2, though I may be mistaken. I really didn't want to bring in Wireshark to check on this, I do enough of that at work, but when I saw it was working in Lan, I knew something wasn't exposed correctly. Thanks again for your hard work on Unraid, I think I use another container you made as well (the NVidia driver one which is very helpful for Plex hw transcoding) But yeah the server seems to work and my friends can access it from the EU. Can this docker container be used for other Steam games like "V Rising" for example ?

For whatever reason the container wasn't being routed through the vpn (when I checked via curl ifconfig.io) but after restart it did. It looks like it's working now and as you suggested the display has nothing to do with ports being exposed. Thanks for your work on this docker container!

I can connect from LAN np, it's from the outside. Since I am behind CGNAT I can't do a regular port forwarding like others so I go through a tunnel via wireguard and do port forwarding myself. I did a wireguard trace between my home PC and NAS during a Valheim connection and I do see udp connections on 2456 , but I also see another udp connection 64319 which I didn't know Valheim uses. What do you mean game servers use their own proprietary protocol, what is there besides udp/tcp ? Anyways I found another udp port scanner from outside and 2456,2457 are open so it's probably something else I need to look for.

Hi, I installed the Valheim server using macvlan custom eth0: (192.168.50.18) , but unlike my other docker containers on custom et0, this one doesn't show anything, is there anything that needs to happen before IP is shown ? I went to the console and installed net-tools and it seems the IP is valid root@f282f8f29240:/# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.50.18 netmask 255.255.255.0 broadcast 192.168.50.255 ether 02:42:c0:a8:32:12 txqueuelen 0 (Ethernet) RX packets 6671 bytes 10280494 (9.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1842 bytes 215092 (210.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 The reason I need custom et0: is because I am behind CGNAT and use Wireguard to port forward to IP:Port I have this kind of setup working correctly with Plex, so I was going to use the same kind of method with Valheim server. Edit: So I it looks like Valheim Server is indeed running and I can connect to it from Steam from another PC in Lan, and I also transferred my World Data files to it and it loads fine. But it's a bit odd that the IP/Port does not show up in the docker dashboard. The real issue is that I can't see the Valheim Server from the outside, https://portchecker.co/ also fails to see the ports being open (works on Plex), I have made sure for my VPN to allow those ports (2456-2458) to be forwarded and the router is configured correctly to listen on wgclient to forward those ports to the Valheim docker IP. But I feel like something is off in the docker container when used with Custom eth0: because when I go the docker allocations I see this: Valheim eth0 192.168.50.18 ???? <-- for ports

Thanks @trurl , I went ahead and changed everything per that document... using custom eth0: now

Hey @JorgeB , I had to go back to macvlan. Reasoning is that I want some of my containers to run on br0 having their own IP. My Router's Wireguard needs a unique Mac Address to put those IP/Mac Address to use VPN (like Plex) MacVlan creates unique Mac Addresses for those br0 instances. When I put it on IPVLAN, all containers on br0 shared the same Mac Address with the host and I didn't want that.

Thank you very much @JorgeB , I noticed the system was unresponsive yesterday as well. It's interesting these things just started happening recently. I just made the switch.

Jan 5 18:56:28 Tower kernel: ------------[ cut here ]------------ Jan 5 18:56:28 Tower kernel: WARNING: CPU: 1 PID: 13603 at net/netfilter/nf_conntrack_core.c:1210 __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Jan 5 18:56:28 Tower kernel: Modules linked in: xt_nat xt_tcpudp nvidia_uvm(PO) macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter xfs md_mod zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) tcp_diag inet_diag ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs af_packet 8021q garp mrp bridge stp llc bonding tls nvidia_drm(PO) nvidia_modeset(PO) intel_rapl_msr intel_rapl_common iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm nvidia(PO) mei_pxp mei_hdcp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel btusb sha512_ssse3 btrtl aesni_intel drm_kms_helper crypto_simd btbcm btintel cryptd wmi_bmof intel_wmi_thunderbolt mxm_wmi rapl intel_cstate drm intel_uncore nvme i2c_i801 bluetooth e1000e i2c_smbus nvme_core i2c_core mei_me syscopyarea sysfillrect sysimgblt mei video ahci ecdh_generic input_leds Jan 5 18:56:28 Tower kernel: led_class ecc libahci fb_sys_fops joydev wmi backlight intel_pmc_core button acpi_pad unix Jan 5 18:56:28 Tower kernel: CPU: 1 PID: 13603 Comm: kworker/u16:1 Tainted: P O 6.1.63-Unraid #1 Jan 5 18:56:28 Tower kernel: Hardware name: System manufacturer System Product Name/MAXIMUS VIII HERO ALPHA, BIOS 3801 03/14/2018 Jan 5 18:56:28 Tower kernel: Workqueue: events_unbound macvlan_process_broadcast [macvlan] Jan 5 18:56:28 Tower kernel: RIP: 0010:__nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Jan 5 18:56:28 Tower kernel: Code: 44 24 10 e8 e2 e1 ff ff 8b 7c 24 04 89 ea 89 c6 89 04 24 e8 7e e6 ff ff 84 c0 75 a2 48 89 df e8 9b e2 ff ff 85 c0 89 c5 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 18 dd ff ff e8 93 e3 ff ff e9 72 01 Jan 5 18:56:28 Tower kernel: RSP: 0018:ffffc90000154d98 EFLAGS: 00010202 Jan 5 18:56:28 Tower kernel: RAX: 0000000000000001 RBX: ffff8881cf57eb00 RCX: 80d6b68f374d667c Jan 5 18:56:28 Tower kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881cf57eb00 Jan 5 18:56:28 Tower kernel: RBP: 0000000000000001 R08: e6eea51f8de62d21 R09: 0102eb91e5109e49 Jan 5 18:56:28 Tower kernel: R10: 0045d5a4c4398db9 R11: ffffc90000154d60 R12: ffffffff82a14d00 Jan 5 18:56:28 Tower kernel: R13: 000000000002a5d6 R14: ffff88810312b900 R15: 0000000000000000 Jan 5 18:56:28 Tower kernel: FS: 0000000000000000(0000) GS:ffff88884ec40000(0000) knlGS:0000000000000000 Jan 5 18:56:28 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 5 18:56:28 Tower kernel: CR2: 0000000002935000 CR3: 000000000420a003 CR4: 00000000003706e0 Jan 5 18:56:28 Tower kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 5 18:56:28 Tower kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 5 18:56:28 Tower kernel: Call Trace: Jan 5 18:56:28 Tower kernel: <IRQ> Jan 5 18:56:28 Tower kernel: ? __warn+0xab/0x122 Jan 5 18:56:28 Tower kernel: ? report_bug+0x109/0x17e Jan 5 18:56:28 Tower kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Jan 5 18:56:28 Tower kernel: ? handle_bug+0x41/0x6f Jan 5 18:56:28 Tower kernel: ? exc_invalid_op+0x13/0x60 Jan 5 18:56:28 Tower kernel: ? asm_exc_invalid_op+0x16/0x20 Jan 5 18:56:28 Tower kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Jan 5 18:56:28 Tower kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack] Jan 5 18:56:28 Tower kernel: ? nf_nat_inet_fn+0x60/0x1a8 [nf_nat] Jan 5 18:56:28 Tower kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack] Jan 5 18:56:28 Tower kernel: nf_hook_slow+0x3a/0x96 Jan 5 18:56:28 Tower kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Jan 5 18:56:28 Tower kernel: NF_HOOK.constprop.0+0x79/0xd9 Jan 5 18:56:28 Tower kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Jan 5 18:56:28 Tower kernel: __netif_receive_skb_one_core+0x77/0x9c Jan 5 18:56:28 Tower kernel: process_backlog+0x8c/0x116 Jan 5 18:56:28 Tower kernel: __napi_poll.constprop.0+0x28/0x124 Jan 5 18:56:28 Tower kernel: net_rx_action+0x159/0x24f Jan 5 18:56:28 Tower kernel: __do_softirq+0x126/0x288 Jan 5 18:56:28 Tower kernel: do_softirq+0x7f/0xab Jan 5 18:56:28 Tower kernel: </IRQ> Jan 5 18:56:28 Tower kernel: <TASK> Jan 5 18:56:28 Tower kernel: __local_bh_enable_ip+0x4c/0x6b Jan 5 18:56:28 Tower kernel: netif_rx+0x52/0x5a Jan 5 18:56:28 Tower kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Jan 5 18:56:28 Tower kernel: ? _raw_spin_unlock+0x14/0x29 Jan 5 18:56:28 Tower kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Jan 5 18:56:28 Tower kernel: process_one_work+0x1a8/0x295 Jan 5 18:56:28 Tower kernel: worker_thread+0x18b/0x244 Jan 5 18:56:28 Tower kernel: ? rescuer_thread+0x281/0x281 Jan 5 18:56:28 Tower kernel: kthread+0xe4/0xef Jan 5 18:56:28 Tower kernel: ? kthread_complete_and_exit+0x1b/0x1b Jan 5 18:56:28 Tower kernel: ret_from_fork+0x1f/0x30 Jan 5 18:56:28 Tower kernel: </TASK> Jan 5 18:56:28 Tower kernel: ---[ end trace 0000000000000000 ]---

@Linguafoeda If you're behind CGNAT, you need a Commercial VPN with port forwarding or a VPS with your own VPN with port forwarding setup. Once you find that provider and setup port forwarding on their page. You have 3 options 1) Setup VPN for the whole system on Unraid 2) Setup VPN for the docker containers only on Unraid (a hassle to pass other containers through it because of port sharing) 3) Setup VPN on a capable router that has port forwarding (I use a Glinet)

Yep, it seems that Torguard is indeed having its web traffic blocked randomly... I tried to find a bunch of proxy sites and found one https://proxysite.us/ that worked and via that one all the sites I couldn't reach worked. It's weird though it's not a complete block, many websites work, but some don't (like ipleak, dnsleak and such I wanted to test my VPN) -- I have a personal VPS and will be moving my VPN to the VPS soon, so hopefully this won't be an issue anymore. Thanks for all your help!

It's possible that the Wireguard gateway is blocking, but I am using other apps on it that work for download & including Plex (both ways). I could run a wireshark but that will only show me requests going through wg0 and not once going through the tunnel. I'll play around with it, and if I discover what it is, I'll post here my finding.

Looking at Chrome processes, to see if there is anything peculiar, I see this (mostly because I see vnc connects unencrypted when launching chrome) chrome 1084 67 0 10:26 ? 00:00:00 /usr/bin/python3 /usr/bin/websockify -D --web=/usr/share/novnc/ --cert=/etc/ssl/novnc.pem 8080 localhost:5900 Do you know what it does ? Also when I look, there is no file on the Unraid: /etc/ssl/novnc.pem

So I finally figured this out per this Reddit Post: the reason was that I needed to add these port mappings for Plex when connected to wg0.

Yeah you're right, it works fine w/o Wireguard. The only thing I noticed when connecting to wg0, the 8080 port in unraid is being used for the main gui I think, so I redirected it in settings to a different port. 172.31.200.4:8080 <-> TCP 192.168.50.250:8081 Once the app start (btw what is this VNC thing ? the actual Chrome process is located elsewhere ?) , I can go to google and search for anything in Google, but if I click any link it sits forever and nothing happens. I opened network inspection in developer mode and it seems to be doing some initial requests like curl does, but gets cancelled eventually. Interestingly some sites work, like maybe 10-20% of the sites depending on them like google, wikipedia, bing it's as if there is a firewall on the vpn's wg0 blocking some requests for browsing.