[b]Platform:[/b] PC (Steam) [b]Account Age:[/b] New account (joined June 22, 2026) [b]Issue Duration:[/b] 1 week, every single session [u][b]PLEASE CHECK COMMENTS TOO[/b][/u] [armory]Summary[/armory] I have been unable to play Destiny 2 since creating my account. I receive error code WEASEL consistently within 30-60 seconds of reaching the character selection screen. If I select my character quickly enough, I can get approximately 10 seconds into the New Light tutorial before WEASEL hits. My character 3D models never render on the character selection screen, though my character name and class display correctly. I have performed extensive network troubleshooting and captured Wireshark data that proves this is a server-side disconnection, not a client-side network issue. [armory]What I Have Already Tried (General)[/armory] - Flushed DNS - Tested on multiple networks (home router, access point, mobile hotspot) - Tested with Cloudflare WARP - Changed DNS servers (Cloudflare, Google) - Tested via Epic Games launcher with a separate Bungie account (same issue) - Verified and reinstalled game files via Steam - Uninstalled and reinstalled Destiny 2 completely - Cleared all Bungie/Destiny AppData folders and Steam userdata for Destiny 2 - Set MTU to 1400 - Tested both with IPv6 enabled and fully disabled on WiFi adapter (Disable-NetAdapterBinding) - Note: IPv6 is enabled at the router level regardless of adapter setting - Added explicit Windows Firewall allow rules for destiny2.exe, destiny2launcher.exe, BEService_x64.exe, miniTicketDbg.exe - Reset Winsock and TCP/IP stack - Set roam aggressiveness to lowest on WiFi adapter - Disabled all third party network software (Mullvad VPN, GlassWire kernel driver) - Tested with Windows Firewall completely disabled - Stopped VMware NAT and DHCP services - Constrained dynamic UDP port range [b]None of these resolved the issue.[/b] [armory]Exact Commands Executed[/armory] [b]Network stack reset:[/b] netsh winsock reset netsh int ip reset ipconfig /flushdns ipconfig /release ipconfig /renew [b]MTU change:[/b] netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent [b]Dynamic UDP port range:[/b] netsh int ipv4 set dynamicport udp start=49152 num=16383 [b]Disabled IPv6:[/b] Disable-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6 [b]Windows Firewall allow rules added:[/b] New-NetFirewallRule -DisplayName "Destiny 2 UDP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\destiny2.exe" -Protocol UDP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 TCP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\destiny2.exe" -Protocol TCP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 Launcher UDP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\destiny2launcher.exe" -Protocol UDP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 Launcher TCP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\destiny2launcher.exe" -Protocol TCP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 BattlEye UDP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\battleye\BEService_x64.exe" -Protocol UDP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 BattlEye TCP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\battleye\BEService_x64.exe" -Protocol TCP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 Ticket UDP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\miniTicketDbg.exe" -Protocol UDP -Action Allow New-NetFirewallRule -DisplayName "Destiny 2 Ticket TCP IN" -Direction Inbound -Program "D:\SteamLibrary\steamapps\common\Destiny 2\miniTicketDbg.exe" -Protocol TCP -Action Allow [b]Disabled Windows Firewall entirely for testing:[/b] netsh advfirewall set allprofiles state off [b]Re-enabled after testing:[/b] netsh advfirewall set allprofiles state on [b]Stopped GlassWire kernel driver:[/b] sc stop gwdrv [b]Stopped VMware NAT and DHCP services:[/b] net stop "VMware NAT Service" net stop "VMware DHCP Service" [b]Enabled Windows Filtering Platform audit logging to capture blocked packets:[/b] auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable [b]WFP audit log query (confirmed Destiny UDP blocks before firewall rules were added, no Destiny blocks after):[/b] Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 5152} | Select-Object -First 50 | Format-List TimeCreated, Message [b]Real-time TCP connection state monitor (used to confirm server-side FIN):[/b] while ($true) { $conn = Get-NetTCPConnection | Where-Object {$_.RemotePort -eq 7500} if ($conn) { Write-Host "$(Get-Date -Format 'HH:mm:ss') - State: $($conn.State) Remote: $($conn.RemoteAddress)" } else { Write-Host "$(Get-Date -Format 'HH:mm:ss') - CONNECTION GONE" } Start-Sleep -Milliseconds 500 } [armory]Wireshark Evidence[/armory] I captured two Wireshark sessions and analyzed the packet data. Both captures show the same pattern: - Game launches and connects successfully to Bungie's auth server on port 7500 (TCP) - UDP game traffic flows between my client and Bungie's game servers - After approximately 60 seconds, [b]Bungie's auth server sends a FIN packet[/b], initiating a graceful connection termination - My client acknowledges with FIN/ACK (CloseWait state) - Connection closes and WEASEL appears I also monitored the TCP connection state in real time using PowerShell while playing. The output confirms the server-side disconnect: [b](Central Time Zone, 06/25/2026)[/b] 00:24:18 - State: Established - Remote: 172.97.56.161 00:24:19 - State: CloseWait - Remote: 172.97.56.161 00:24:21 - CONNECTION GONE 00:24:22 - CONNECTION GONE [b](Central Time Zone, 06/25/2026 | Test 2)[/b] 02:26:10 - State: Established Remote: 172.97.56.161 [...] (Exactly 1 minute of "Established" before FIN is sent from Bungie) 02:27:10 - State: Established Remote: 172.97.56.161 02:27:10 - State: CloseWait Remote: 172.97.56.161 02:27:11 - State: CloseWait Remote: 172.97.56.161 02:27:12 - State: LastAck Remote: 172.97.56.161 [b]CloseWait state is only entered when the remote side sends a FIN. This proves Bungie's server is initiating the disconnect, not my client.[/b] [b]Bungie auth server IPs observed across multiple sessions:[/b] - 172.97.56.80:7500 - 172.97.56.39:7500 - 172.97.56.161:7500 - 205.209.22.119:7500 The pattern is identical every time regardless of which auth server I connect to. [armory]Additional Observations[/armory] - Character 3D models never render on the character select screen (name and class text show correctly) - The issue occurs on [b]both Steam and Epic Games[/b] with separate Bungie accounts - UDP traffic ratio improved after adding explicit firewall rules, but the server-side FIN persists - The disconnect occurs on a consistent ~60 second timer suggesting a server-side timeout threshold - This began happening immediately upon account creation and [b]has never worked once[/b] [u][b]My Initial Theory[/b][/u] [spoiler]The Bungie auth server appears to be timing out waiting for a client-side confirmation that the character/profile data was successfully received and rendered. Since character models never render (likely a CDN asset streaming issue for new PC accounts), the client never sends this confirmation, and the server closes the connection after its timeout threshold. This appears to be a chicken-and-egg problem introduced in a recent update — the client waits for assets before confirming, the server waits for confirmation before serving assets, neither gets what they need, and the server times out. The fact that this affects [b]multiple launchers and multiple Bungie accounts from the same PC[/b] strongly suggests this is a server-side issue with new PC account onboarding, not a client or network problem.[/spoiler] [armory]My Theory (Updated)[/armory] My original theory has been revised. Since my initial post, character models now render correctly on my local machine after a session on GeForce NOW, which appears to have completed whatever profile initialization was stuck on Bungie's end. This means the original chicken-and-egg rendering theory no longer applies. The core issue remains: Bungie's auth server closes the connection via FIN at [b]exactly 60 seconds[/b] every single time on my local machine, but [b]not on GeForce NOW[/b] using the same account and internet connection. My current theory is that Bungie's auth server expects a specific client-side response during that 60 second window — possibly related to BattlEye hardware attestation or a client capability check introduced in a recent update. GeForce NOW's environment satisfies this requirement. My local PC installation does not, and the server times out waiting for it. [b]The only way to identify what that difference is would be to compare server-side logs between a successful GeForce NOW session and a failed local PC session on the same account.[/b] [armory]System Info[/armory] - OS: Windows 11 - Network: WiFi (Intel Wireless-AC 9462, driver version 23.30.0.6) - Launcher: Steam (also tested Epic Games) [armory]Request[/armory] Can a Bungie engineer check the server-side logs for my account (Nytonyx#4279) around the timestamps of these disconnections to confirm what the auth server is timing out waiting for? The network data on my end is clean — [b]the answer is in your server logs.[/b]