Notice VPN Issue Workaround

RReds

R
Stephen Benedetti said:
Greetings Commanders,

We have noticed that the VPN networking issue, which was addressed in the September Update - Patch 1, still persists for some players. We wanted to let you know that the team has renewed their investigations into the matter and hope to resolve it for affected players as soon as possible. However, in the meantime, we have identified a workaround that will hopefully help you connect via a VPN.

Please follow these steps below:
  • Locate the IP address used by your VPN.
  • Next:
    • (Steam) Navigate to the folder here: C:\Program Files (x86)\Steam\steamapps\common\Elite Dangerous\Products\elite-dangerous-64\
    • (Standalone): Navigate to the folder here: C:\Program Files (x86)\Frontier\Products\elite-dangerous-64\
  • You should see a file named 'appconfig.xml'
  • Open this with a text editor such as Notepad and scroll down to the bottom, where you should see a Network section.
  • Add the following line (replacing 'xx.xxx.xxx.xx' with your VPN's IP)
    Code: 
    <UseNic>xxx.xx.x.x</UseNic>
  • The final result should look similar to this:
    Code: 
    <Network Port="0"
upnpenabled="1"
LogFile="netLog"
PingTime="27"
MaxUpRate="250000"
DatestampLog="1"
SendCompressedIDs="0"
>
<UseNic>xxx.xx.x.x</UseNic>
</Network>

  • Don't amend any of the other sections as they'll have been configured for your standard usage already.
  • Save the file in the same location.
Thank you for your understanding.
Click to expand...

Still cant connect to frontier servers after patch 2. Workarounds doesnt work. Im unable to enter game since september, 18.
 

Haizman

H
Stephen Benedetti said:
Greetings Commanders,

We have noticed that the VPN networking issue, which was addressed in the September Update - Patch 1, still persists for some players. We wanted to let you know that the team has renewed their investigations into the matter and hope to resolve it for affected players as soon as possible. However, in the meantime, we have identified a workaround that will hopefully help you connect via a VPN.

Please follow these steps below:
  • Locate the IP address used by your VPN.
  • Next:
    • (Steam) Navigate to the folder here: C:\Program Files (x86)\Steam\steamapps\common\Elite Dangerous\Products\elite-dangerous-64\
    • (Standalone): Navigate to the folder here: C:\Program Files (x86)\Frontier\Products\elite-dangerous-64\
  • You should see a file named 'appconfig.xml'
  • Open this with a text editor such as Notepad and scroll down to the bottom, where you should see a Network section.
  • Add the following line (replacing 'xx.xxx.xxx.xx' with your VPN's IP)
    Code: 
    <UseNic>xxx.xx.x.x</UseNic>
  • The final result should look similar to this:
    Code: 
    <Network Port="0"
upnpenabled="1"
LogFile="netLog"
PingTime="27"
MaxUpRate="250000"
DatestampLog="1"
SendCompressedIDs="0"
>
<UseNic>xxx.xx.x.x</UseNic>
</Network>

  • Don't amend any of the other sections as they'll have been configured for your standard usage already.
  • Save the file in the same location.
Thank you for your understanding.
Click to expand...
Tried this, still no connection.
Also, both local and internet address, shown in network options, still 192.168.xxx.xxx - my local IP, same as before.
 

Nasty2015

N
hchalkley said:
It looks like there was an error in communication at some point - the correct XML for this setting is a child element, not an attribute, as follows:

<Network ... various attributes... >
<UseNic>123.45.6.7</UseNic>
</Network>

This is used when you have multiple network adapters (a VPN driver appears as an extra network adapter to the operating system) and the game for any reason does not pick the one you want it to use - with this setting, if there is a network adapter that has the specified IP address, the game will attempt to use that one.
Click to expand...
I appreciate the response. Unfortunately it doesn't work. Also I would have to make this change manually BEFORE each session. Bottom line is you folks broke this and the responsibility for making it work is on YOUR side not mine. Try "Play through a VPN is no longer supported by Fdev". That would be more honest than having players rooting around in XML files. Thanks.
 

fbt

F
Nope, after explicitly setting the ip of the proper interface in the config, the game still thinks my WAN is my local network.

I have found a workaround. If the game doesn't play well with many interfaces, you can just force it to only deal with one. However, the method that I've used (network namespaces) is completely useless to everyone but Linux users.
 

Nasty2015

N
I just love how Fdev assumes I don't know what I'm doing. After 30 years of work in corporate network security and NOC management I might have picked something up along the way. Windows 10 Does Not Like it when WinXhome users start fiddling with their Network settings. I use WinX ProX64 and it's Very buttoned down. You can do all kinds of PowerShell madness but it'll be set to defaults on the next security update. what FDev did in this last patch it killed VPN support pretty completely. I have a hunch that buried somewhere in the morass of XML silliness there is a commented setting that someone forgot...... (Hint)
 

AveCandido

AveCandido
Nasty2015 said:
I just love how Fdev assumes I don't know what I'm doing. After 30 years of work in corporate network security and NOC management I might have picked something up along the way. Windows 10 Does Not Like it when WinXhome users start fiddling with their Network settings. I use WinX ProX64 and it's Very buttoned down. You can do all kinds of PowerShell madness but it'll be set to defaults on the next security update. what FDev did in this last patch it killed VPN support pretty completely. I have a hunch that buried somewhere in the morass of XML silliness there is a commented setting that someone forgot...... (Hint)
Click to expand...
I use Win 10 Pro X64 and everything works ok.
 

Meresiga

Meresiga
Haizman said:
Also, both local and internet address, shown in network options, still 192.168.xxx.xxx - my local IP, same as before.
Click to expand...

I think that the problem is not on the side of Frontiers, and the problem is on Your side. This IP address cannot be broadcasted to the Internet. This means You do not have a gateway configured between Your internal network and the Internet. Or Your ISP has not configured your access to the Internet.
 

fbt

F
Meresiga said:
I think that the problem is not on the side of Frontiers, and the problem is on Your side. This IP address cannot be broadcasted to the Internet. This means You do not have a gateway configured between Your internal network and the Internet. Or Your ISP has not configured your access to the Internet.
Click to expand...

You're wildly off mark here. As someone with a complex networking setup that definitely works (I'm using it to type this here message), the issue people are discussing here has something to do with how Elite chooses the interface to bind to for outgoing connections (for whatever reason). I'm guessing in complex cases Windows can report something like this, which confuses the game (note several “default” gateways):

Code: 
Ethernet adapter eth1

    Connection-specific DNS suffix. . : ***.org
    IPv4 address. . . . . . . . . . . : 172.19.2.13
    IPv6 address. . . . . . . . . . . : fe80::280:48ff:fe16:d89c%3
    Default gateway . . . . . . . . . : 172.19.2.1

Unknown adapter vpn2

    Connection-specific DNS suffix. . : ***.org
    IPv4 address. . . . . . . . . . . : 172.19.8.10
    IPv6 address. . . . . . . . . . . : fdab:cbfa:9ecb:10:3::1
    IPv6 address. . . . . . . . . . . : fe80::3065:d660:c22b:a7c1%7
    Default gateway . . . . . . . . . : 172.19.8.1

Unknown adapter vpn0

    Connection-specific DNS suffix. . : ***.org
    IPv4 address. . . . . . . . . . . : 10.67.255.6
    IPv6 address. . . . . . . . . . . : fe80::2146:94d4:cf87:7dca%12
    Default gateway . . . . . . . . . : 10.67.255.1

Unknown adapter vpn1

    Connection-specific DNS suffix. . : ***.org
    IPv4 address. . . . . . . . . . . : 10.15.255.3
    IPv6 address. . . . . . . . . . . : fe80::557f:99f0:8335:ff8f%13
    Default gateway . . . . . . . . . : 10.15.255.1

I've dealt with this stuff quite a lot, and my advice — however unprovoked — would be to add an option inside the game to bind to a specific interface (or at least fix it working from the config!). If you insist on automagic, maybe iterate over the interfaces till you find one that allows you to get to the game servers? Just blindly choosing the first (if you're indeed doing so) seems silly.
 

Meresiga

Meresiga
fbt said:
would be to add an option inside the game to bind to a specific interface (or at least fix it working from the config!). If you insist on automagic, maybe iterate over the interfaces till you find one that allows you to get to the game servers? Just blindly choosing the first (if you're indeed doing so) seems silly.
Click to expand...

The Windows OS has the ability to select manually the desired interface and assign this interface to the default one by using metrics. Maybe then the game will not search for various interfaces, as will be to address in this interface which is appointed the main?
 

fbt

F
Meresiga said:
The Windows OS has the ability to select manually the desired interface and assign this interface to the default one by using metrics. Maybe then the game will not search for various interfaces, as will be to address in this interface which is appointed the main?
Click to expand...

My guess (can't check, no proper Windows machine handy, not even a VM rn), based on the VPN users' reports, is that metrics don't solve the issue, as on Windows, all those VPN clients usually bump the VPN interface metric by default.
Won't harm for someone to try it and report back ofc.
 

Meresiga

Meresiga
fbt said:
all those VPN clients usually bump the VPN interface metric by default.
Click to expand...

By default, the priority of metrics is not set in the system (all interfaces have equal access rights). Priorities for interfaces should be done manually.
 

AveCandido

AveCandido
fbt said:
My guess (can't check, no proper Windows machine handy, not even a VM rn), based on the VPN users' reports, is that metrics don't solve the issue, as on Windows, all those VPN clients usually bump the VPN interface metric by default.
Won't harm for someone to try it and report back ofc.
Click to expand...
To start, it is known that VMware and others (machine virtualization), is giving errors in windows 10; It is a known problem ... among other things due to security problems on the client side that were accused of windows but in reality it is virtualization who creates them, obviously Microsoft has taken measures or the owners of that software put security or cover so that they do not They accuse us of data traffic by virtalization, until the owner of VN who has to give that security, for reasons that I am not going to explain here, take a patch. (And I dedicate myself to computer forensic analysis ).
I will not give solutions, because for that there are other qualified professionals who have all the necessary information, Frontier for example.
 

RReds

R
fbt said:
My guess (can't check, no proper Windows machine handy, not even a VM rn), based on the VPN users' reports, is that metrics don't solve the issue, as on Windows, all those VPN clients usually bump the VPN interface metric by default.
Won't harm for someone to try it and report back ofc.
Click to expand...
I checked metrics several days ago, VPN had lowest, so it must be used by default. My knowledge in network systems not very big, so probably I did some useless staff, but I tried this: ED always shows my local network IP 10.138.32.100, in route list I have 2 main routes -
146778
First one is ethernet adapter, second one - VPN. I deleted 10.138.32.1 route. After that everything worked smoothly, ED Launcher worked also, but ED refused to launch with "cannot initialize network" error.

Also I already knew about AppConfig.xml before, I had problems with connect to several ED servers, so I found this line in AppConfig.xml:
Code: 
        <!-- if you need to connect to a specific server, include a line like this
             where id is your 'regular' EDServer and id2 is a mission server
             (omitting id2 will cause using id for both the regular and the mission server): -->
        <!-- <edServer id="107" id2="108" /> -->

But this acually doesnt work. I opened ticket about "how to use this function properly" and after some conversation I recieved this answer:
146783

So, probably workarounds doesnt work because they are not supposed to work outside of their environment?
 
Last edited:

nexusreject

nexusreject
So..... Crappy Issue tracker hunts down and closes issues input by users concerning this problem. Great issue tracker. Duplicate means that it's a big issue. Then you come on the forum here and every bloke & his wife has some kind of nerdy argument about network settings & how FD have said play around with your config.xml all the while the ELEPHANT in the room is this error came with the great September update. No-one had the issue before yet the bright sparks on here (& I appreciate your efforts network spods I really do) try and help with changing network settings & .xml just like the Alpha days!

THIS ERROR CAME WITH THE UPDATE.....!!! It can't be user side problem.
 

RReds

R
After patch I can choose vpn connection in network options and can connect to Frontier Servers, howerver, after long loading Im getting
147179
 

fbt

F
Meresiga said:
On the Russian-speaking forum, people say that after this today's patch, the network error when connecting to the game - disappeared. Now they connect normally.
Click to expand...

It always worked sometimes, but yeah, atm seems to connect fine over my local connection.
Do note that some of the connection issues were (and probably will be again) RKN's fault, not Frontier's.

UPD: And, as due to this issue I was forced to change my home networking anyway, I can now do fun things like changing routing under the game specifically and on the fly. Happy to report that the game even survives me switching exits like a champ. Before, a slight sneeze in my networking's general direction would usually result in a disconnect.
 
Last edited:

Meresiga

Meresiga
fbt said:
Do note that some of the connection issues were (and probably will be again) RKN's fault, not Frontier's.
Click to expand...

I know. RKN's fault was during blocking of Telegram and IP-addresses of Amazon's servers in Russia few months ago. Now they have stopped (temporarily) that procedure. But it is very possible that soon there will be a new wave of blockages. But not now.
 
  • Like (+1)
Reactions: fbt
You must log in or register to reply here.
Top Bottom