Netduma Fraser

Good to hear, do keep us posted!

The abuse report, the IP is from Google so definitely not being attached. Some routers are very sensitive regarding what they consider an attack but the router has a firewall so you're perfectly safe. Grab a log from where it's disconnecting now please. Also reserve an IP for the affected devices on the R3, hopefully that will keep them connected.

Added, please let us know if that helps your issue - don't use that firmware though, use the one pinned to the top of the Early Access sub forum

The x20 will function as normal and that should then allow the PC on the R3 to get an Open NAT. QoS will not be very effective because it can't control 99% of your network in this setup, it would be mostly for the Geo-Filter.

Added

Added

Hold the reset button in the back of the router for 30 seconds, then wait 4 minutes before accessing the interface, go through the wizard and you can change them there. If needed after the reset the default credentials are admin / password

I'm waiting to hear back from Telstra with an update and then I'll let you know

Port forward ports 1-65535 source & destination, TCP & UDP to the R3, that will act essentially as a DMZ function

The DMZ is fine, now check if you still see the issue through the R3

If you consult the manual for it, it should give you details

I wouldn't have thought so no but we can't know how it might be interacting with your network so ensuring it's setup to pass all traffic to the R3 unimpeded could help or at least take it out of the equation. The bridge mode would be on the modem/hub interface - can you find it there to enable it? Alternatively there should be a DMZ option that you can put the R3 WAN IP into.

It won't be able to stabilize every single server but : Quit the application/game/client completely Remove device from the Geo-Filter Give PC PlayStation Device Type in the Device Manager Resync from the Geo-Filter Map menu Re-add the device to the Geo-Filter Set up the Geo-Filter how you like Wait 2 minutes Boot up application/game/client The Geo-Filter should filter better and it may stabilize more often.

Do you notice it happening if you use any of the other LAN ports?

That's good to hear, thanks for the update!

Glad to hear you were able to get it resolved, thanks for the update and the suggestion, I'll pass it on!

Is this on a PS4/5? If you swap the cable or the port on the router does it work?

Added https://forum.netduma.com/forum/151-netduma-r3-early-access/

You need to tell us what the error/issue is and then we can best advise on how to resolve the problem

Thanks, let us know! Your issue is unrelated to those concerns, I'm not sure what yours is caused by currently but we'll get there.

Okay great, on the hub you'll need to put the R3 in its DMZ. Copy the WAN IP from the R3 WAN page, access your hub, find the DMZ option (could be in Security settings or WAN/LAN) and enter it there. Ideally you will then connect all devices to the R3. You can adjust Congestion Control in Ping Optimizer > Advanced. I would also try with disabling the Geo-Filter when you next give it a go.

Disable IPv6 in LAN & WAN advanced settings then reboot from the interface and see if that resolves it please

You'd just have to connect the R3 to it and then port forward, that's all you can do in that scenario

That's great to hear, thanks for the update!

Did they understand what the logs were for, just to diagnose the connection issues and not for recording internet traffic? A strict no-logs policy sounds like the latter. It only supports OpenVPN, our own routers on DumaOS 4 support Wireguard also. Right okay maybe that has something to do with it, as if the connection takes too long to establish or has a delay during then the timeout may apply as the server hasn't responded when we would expect, this makes sense given the distance between you and the server. UDP might work better, you don't need to combine configs, TCP would still be covered by connecting to the VPN using UDP so give that a try. What you could do is attempt to extend the timeout settings through the config by adding these lines to the config: connect-retry n (change n to be the number of seconds to wait between connection retries the default is 5 so try 10) connect-timeout n (change n to number of seconds before it considers there to be a timeout the OpenVPN default is 10 (which isn't long given your distance) so try higher) connect-retry-max n (change n to be the number of retries of the connection attempt. The default is supposedly infinite but I'd set this manually as we can't be sure if that is happening) Do throw in that syslog line as well just in case it provides more information about how these lines are doing. There is really no other information I can use to help - you could grab the main log from the System Information page - perhaps that might show something if the cause is router based but I wouldn't count on it.