NAT Reflection Issue for a VM running on TrueNAS
-
@Gblenn I have done that, and have attempted to create rules to allow access:
Enable NAT Reflection:
List of NAT Rules:
Example of one NAT Rule:
That got me to the point where I could see and access the servers from outside my home network, and travel from one to another within the game. However, I need to know what I missed to make that same full functionality available from inside my home network. -
@SlackerDude Ok so all of that looks great, and since you can access the game from an external source, that shouldn't be the issue...
It does look a bit strange though that one can see the actual port numbers and IP's in the List of rules. Rather than the aliases you have created? Not that it matters as long as the information is correct..
One thing to note wrt aliases, as they are all the same type (UDP) you could create one single alias for all the ports that you use for that one server. Just click Add port when you edit the alias and enter the next port or range and so on...
I'm not sure how automatic this really is, but what if the outbound rules are only automatically created when the rule is created/edited, Then if you try editing each of those rules and click save and apply changes and see if that changes anything?
Then when the firewall rules have reloaded, try again... it really should work fine also from inside the network the way you have it set up.
BTW, another thought, are you access the ARK server using it's internal IP?
-
@Gblenn I goofed when I uploaded that image. that was a screenshot I took before creating the alias for the various ranges of ports. This is what looks like as of today:
I separated the various ranges to cover a possible total of 8 servers, with the game/peer ports, query ports, and RCON ports grouped for simplicity's sake:
I will try your suggestion and edit/save each of them and follow up with a forced reload by way of simply rebooting pfSense, just to keep things honest. I will share the results in a bit. Thanks! -
@Gblenn I did consolidate the Aliases:
and created a new NAT rule:
as well as a WAN rule:
and then rebooted pfSense. I ended up with the same result, unfortunately:
I honestly don't know what to try next. -
@SlackerDude Hmm, that is strange... so a few other ideas and checks then.
You mentioned that Plex has been working fine for you, so if you could try accessing Plex from inside your network, using a web browser (publicIP:32400).
That will tell you if NAT reflection is actually working or not. And if that doesn't work, try reloading the Plex rule as well by making an edit (or just save) and Apply.The picture you are showing seems like it's from a server management SW,
Have you tried starting up the game and entering your external IP to access your server that way? I'm thinking that the Server SW may have a bit more intelligence to it and could detect going back to itself.Also, do you really need, or want, to open the RCON ports? Not that it would make a difference here, but those are for server management aren't they?
-
@Gblenn Great question! I can access my Plex server from inside my home network only by a private IP address and can access it from a public IP only when I am outside my network, so I guess that indicates the NAT reflection is not working.
I do not require the RCON ports, as I access and administer the ARK servers via an RDP connection inside my home network, and so can eliminate them.
Okay, so it seems the thing I am missing is a working NAT reflection rule. I have tried various rules, but have so far failed to get a positive result.
-
@SlackerDude
You can try NAT reflection + proxy if pure NAT doesn't work.
Also consider that your firewall rules have to allow the access.If NAT reflection works properly, can be investigated by sniffing the traffic on the internal interface.
You should see request packets from your client to the public WAN IP. These have to be forwarded by pfSense, where the source is turned into the pfSense interface IP (LAN maybe) and the destination into the servers IP.
So the server should respond to pfSense and pfSense should forward responses to the client, while the source is turned into WAN IP. -
@viragomann said in NAT Reflection Issue for a VM running on TrueNAS:
@SlackerDude
You can try NAT reflection + proxy if pure NAT doesn't work.
Also consider that your firewall rules have to allow the access.Perhaps you know how this works, wrt the automatic creation of outbound rules? If you have a bunch of NAT rules already, and THEN tick the boxes in Setup > Advanced > Firewall & NAT. Will all of the rules then be rebuilt and the relevant outbound rules will be created? Or will that only apply to new rules created after those functions have been turned on?
I'm thinking the rules may need to be redone, or at least edited and saved for that to happen? I don't see any reason Pure NAT shouldn't work?>
-
@Gblenn
The rules are not visible in the GUI, as far as I know. But they should be listed in /tmp/rules.debug, I think.I had no success with pure NAT for simple HTTP traffic years ago, when the server and client were within the same network segment. But it worked with proxy though.
I know, the proxy mode is not necessary these days anymore and I've disabled it in my settings, but I'd still suggest to try it if there is no joy otherwise. -
@viragomann Exactly, it's not easy to troubleshoot when you can't even find the rules. I assume that when a rule is created, it will check if those options are set, and then create the outbound rule. But is the reverse also true? If you tick the boxes, is there a check to see if any rules exist for which outbound rules need to be created. And if I remove those options, will my outbound rules be removed?
There is a section in /tmp/rules.debug that starts out with:
'# Outbound NAT rules (automatic)
'# Subnets to NAT
table <tonatsubnets> {
etc.And I can see references to my NAT rules that I have in place, including Plex...
So I did some testing... and if I uncheck the boxes, the list changes only slightly, but I can verify that I am no longer able to access the server I tested towards, using my public IP (fqdn).
What's more, after turning reflective NAT back on, I had to reboot the server in order for it to be accessible again. I suppose I could kill all the states instead, but that's what I did.
So, @SlackerDude, try restarting your server(s) and see if you can access Plex using your external IP?
-
@Gblenn said in NAT Reflection Issue for a VM running on TrueNAS:
I assume that when a rule is created, it will check if those options are set, and then create the outbound rule. But is the reverse also true? If you tick the boxes, is there a check to see if any rules exist for which outbound rules need to be created. And if I remove those options, will my outbound rules be removed?
As far as I know, the rule set is rewritten every time you apply changes or a service like pfBlockerNG.
If you run "pfctl -sa" in the shell or on Diagnostics > Command Prompt you get the NAT rules only. This is probably more meaningful than tmp/rules.debug.
-
Like I said, I actually did some tests and yes they are rewritten:
So I did some testing... and if I uncheck the boxes, the list changes only slightly, but I can verify that I am no longer able to access the server I tested towards, using my public IP (fqdn).
What's more, after turning reflective NAT back on, I had to reboot the server in order for it to be accessible again. I suppose I could kill all the states instead, but that's what I did.
So, @SlackerDude, try restarting your server(s) and see if you can access Plex using your external IP?
-
@Gblenn I tried running the "pfctl -sa" command and received output that I am trying to wade through (there is a lot to go through). I have also restarted the servers and can still access my Plex server on the public WAN address from outside my local network. I can also still access my game server IP on the public WAN address. However, with clustered ARK servers, the ability to "travel" from one server or map to another when accessing the game from within the local network requires "loopback" to be enabled, which is where I seem to be stuck. I am reading that either a reflective NAT rule or Split DNS will resolve the issue. I think I have set up Split DNS correctly, just as I thought I had followed the instructions for creating a NAT reflection rule correctly, but have yet to achieve success.
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.
I appreciate all the great ideas and suggestions from you guys. I wish I could wrap my head around what is very likely a simple solution.
-
@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...