NAT Reflection Issue for a VM running on TrueNAS
-
@SlackerDude said in NAT Reflection Issue for a VM running on TrueNAS:
Using No-IP, I have created a dynamic hostname for each server, Plex and ARK. I can provide those if you would like to see that it is possible to reach both from outside my local network. Without the logins, you will likely get no further than seeing they are in fact, reachable.
No need for that, as I think it's clear that things are working from that perspective.
I mean, you have already verified that your NAT rules are in order since people can access and play on your server. And the rules do look right based on the pictures you have posted as well.
However, the testing I suggested with Plex will not work unfortunately. To access Plex from a webbrowser internally, you have to use the internal IP. In the apps on the phone and other devices, Plex will use your account to login at Plex to get the right WAN IP for your server. So, forget that test, my bad!
And I tested and verified that the loopback rules are actually created and removed automatically when you activate or deactivate NAT Reflection for 1:1 NAT and automatic outbound NAT for Reflection in System > Advanced > Firewall & NAT.
This means there has to be something else going on that is messing things up. It could perhaps be something in the ARK server setup, but since the instructions are to activate loopback, it should work.
Do you have any other service running that you could test towards? Anything you could quickly install on TrueNAS that you can try. One thing to note though, is that many applications do require you to add a list of trusted proxies or sources, even for internal IP's.
Again, ARK seems fine in that regard.
BTW, exactly how are you testing ARK here? Are you actually trying to play the game on a PC, or are you still looking at what the ARK Management SW is showing?I guess it could be a good idea to implement Host override as suggested by @viragomann earler (split dns as you wrote). And you say you have set that up but it's not working either?
I have not used that myself, before, but it looks like it's quite straight forward. And in fact it is something I need to look into for my own use I think.
Some quick tests shows it working for me though. And I noticed you don't even need a real domain hostname from e.g. NO IP. You can make one up as long as you end it with something "real", like .com .org etc.All you need to set up would be something like (under Services > Resolver):
Using my.arkserver.com with internal IP 10.10.5.206 as an exampleHost : my
Domain : arkserver.com
IP : 10.10.5.206
Description : optionalDon't enter any port numers here, the application will add them as needed.
-
@Gblenn said in NAT Reflection Issue for a VM running on TrueNAS:
I guess it could be a good idea to implement Host override as suggested by @viragomann earler (split dns as you wrote).
Not sure, if this really would help here. As the screenshot above shows, the ARK server manager obviously determines the public IP itself. Or is it manually entered? If not I suspect, it does this by an uplook to a service, giving back the public IP.
So possibly the server hands out the public IP to the client to connect to. In this case, NAT (reflection) would be the only way to get local clients work, if any.
Maybe you succeed if the client and server are within separated network segments. In this case, pure NAT reflection should be sufficient. -
@viragomann said in NAT Reflection Issue for a VM running on TrueNAS:
@Gblenn said in NAT Reflection Issue for a VM running on TrueNAS:
I guess it could be a good idea to implement Host override as suggested by @viragomann earler (split dns as you wrote).
Not sure, if this really would help here. As the screenshot above shows, the ARK server manager obviously determines the public IP itself. Or is it manually entered? If not I suspect, it does this by an uplook to a service, giving back the public IP.
So possibly the server hands out the public IP to the client to connect to. In this case, NAT (reflection) would be the only way to get local clients work, if any.
Maybe you succeed if the client and server are within separated network segments. In this case, pure NAT reflection should be sufficient.I think you are right about the ARK server manager determining the public IP itself. But I'm quite sure it does not provide any information to the clients. In fact, I don't think the game client interacts with the server manager at all.
Typically these tools are open source projects developed by enthusiast users/players and are not affiliated with the game developers. The purpose of the tool is to leverage e.g. Steam tool to simplify deployment and management of game servers. The manager SW will itself log into the game server once it's up and running and you can use the UI to execute commands from the tool instead of typing commands into the console on the server.
This is why I'm curious if @SlackerDude has tested by trying to run game, rather than relying on the information shown on the management tool.
Starting the game on a PC, you can typically select if you want to play on LAN or Internet.
In both cases you often have the option enter a server IP yourself. Alternatively, you let the game search for available servers and you select from that list. These lists are provided by the game developers main server(s). And the game servers that @SlackerDude has deployed, most likely have announced themselves to these servers and provided their public IP. So selecting them from that list, would be like trying to access from the outside = loopback.Based on this, I'm thinking that host override should work as well. And if you can enter the IP manually in the game, you could type the actual IP, use the NOIP domain or a completely made up one used in pfsense Host override.
-
@Gblenn Thanks for sticking with me on this, I do appreciate it!
Plex is a bit finicky, but provides an internal method to determine whether the is a usable connection to the outside world:
To test ARK, I took a laptop with Steam and the ARK game installed, to another location and accessed the game. Once in the game, I went to an obelisk location (could have used a transmitter instead) and selected to travel to another server, or map. I could see both of the other servers/maps. I cannot see them when inside the local network.
As for the Host override, I created a dynamic host on the No-IP site and set up a Host Override using it and the local IP of the ARK server:
EDIT: Point of note - Just to see if it would work now (never did before port forwarding was set), I removed the three ARK servers from the Steam client (added by entering the local IP of the server and the port of the respective server: 10.10.5.206:2701, 27023, & 27027) and added them using the dynamic host (slackergamers.servegame.com and the port number) I found they all were recognized and that I could log into the game as before, but still not be able to travel from server to server.
Yes, I know I am essentially plastering everything about my network out in the open here, but I suppose it will serve as a good test of whether I set up the IDS correctly. (lol)
If I ever get this thing nailed down, you can be sure I will craft a "For Dummies" step-by-step (with pictures) of exactly how to make this all work, for anyone else who had or is having trouble with what should be a simple thing.
-
@SlackerDude said in NAT Reflection Issue for a VM running on TrueNAS:
@Gblenn Thanks for sticking with me on this, I do appreciate it!
Plex is a bit finicky, but provides an internal method to determine whether the is a usable connection to the outside world:
Yeah, that's what I meant when I said there is no way to test NAT reflection using Plex, since you never use your external IP in the way necessary for that test. You log in to www.plex.tv, not your own domain, and it directs you back...
To test ARK, I took a laptop with Steam and the ARK game installed, to another location and accessed the game. Once in the game, I went to an obelisk location (could have used a transmitter instead) and selected to travel to another server, or map. I could see both of the other servers/maps. I cannot see them when inside the local network.
Ok so this is when testing from the outside, and this "travelling between servers" can happen in game I assume? Which sounds like something quite specific to this type of game, unlike e.g. CoD where you exit the server and find a new one to play on.
As for the Host override, I created a dynamic host on the No-IP site and set up a Host Override using it and the local IP of the ARK server:
EDIT: Point of note - Just to see if it would work now (never did before port forwarding was set), I removed the three ARK servers from the Steam client (added by entering the local IP of the server and the port of the respective server: 10.10.5.206:2701, 27023, & 27027) and added them using the dynamic host (slackergamers.servegame.com and the port number) I found they all were recognized and that I could log into the game as before, but still not be able to travel from server to server.
Is this also how you tested reflective with NAT, before adding host override ? And this part proves that host override is actually working I suppose. And like I wrote, you can put whatever you want as host and parent domain. It doesn't have to be a real one from NOIP... since it's internal only.
But you are also saying that originally you had all three servers entered into the Steam client using the internal IP and the respective ports. Were then you able to travel between servers within the game?
Yes, I know I am essentially plastering everything about my network out in the open here, but I suppose it will serve as a good test of whether I set up the IDS correctly. (lol)
Now you mention IDS... do you also have IPS activated? If so, have you checked the blocked hosts logs for anything related to the Steam client, when you tested reflective NAT I mean? It could be as simple as blocking of the DNS lookup based on some "Emerging Threats "suspicios domain lookup rule" or anything like that.
-
@Gblenn said in NAT Reflection Issue for a VM running on TrueNAS:
Is this also how you tested reflective with NAT, before adding host override ? And this part proves that host override is actually working I suppose. And like I wrote, you can put whatever you want as host and parent domain. It doesn't have to be a real one from NOIP... since it's internal only.
My test of removing the existing servers & adding them using the hostname occurred after I had added the host override
But you are also saying that originally you had all three servers entered into the Steam client using the internal IP and the respective ports. Were then you able to travel between servers within the game?
No, At no point have I been able to travel between servers from inside the local network. The ARK Server Manager continues to display "Availability: Available - No Loopback".
"Available" indicates the servers are available to the outside network, including server-to-server travel.
"No loopback" indicates the servers are available to the local network, but no server-to-server travel. -
@SlackerDude said in NAT Reflection Issue for a VM running on TrueNAS:
But you are also saying that originally you had all three servers entered into the Steam client using the internal IP and the respective ports. Were then you able to travel between servers within the game?
No, At no point have I been able to travel between servers from inside the local network. The ARK Server Manager continues to display "Availability: Available - No Loopback".
"Available" indicates the servers are available to the outside network, including server-to-server travel.
"No loopback" indicates the servers are available to the local network, but no server-to-server travel.Ok that is a little bit strange, that you wouldn't be able to play LAN only... But I found an explanation stating the following which sounds reasonable:
Technically your game client requests a list of servers. That includes the servers running on your server - BUT the IP of those servers is your public or WAN address. The game client then tries to talk with that public or WAN address, but the router knows that the WAN address is NATed to your internal server and thus sends the client request directly to the internal address of the server [10.10.5.206 in your case].
The server talks back to the client request (directly - cause it is on the LAN), and the client doesn't know what to do with replies from a LAN IP when it has sent requests to the WAN IP of the server. So no connection can be made. Loopback NAT makes the traffic on the LAN directed at the WAN IP flow through the router which knows who sent what to who and who is replying to who, and then things work as expected.One thing to investigate might be server settings, if it is possible to instruct them to accept LAN IP as well.
But it would also mean that host override will not work, since it is just a nicer more user friendly way of accessing directly on the LAN IP.
My test of removing the existing servers & adding them using the hostname occurred after I had added the host override
So... it's back to the NAT reflection rules in pfsense. And I really think this should work!
So remove the host override, and test again using hostnames, with NAT reflection activated.And I wouldn't give up just yet... you have Pure NAT and then you have Pure NAT + Proxy to try as well.
But the key item will be this one (and I really think you can skip NAT reflection for 1:1 NAT) :Beyond that I don't know...
-
@Gblenn [SOLVED] First I want to extend my apologies for such a late response. Living in Alaska is not without its toll, and frequent & sometimes long-lasting power outages are a thing. I wanted to share that I finally stumbled upon the thing that solved my issue. The Windows 10 VM that I run my ARK Survival Evolved servers on has a set of inbound rules within the Defender Firewall. I inspected them and found the rules list the ports correctly, but had an option I was unfamiliar with; "Edge Traversal", which was set to "off" by default:
and
Acting on a whim, I enabled Edge Traversal on both the inbound rules, which resulted in ARK Server Manager (ASM) immediately changing the status of the servers to "Available", meaning the servers were reachable, and that server-to-server travel was available to clients inside and outside the local network.
It turns out I am not crazy, and had likely set up the port forwarding and NAT Reflection rules in pfSense correctly at least once before, but was repeatedly defeated by not knowing about this Edge Traversal thing. Microsoft does not provide a very clear description of what Edge Traversal does or is for, but I found this post on the serverfault site that may provide a bit more insight:I want to extend my thanks and gratitude to you and the others who jumped in and provided guidance and suggestions in troubleshooting this off-the-wall issue.
-
@SlackerDude Wow that was a tricky one to figure out... good catch!
Like you say, you really had all the configurations in pfsense sorted out, so it was really strange that things weren't working as expected.
Perhaps it's worth investigating if moving the ARK server to a Linux VM might be a good idea?
Besides freeing up a Windows license, I would suspect that you may be able to improve performance a bit actually. -
@Gblenn Great suggestion! That is my plan. I originally spun up the Windows box because I was familiar with the ARK Server Manager software. However, I've been reading up on Pterodactyl and Wings, which can be run on a Debian platform. It looks interesting and has the added advantage of being able to host multiple self-hosted game servers.