A solution for cannot connect to local dedicated server (server is offline)

[Hades]

Hi all,

Thought I'd share my solution for this, since Hellion doesn't have direct IP/local LAN feature.... and many people just can't host their own server because of this.,

This issue can be resolved by configuring your router/modem/firewall with "NAT hairpinning" or "NAT reflection"... however this is a very complex piece of configuration that most devices don't support (or it's just really really hard to get working).

I assume you know how to host a dedicated server in your network (the usual port forwarding stuff), but are struggling with the "server offline" whenever you try to connect to your advertised server from within home network.

Background

The reason you can see your server advertised... but it appears as offline, is because your server is advertised via your public IP address... not via it's internal local LAN IP address.

When you try to connect to your public IP, you go out via your router/modem/firewall which doesn't have a NAT rule that says "when the packet comes from inside the network and goes to the public IP address, change the destination from the public IP back to the private IP and send it back again".

That's because by default most NAT rules only have "when the packet comes from the OUTSIDE of the internal network..." .so they just drop the packet. #fail.

Anyway, here's the workaround:

The non-NAT hairpinning/reflection workaround

I'll give this as an example for people using WIndows 10. Just change the IP addresses to match what you have.

Your gaming PC private address: 192.168.0.10
Your dedicated server private address: 192.168.0.20
Your public IP address: 200.10.10.22

1) Add a second IP address for your gaming PC

a. Click Start, type "network" and choose Network and Sharing Center
b. Click "Change adapter settings"
c. Right click on your ethernet adapter and choose "Properties"
d. Left click on "Internet Protocol Version 4 (TCP/IPv4)... and choose ""Properties"
e. Click on "Advanced" button.
f. In the IP Address section, click "Add" and enter "200.10.10.23" with a mask "255.255.255.0"

Yes, that's right: just make your gaming PC secondary IP address "one more" then the real public IP. i.e. instead of .22 we're making it .23.

2) Add a second IP address for your dedicated server which is your REAL public IP.

a. Repeat exactly as 1) above, except for the IP Address use your real public IP address. In this example, it's "200.10.10.22" (and keep the mask the same "255.255.255.0".

Yes... your dedicated server now has the same secondary IP address as your real public IP address.

Profit

That's it.. have fun connecting to your own Hellion dedicated server. When you're done, just remove the extra IP addresses above.

So what happens now is when you see the list of servers in Hellion, your Hellion client tries to connect to your real public IP address.... however this time, your gaming PC believes that the real public IP address is right next door on the LAN... so it never goes through the reouter/modem/firewall.

P.S. Some people may experience issues if they have friends that happen to be on the same public IP address range (e.g. your friend just happened to be on "200.10.10.x" network as well. If so... it won't work for your friend... sorry for him.

[CheeseJedi]

Interesting write up. :)

In my experience most consumer grade routers either support hairpinning or they don't - no configuration needed, or even available, it's just part of the implementation.

Not having Hairpinning/loopback support simply means the router can't route packets from the internal network out to it's public interface and then back again, preventing communication.

Typically the NAT implementation would need specific support for this feature, and some router manufacturers have been dragging their heels on this, perhaps citing the fact that hairpinning is "not a typical consumer feature".

DrayTek routers, which cover both the home user and SME (small / medium enterprise) space have supported this for many years now - other router manufacturers do seem to be supporting it more often these days.

More complex kit, like Cisco SOHO (Edit: and enterprise) equipment may have options for this, but I'd argue that they are less likely to be found this at HELLION players homes (perhaps with the exception of some enthusiasts).

A cautionary note: If one follows the advice under the Workaround section, YOU MAY LOOSE THE SECURITY BENEFIT OF NETWORK ADDRESS TRANSLATION (if it works at all in the proposed configuration) as you are bypassing this feature and the traffic is then routed normally rather than NATed. This configuration is often also referred to as a DMZ. Make sure you are well firewalled up and beware you are at increased risk!

Additionally the router may not cope well with seeing the same network ranges being used on both internal and external interfaces

Finally, using IP addresses within your providers range that you have not been specifically allocated could cause issues other than simply not being able to connect - even if you feel comfortable with the risk of loosing NAT protection I would still advise proceeding with extreme caution!

[Hades]

I'm using the above workaround myself for the last few weeks and it works fine... just wanted to share it with others.

Just a few corrections for you CheeseJedi (constructively meant!)

- there is no change in security posture or any changes in firewall rules required
- it's exactly the same as a direct IP/LAN connection works... packets just go straight to the server instead of hairpinning through the router (and creating extra CPU load on it). When Hellion gets direct IP it will work the same way.
- it's not a DMZ configuratiion (DMZ is a separate subnet/zone on a firewall with it's own security policy... however this is just your typical server on the internal subnet with port forwarding but adding a route directly to the server to avoid hairpin config.

P.S. I have MCSE and CCIE certifications... and even I just got frustrated trying to get NAT hairpinning working on a Cisco ASA 5510 firewall (v9) software... so just trying to help Joe Public out here.

[CheeseJedi]

I guess you were unable to get the Cisco device to correctly hairpin the connection, hence why the workaround was needed. As the ASA 5510 is EoL I'm also guessing software updates are not really an option, so the situation can't be improved that way.

if I understand this correctly now (my apologies, I've re-read your post ;) you've essentially created a new subnet on the same physical segment with an alternate addressing scheme, of which only the server and client machines are members.

In that case any packets destined for this secondary class C (/24) network will not be sent from either the server or client machine to the default gateway (router) on the 'internal' network and instead will be delivered directly to the other host, or dropped in the case of the other 252 addresses - and this is presumably the gotcha for external people on the 'official' version of the subnet within the ISPs network.

The DrayTek routers I mentioned previously (can but don't have to) implement their DMZ on the same physical segment as the internal LAN(s) and in this case adding of secondary IP addresses (from a pool of public addresses) to internal hosts can allow firewalled, but not NATed traffic through to the machine, which I consider a somewhat similar arrangement to what you have configured.

While I wasn't necessarily expecting any additional firewall changes in your configuration for this 'reflection eliminator', presumably external players are able to connect to your server without issue? (with the correct port forwarding, of course) Have you had any problems in this regard?

While I'm still not overly keen on the idea of using an unallocted address from your ISPs block, especially considering how highly contended IPv4 addresses are now becoming, you might consider using a two host /30 (255.255.255.252) netmask to reduce the chance, however unlikely, of address collisions with the outside world.

Thanks for sharing your experience with this.

[Hades]

Yes, that's exactly it.

Using a /30 mask would be more elegant, but trying to explain to Joe Public how to determine the /30 network address of the 4th octet of their real public IP by doing binary math.. might be more headache than it's worth :)

And the chances of two people being on the same ISP /24 range, playing the same game and connecting to the same server is pretty slim. On top of that, I very much doubt Hellion clients will ever establish peer to peer connections between themselves... so it's more likely that peer-to-peer voice (Discord, Skype etc.) wouldn't work to the hoster in that rare scenario.

In point of fact I've only been doing LAN games, so external connections to the server have only been demonstrated by the fact that the server is visible in the Hellion server browser, and I've also done UDP port testing from check-host.net which sees it ok. So the source IP must be NAT'ed behind the internal interface.... hence the server is able to reply to external locations like Steam (if it was NAT'ing behind the external IP then the server would never respond to Steam because the source IP would be itself.

As an academic exercise, someone might want to try to connect to the server (it's in community servers... [SG] Storm. Even in the unlikely scenario that it doesn't work... at least Joe Public can play Hellion on "their own server" and avoid latency and potential griefing.

[CheeseJedi]

I thought I'd check to see if the server was connectable, and I found what I suspect is your server, but it was reporting as offline, which is odd. Maybe I just chose a bad time to test it?
http://steamcommunity.com/sharedfiles/filedetails/?id=1300553341
This aside, it looks like you've found a legit workaround for a player who whats their own server (on a seperate machine to their client) behind a router that won't hairpin, and (possibly) isn't too concerned about external players connecting. Nice job! :)

If anybody else tries this approach I'd recommend leaving feedback here to let us know how you got on.

[CheeseJedi]

One final thought - running the dedi on the client machine should also work in this configuration (and could be marginally simpler?)

In that case I guess only step 2 would be applied (to the client machine) plus the expected dedi installation and port forwarding set up.

[Hades]

Not sure why you saw offline server there... my log showed a few Internet hiccups during the day so maybe it was bad timing. I actually host a few games on my dedi server, and external players have been connecting ok. But Hellion doesn't get as much traffic.

Still be good to see if anyone else has issues connecting to my server... or success stories.

This is all just a workaround until Hellion gets direct IP/LAN support anyway... which is why you would rarely see this kind of solution. Hopefully the devs can put a console/debug command in as a quick hack, .e.g. "connect 192.168.1.20" before adding direct IP menu.

[CheeseJedi]

Originally posted by Storm:

Not sure why you saw offline server there... my log showed a few Internet hiccups during the day so maybe it was bad timing. I actually host a few games on my dedi server, and external players have been connecting ok. But Hellion doesn't get as much traffic.

Still be good to see if anyone else has issues connecting to my server... or success stories.

This is all just a workaround until Hellion gets direct IP/LAN support anyway... which is why you would rarely see this kind of solution. Hopefully the devs can put a console/debug command in as a quick hack, .e.g. "connect 192.168.1.20" before adding direct IP menu.

Agreed, an option to manually enter an ip:port would be the best long term option, as I believe the master servers are only acting as an index of online servers for the browser.

Back to the original matter, I came across this document, linking it in case you hadn't seen it already: https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6505-nat-on-stick.html

No idea if this is appropriate for your device though, so may not be of much help.

[Hades]

Thanks for the thought :) The link is for a conventional router not an ASA firewall (different OS). Even so, the technique requires a downstream ethernet switch capable of inter-VLAN trunking)... so while it deals with the kind of issue, the hardware involved is rather special.

Anyway, hopefully Hellion will feature LAN or direct IP connect feature soon - and all the problems will fade away instantly :)

[Gintar]

you can also simply add your outside ip address to the host file and space then localhost. This also allows you to play client on same machine as server.

[sumfuka]

Originally posted by Gintar32:

you can also simply add your outside ip address to the host file and space then localhost. This also allows you to play client on same machine as server.

As far as I'm aware, the Windows hosts file only resolves hostnames to a particular address (e.g. 'localhost' resolves to '127.0.0.1'), whereas the Hellion server browser only returns ip addresses for connection to, so the Hellion client will only ever attempt to connect directly to an ip address, not a hostname, and so a Windows hosts file won't do anything.

[Hades]

Yes, that's correct sumfuka. Specifically, without the ability to manually enter a server IP address in the client.. you have to rely on the Hellion client server browser - and it only displays external IP addresses which skips localhost name resolution.

[LvlLord]

Since I had the same problem with the router not routing back internal packages, I use a raspberry pi as a gateway.
Here is how:
Just start up an raspberry pi (or any other linux machine) and remember its IP adress (r.r.r.r)
Then get your extenal ip which is x.x.x.x and your dedicated server machines ip address s.s.s.s.
On your computer where you want to play, you start cmd with admin priviledges and use

route print

to detect your interface to the network. It is located on the top. Similar to this

===========================================================================
Schnittstellenliste
  5...xx xx xx xx xx xx ......Realtek PCIe GBE Family Controller #2
  1...........................Software Loopback Interface 1
===========================================================================

So you know your interface # is 5 (=ifid).
Then you use the following command

route add x.x.x.x MASK 255.255.255.255 r.r.r.r IF ifid

You should replace the x.x.x.x, r.r.r.r and ifid with your numbers.
Example

route add 8.8.8.8 MASK 255.255.255.255 192.168.0.2 IF 5

You will get an "OK!" as return. This command will route all packages for your external IP to your raspberry pi.

Now we have to configure the raspberry pi. This needs to be repeated after every reboot.
Log into it and get a root access.
First we need to activate ip forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

Now we have two possibilities. Either lazy (good for scripting) or the specific configuration.

The lazy one (will working even if your external ip changes, but you still have to adapt your route add above):

iptables -t nat -A PREROUTING -j DNAT --to-destination s.s.s.s

This will route any requests to any IP to your server s.s.s.s

The specific one would be

iptables -t nat -A PREROUTING -d x.x.x.x -j DNAT --to-destination s.s.s.s

This will route only the requests to your external IP to your server s.s.s.s

The last command is:

iptables -t nat -A POSTROUTING -j MASQUERADE

This will activate masuqerading, so that the response packages go back to the raspberry pi, which will forward the answers back to your main.

After this you can start your dedicated server and only you will be able to detect your local dedicated server.

[SabreZero ice]

I've tried to solve this for about a week, the solution is:

alt_ip_address=127.0.0.1 in GameServer.ini

[Darth Venerable]

Where can I find the local dedicated server client? I do not see it in Steam's workshop.