Error Avatars on Gateway IP Change
´ DyMattic `
I use a multi WAN setup for redundancy.
Sometimes I need to disable a gateway on my router, when the uplink is flapping.
If this happens while I am in a VRC instance, all new players that join the instance show as error avatars.
Normally the fix is to restart the client.
But when I am performing in VRC and streaming, it's not as easy, because after restarting the client, I have to set up the dolly system on the camera again and it just really distracts me from my performance.
VRC authentication tokens are bound to an IP address.
This is a security feature.
Though there are probably ways around this.
The client could try to re-authenticate using the steam clients token when there is an IP/token mismatch.
Or authentication tokens could not just be IP bound, but also use a device/client fingerprint in addition to the IP address link.
Would really increase quality of life :D
PS: image is a screenshot of my visuals, you can see the error avatars there, though it's a little dark, sry for that
Photo Viewer
View photos in a modal
Log In
WubTheCaptain
Seems like a self-inflicted footgun with a network stack that's not been standardized or defined at the IETF. Using BGP would be the standard solution here for uplink redundancy.
Not a bug, imo.
C0D3 M4513R
WubTheCaptain "Using BGP would be the standard solution here for uplink redundancy."
Yeah, but setting BGP up requires you to have an AS-Number and BGP peering with ISP's. In a simple case, where you just have a normal ISP connection and maybe a 5G Mobile-Network fallback uplink, this just isn't feasable.
´ DyMattic ` "Or authentication tokens could not just be IP bound, but also use a device/client fingerprint in addition to the IP address link."
This requirement fails quickly once you realize, that there are many tools that use the VRChat API (even if it's not officially documented). Some of which are vrc.tl (through vrc.tl owned vrchat accounts) and vrcx (through your own account).
I agree that it'd be neat for vrchat to not immediately break in a bunch of ways when the public ip-address changes (be that trough VPNs or multiple WAN connections).
´ DyMattic `
C0D3 M4513R
I had my llm rephrase this, cause I suck at bringing information across properly sometimes xD
"To clarify the proposal — the device/client fingerprint wouldn't be a hard requirement on top of IP binding. It'd be a fallback path
only
for the official VRChat game client, so that tokens don't immediately invalidate the moment the public IP changes.Third-party tools like vrc.tl and VRCX would behave exactly as they do today: tokens tied strictly to IP, invalidated on change. Nothing about how they authenticate would have to change, no new fingerprinting requirement gets imposed on them.
The specific case this is meant to fix: you're connected to an instance on the official client, your public IP changes mid-session (WAN failover, VPN reconnect, mobile handoff, whatever), and avatar loads + API calls start failing because the token got invalidated. Right now the only fix is restarting the client, which mid-performance or mid-stream is rough. With a fingerprint fallback scoped to the official client, the session could just keep going.
So it's strictly additive for the official client, zero impact on anything else hitting the API."
Since the main issue is that tokens get invalidated on an IP change while the game client is still connected in a session and stays in the instance, adding a mechanism that provides a grace-period for game clients ( the fingerprint is only meant to prevent abuse of this grace-period ), the API can basically behave like this:
- Auth Token and Client ip missmatch detected
- check if device/client fingerprint matches fingerprint associated with token
- If true: Notify client that re-auth is needed( grace period .eg. 5 minutes)
- Client issues re-auth
- profit
Something like this.
I don't know how VRC is doing things behind the hoods exactly, this is just an idea ^^
´ DyMattic `
WubTheCaptain
What does Peering and BGP have to do with an enduser?
Also I am using OPNSense in a Multi-WAN setup.
I have seen this in the wild with other "big name" firewall vendors as well...
If you like to throw IETF Standards around, at least check your facts xD
Relevant RFCs for what I'm doing (multi-WAN with policy routing and per-WAN NAT):
- RFC 4116— IPv4 Multihoming Practices and Limitations, Section 3.3 (NAT-based multihoming): https://datatracker.ietf.org/doc/html/rfc4116#section-3.3
- RFC 2663— IP NAT Terminology and Considerations: https://datatracker.ietf.org/doc/html/rfc2663
- RFC 3022— Traditional IP Network Address Translator: https://datatracker.ietf.org/doc/html/rfc3022
- RFC 4787— NAT Behavioral Requirements for Unicast UDP: https://datatracker.ietf.org/doc/html/rfc4787
- RFC 5382— NAT Behavioral Requirements for TCP: https://datatracker.ietf.org/doc/html/rfc5382
- RFC 2991— Multipath Issues in Unicast and Multicast Next-Hop Selection: https://datatracker.ietf.org/doc/html/rfc2991
- RFC 2992— Analysis of an Equal-Cost Multi-Path Algorithm: https://datatracker.ietf.org/doc/html/rfc2992
- RFC 3582— Goals for IPv6 Site-Multihoming Architectures: https://datatracker.ietf.org/doc/html/rfc3582
And for the IETF's work on transport-layer session survival across IP changes (the actual underlying issue):
- RFC 9000— QUIC, Section 9 (Connection Migration): https://datatracker.ietf.org/doc/html/rfc9000#section-9
- RFC 8684— TCP Extensions for Multipath Operation (MPTCP): https://datatracker.ietf.org/doc/html/rfc8684
- RFC 6275— Mobility Support in IPv6: https://datatracker.ietf.org/doc/html/rfc6275
- RFC 5944— IP Mobility Support for IPv4, Revised: https://datatracker.ietf.org/doc/html/rfc5944