{{
`${userDetail.user.displayName}${userDetail.user.cachedBungieGlobalDisplayNameCode ? `#${standardizeBungieGlobalCode(userDetail.user.cachedBungieGlobalDisplayNameCode)}` : ""}`}}
{{getUserClans()}}
8/23/2018 10:36:28 AM
2
-
What you're describing is standard UPnP behaviour. This isn't a Bungie thing. You don't have multiple people concurrently launching Destiny inside the boundary of your internal network, do you? If you do, then you want to disable UPnP - if currently enabled. There's going to be something else amiss as I don't run a UPnP firewall meaning the Destiny client has whine about my environment being a "strict NAT" environment yet I don't have any ongoing issues such as those you've described above. While I'm speculating on this point, I would have thought having a more restrictive environment would have meant I would be more susceptible to disruptions. If you're not running UPnP either and you haven't set up PAT (the static port forwarding you've referenced above) then there's no capacity for Bungie to initiate any kind of connection to you, VPN or otherwise. The only way tunnelling could occur is if the Destiny client initiates the connection subsequently used as the tunnel back to Bungie's infrastructure, in which case from the IP layer, you'll never see 192.168.0.0/16 coming from Bungie and hitting the external interface as it's strictly not routable over public IP ranges - and that's not negotiable over the public Internet. But I expect you already know this. As an aside, most modern home gear I've seen - which isn't all that much in the broader context of how many devices are out there to be honest, is UPnP meaning the average user doesn't have to think about it (though if they care about robust security they might do so). I reckon you're looking too hard at an area where there is no problem, but if you wanted to get a more definitive "proof", you'd have to break out your favourite network tracing tool, where you'd be looking for TCP packet behaviour like SYN's that are being retried and not receiving ACK's, or even a bucketload of ACK's on their own (indicating your Destiny client is having troubles talking the other side). But again, I think this is looking to hard at an area unlikely to be at fault (the Destiny client's networking stack). As I mentioned earlier though, I'd try disabling UPnP - which you'll know you've done because the Destiny client flashes up a massive red banner down the bottom of the initial character selection screen moaning about you being on a "strict NAT" environment. Yes, it's not as convenient for them, but as I say, I haven't had any issues (that I know of) to date with it. Cheers, Lain
-
Edited by seFraggle: 8/24/2018 10:54:51 AMThanks for your response, this behaviour is not related to UPNP. DNAT is in place, as the connections arrives at the PS4, but the return routing isn´t working as of private range IP´s. (which are not routeable via Internet, withour additional protocols) My guess is that GRE or similar is used to handle some connections, it would be capable of causing this behaviour. PSN uses GRE as well for DDOS mitigation. What is still unclear for me is, why the private IP ranges are visible within tcpdumps and logfiles, they shouldn´t be visible as the GRE tunnel usually terminates on the PS4 device. Another idea is, that this traffic is p2p traffic, and there are problems with masquerading the ip´s on the other user devices. What makes this theory obsolete is, that I can see the same host-addresses over and over (15-20 addresses) and it´s unlikely that all the different players I´ve gamed with do have the same IP´s configured. Or there is a configuration issue on the cloud provider side? I´m certain that you will find the same behaviour in your environment, just take a look at a tcpdump when joining a fireteam, or pvp match.
