Still active? #30
Comments
|
@EinDev This app is still active however, updating is really slow and i understand that the developers are busy and at the moment, it isn't working for GTA Online anymore since the new update came out few months ago where they fixed the slow loading into Online. |
|
Yeah, I'm still around. I didn't actually know the program didn't work anymore. I tried searching if anybody has found what the new ports or a method to get a private public session, but I haven't found anything. If anybody finds out how they changed their networking and how to get around it let me know or put up a PR, and I'll update the program. |
|
@Elec0 You got Discord ? i wanna discuss the app with you and ways how to help you update it further and i can become beta tester |
|
@Peshmerga1990 I do, but do you know how Rockstar updated their netcode? |
|
@Elec0 add me on Discord: Peshmerga1990#6143 and i'll find out what R* exactly did with the game |
I think I found the correct settings for the firewall rules, here is my gitrepo: https://github.com/Ultraporing/LeaveMeAlone |
|
@Ultraporing awesome, thanks. I'll look into that. |
|
still active? |
|
@Ultraporing So I've looked through your code, the main difference I saw was that you had two rules per direction, along with port 65431 blocked, which I added, but it doesn't appear to have worked. |
It seemed to work at the time, but I cannot be really sure since it could have been coincidence that ppl didnt join my mission or Lobby.
New Experimental Release: https://github.com/Ultraporing/LeaveMeAlone/releases/tag/v1.0.3 |
|
@Ultraporing Since we seem to be living in the same timezone, maybe we can test it together? Would be interesting to capture wireshark data on both ends during a session. I also tried blocking only my friend's IP's, but that resulted in GTA tunneling the connection through R* servers. |
Yes thats because they run a docker container on your machine in the background which acts as tunnle. You can block port 80 but then GTAO seems to break a bit. |
|
I updated a test build and didn't block friends on the outbound rule, but @Peshmerga1990 said that caused the program to do nothing at all from their point of view. It didn't get them an empty session or anything. Which doesn't make any sense to me at all. |
|
I had a few problems with the old method, halting the cpu or network with task manager such as weird glitches and even ctd or freezing the computer. I have no idea how that happened but I could do the trick before without any problems, this started this month so I had to look for an alternative and then I found your code. Yours seems to work just fine, no bugs or anything, no freezing either. Why is that? I mean what's the difference, and what was causing so many headaches with the old trick? I had the feeling that whenever I suspended the process I was just bloating some script or drivers or whatever somewhere until I had to reinstall the game. |
Any chance we can get a release of your latest version? Quite happy to test and report. Current version seemed to work as expected for an hour, but after completing a mission and returning to a public session my friends kept getting kicked. |
|
GTA5.zip |
|
Hi, any news about this? I'm one of the developers of Guardian and Victoria (tools that dynamically block packets filtering at kernel level instead of using windows firewall) and i've been trying quite a few stuff and changes without any results at all. As far as i've been able to test, it looks like they added some connectivity checks that won't allow anyone to join to your lobby if you use strict blocking (all ip besides those whitelisted), and if you use a more permissive blocking (allowing Take2 ips by default) randoms get routed to your session through those ips. Till now i've been testing fully blocking both incoming and outgoing packets, will try blocking only incoming packets as mentioned above as soon as i find some free time. |
|
No, I don't have anything new yet. |
|
What about changing the MTU for all active NICs to about 1280 or 800 and then set it back to the original value after 10 seconds? This is a trick used on PS4/XBOX to start or lagg out into an empty public session. It's not bulletproof, but it's an alternative and only the host needs to do this. I know C# can get the current MTU for IPv4 and IPv6. But I didn't find a way to set it using a .NET API. It could be done by running netsh commands using C#. Like This does however change the accuracy and the convenience of the tool. |
|
For solo it is working for me just fine. No randoms managing to get through and no CTD or anything like that when I previously used rudimentary stuff like forcing to cut the connection. |
Mind to share the repositories (if these are open sourced) or a source where I can try both tools? Sorry for being a bit offtopic here. As for blocking only incoming traffic I already tried with a conventional firewall solution but that didn't work well. What I do is to allow only a few specific IP addresses from R* servers so it does register the lobby session + host IP address and allow friends IP addresses. It costs a few tries to get on an empty lobby with this method but its been working well for my case. |
Yeah you can check the tools here, there is a new version of Victoria that uses a Rust backend to filter (more reliable than python multithreading and way less resource hungry) but it's not public yet 😅 Regarding the issue, I tried quite a few things with no positive results at all. As a last resort i want to try setting up a udp ssl termination proxy to try and decrypt the game data, but if it uses a hardcoded cert it won't be possible (since i know nothing about reverse engineering to try and extract it) |
|
Do we have any updates coming soon to make this more reliable? It is easy enough to get into a solo lobby, but playing with friends hasn't had a great success rate... Sometimes it works, sometimes it doesn't and just boots them out. |
|
Also having the same problem. The initial session works as expected, allowing whitelisted players to join, and keeping others out. Once a heist or other private-instance session has been completed the tool stops working until the game is re-launched. Not currently useable for doing the open-world setup portions of the newer heists in a whitelist-only setup. |
|
I haven't been able to figure out any way to get it working, and I haven't seen anybody else able to get it working either. (Rubensei, for example.) I don't want to say private public lobbies are dead, but they very well might be. :( |
|
@Rubensei Can you please add me on discord to discuss few things about the Guardian app |
Programs that only extend upon Windows' stock firewall (which can only filter on source / destination) aren't powerful enough anymore as the session tunneling procedure will eventually find a R* IP you're already using to play the game through to tunnel players. This is why sessions can stay safe for a while; once enough people have attempted to join, the tunneling procedure will discover the destinations you're connected to and will "re-use" them for tunneling. Also, as a side note, tunnels aren't only IP flexible. They're also port flexible, meaning that you can be hosting on the standard Game Port (6672) but receive tunneled connections on any other UDP port. |
|
Some good news if anybody is still watching this thread. No promises, but I believe I've discovered not only a way to fix Whitelisting to work since Online 1.54, but also a couple of flaws in Guardian (some intentional, some probably not) that were hindering the program's efficacy to filter packets. I'm in the process of cleaning up my fork and will make it public in a few days so we can all benefit from more extensive testing. |
|
Alright, that should be good enough for beta testing. You can find more details about my fork here: https://gitlab.com/Speyedr/guardian-fastload-fix/-/merge_requests/1 Again, no promises on how well this will work for everybody, but private testing has been optimistic. |
You're amazing! Did a quick check and could start a public session with nobody else in (selecting "whitelisted" option), while R* servers could see my session up. It even worked with 3rd party firewalls (I use ESET just because I can see active UDP connections lol) that I disabled my firewall rules to use this. Didn't invited friends to try yet with the whitelisted IPs but if I do I'll let you know, although someone will do that before I do heh. |
|
Did a few tests with my implementation (same behaviour but active all the time) and I got mixed results. |
My testing has suggested that the Whitelist works best when started from a session with only you in it. When you enable the Whitelist with other players in the session, the non-whitelisted players may get routed through the whitelisted one as soon as they lose connection to you. I have some ideas on how to at least detect this, but fixing it without also kicking the actually Whitelisted player might not be possible, and if it is I'll need to add a bunch of extra functions to Guardian anyways. I have a hunch as to why the Auto-Whitelist fails and will look into it soon, and I also have an idea on an alternative "type" of session that should work basically the same as Auto-Whitelist anyways. |
|
Yeah, so I've got a good guess as to why auto-whitelist is broken, but fixing it will require a bit more work and investigation. https://gitlab.com/Speyedr/guardian-fastload-fix/-/issues/1 In the meantime I'll see if I can bring back "Locked Sessions" which will just block matchmaking requests entirely. |
|
Guys, i found a work-around for the app to make it work, it's not a 100% every time, but its been working for most times, latest was yesterday night, What you have to do is, go into a public session with other players in it, have your friends join the session too, whitelist your friends, then enable the app, the app should kick the randoms out and leave your friends with you, from that moment, app should work fine, You can stay in session and control it who stays and who leaves, hope it works for you as it does for me. |
|
As I understand it, the program is just creating an outbound firewall rule? If so, it works to create a solo session. The problem with connecting friends, they cannot come to me even if their IP is on the white list. Once I monitored all IP addresses that connect to me through GTA ONline in an empty session. And several IP addresses started at 192.81. *. * |
The reason that this occurs is because the very first packet that informs you of an incoming connection will always from one of those 192.81.. IPs you saw (technically it could be any R* / T2 IP), or a Microsoft Azure IP depending on your country. You can find a list of R* / T2 US ranges here: https://whois.ipip.net/AS46555 This is why your friend can't connect to you if you don't allow R* / T2 IPs through; the initial packet which informs your client of the incoming connection never gets a response (or in some cases, never reaches the game at all, depending on how you're filtering).
This is because Online 1.54 brought in a new way of tunneling connections if a player attempting to join your session could not connect to you. After the initial connection response, if two clients cannot reach each other directly, R* services will provide a tunnel for one or both of the clients which will go through an existing hole in your firewall. So, those people who are able to get in to your session aren't directly connected to you; as far as the source and destination IPs are concerned, it looks like R* services traffic. As stated before, you are correct that these 192.81.. IPs belong to R* / T2. |
Are you sure this is the case? I'll need to test if this is still the case, but I remember that once the Firewall is active all connections are dropped, even whitelisted. But that may be because two people were joining that were using the same gateway. If that packet isn't encrypted maybe we can read it? From my experience the IP's that are probably present in some DNS entry from rockstar.com or similar. If they are differentiating between proxy and matchmaking server (which would make sense to do) this could maybe help. |
|
Not totally sure, since game data is obviously encrypted we can just guess here unless someone finds a way of decrypting it. On the other hand, filtering assuming there are some special packets that must reach the host to avoid the servers thinking tunneling is required seems to work reliably enough (the approach Speyedr is using) |
Yes, I have run packet captures with Wireshark in an attempt to investigate network behavior, and every time someone requested my session details, the first packet was not from their IP address. Only after the response to the initial request would you receive packets directly. People are probably getting dropped from the session because your client doesn't respond to the heartbeat that occurs once every 60 seconds or so (because it will come from a non-whitelisted IP and get blocked, likely from the same or similar IP used for that initial packet I was talking about), and something is assuming that your client has gone offline and you get disconnected.
Unfortunately it seems to be encrypted, but there's actually still enough information there to determine if the packet should be let through. I've attached some packet captures containing session detail requests which have had their payloads redacted, but there still should be some certain statistics that stand out, even without the payloads included.
You can find the US and EU IP spaces owned by Take-Two linked above in my previous post. If you take a look at the destination and source IPs included in my packet captures, you'll notice that due to where I live, I do not receive the initial packets from an IP in any of those ranges. Instead, the packet is received from a "breakout IP" owned by Microsoft and used for their Azure Cloud services. I believe that there is simply no way to achieve Whitelisted Private Public Lobbies using IP addresses alone. You can still prevent new players from joining, and you can also "kick by IP" using the standard Windows Firewall, but individual packet inspection needs to be performed to determine if a packet might be tunneled game traffic or not. I would search around for "WinDivert C Sharp" and see if you can find a package or library that would work with this project. |
|
I originally started using this tool as a way to play "private" sessions online with the ability to run CEO/gang operations. The idea of playing without it was pretty awful. Fortunately the built-in, invite-only lobbies now allow players to run their CEO and Biker Gangs without restrictions, so thankfully this tool is no longer required for that use-case. My thanks to the devs who gave us this tool to begin with: without it I'd have never played GTAO as much as I did, and I'm sure many others feel the same. Thank you for all your hard work and efforts over the years. |
Will working PR's be merged? I just had the idea of this program, but if this repo is still active i will start fixing the current issues instead of coding it completely from scratch.
I also have some feature requests, are you open for that? Like using an ID system like Hamachi or Among us does.
The text was updated successfully, but these errors were encountered: