[ 386.11alpha Build(s) ] Testing available build(s)

[Calkulin]

The old system merely throttled connections, it did not do any active blocking.

Any chance of you implementing that again? Because I'm doing my testing on the LAN side, so it's not just a WAN exposure problem and Asus protection daemon is worthless if it's only going to block an attack for the first 5 mins and then allow it to continue uninterrupted after that initial 5 min block

 

[RMerlin]

Any chance of you implementing that again?

It sounds redundant. If Asus' server protect feature is currently broken, then it needs fixing. Throttling won`t help you much in that scenario, it will only slow it down.

 

[ColinTaylor]

Any chance of you implementing that again? Because I'm doing my testing on the LAN side, so it's not just a WAN exposure problem and Asus protection daemon is worthless if it's only going to block an attack for the first 5 mins and then allow it to continue uninterrupted after that initial 5 min block

I can confirm that the same bug/behaviour existed in 386.5_2. The relevant iptables blocking rule is created (in PTCSRVWAN or PTCSRVLAN) after the initial 3 failed login attempts. After 5 minutes the rule is deleted. All subsequent failed login attempts from the same IP address are no longer blocked. New failed login attempts from a different IP address will still be blocked initially.

 

[maxbraketorque]

Any chance of you implementing that again? Because I'm doing my testing on the LAN side, so it's not just a WAN exposure problem and Asus protection daemon is worthless if it's only going to block an attack for the first 5 mins and then allow it to continue uninterrupted after that initial 5 min block

Are you folks discussing SSH exposed to the internet? If yes, then its great to know what security measures are associated with it, but I'm 100% in favor of never exposing anything like that to the internet. ASUS should disable exposing SSH to the internet.

 

[ColinTaylor]

Are you folks discussing SSH exposed to the internet?

No, this applies to WAN and LAN (I've tested both).

 

[SheikhSheikha]

I dirty flashed the second Alpha (release earlier today). Unfortunately the OVPN performance is still 20% than 386.7.2

 

[Calkulin]

It sounds redundant. If Asus' server protect feature is currently broken, then it needs fixing. Throttling won`t help you much in that scenario, it will only slow it down.

I would say slowing it down would be better than what Asus is currently doing. Also who's to say Asus will even do anything about it? They might just say it's working as intended and not change anything, so that's why I say maybe implementing something would be better than leaving the current behavior

 

[cebu99]

is it ok to flash the update over wifi?

 

[L&LD]

Yes.

 

[SheikhSheikha]

running the second alpha for several hours: VPN disconnects without a reason. Blocking all LAN to WAN (although that is not configured). I am not liking OVPN and the way it works with Merlin.

 

[L&LD]

Which Alpha specifically are you using?

Have you removed (and afterward, rebooted), and then re-added the OpenVPN clients/servers, then tested after an additional reboot via the GUI?

 

[SheikhSheikha]

Which Alpha specifically are you using?

Have you removed (and afterward, rebooted), and then re-added the OpenVPN clients/servers, then tested after an additional reboot via the GUI?

Running 386.11_alpha1-gd70162f6f5. Have since 386.10 tremendous performance loss on OVPN (does not matter if I use Proton or Expressvpn, does not matter which nodes. Have done clean installs with WPS resets etc etc. so went through the hoops. Now I see OVPN becoming intermittent. I think that 20% performance loss is too much and with this alpha the OVPN getting disconnected without a log event... I got two AC5300's so I can compare and it simply is not that good since 386.7.2 on my AC5300's.

 

[L&LD]

What options, past defaults, are you changing in the OpenVPN configuration pages?

What paid-for scripts are you importing (if any)?

What is 20% in absolute numbers? Why does this matter to your use case?

 

[SheikhSheikha]

No scripts, just merlin and my openvpn profile for ovpn client.
any bandwidth I can get is a gain. That matters given my use in a desert country with a government managed proxy. The flux of 20% less compared to the older merlin firmware is a loss of 80-100Mbps. together with an increase in ping speed and jitter that affects the VPN connection too much. As I can see the difference on two AC5300's next to eachother it is simple: 386.7.2 is spot on, everything after that ... leaves room for improvement.

 

[L&LD]

Sorry, I shouldn't have said scripts, I meant the VPN profiles. What changes there?

Two RT-AC5300 next to each other? Are you turning one off before turning the other on, to test? And are you resetting your ONT/modem too, in between the two routers?

So your ISP speeds are ~500Mbps? If you're seeing 400Mbps bypassing the VPN, then your settings are not 100% matched. You're not importing saved backup config files between the two routers, are you?

 

[Tech9]

The flux of 20% less compared to the older merlin firmware is a loss of 80-100Mbps.

performance loss on OVPN

Your router can do about 60Mbps on OpenVPN. How come you lose 80-100Mbps? This is impossible.

 

[Martinski]

I would say slowing it down would be better than what Asus is currently doing. Also who's to say Asus will even do anything about it? They might just say it's working as intended and not change anything, so that's why I say maybe implementing something would be better than leaving the current behavior

As a temporary solution (until the issue gets resolved), you could try the "fail2ban" package from Entware. However, the caveat is that when the fail2ban server runs it takes a fairly good chunk of RAM (I don't recall the exact footprint, but it was significant), so I'd recommend it only if your router has 1GB of RAM or more. If your router has 512MB of RAM, it runs OK but only if you don't have several other built-in services or 3rd-party add-ons running concurrently which require a lot RAM as well.

If you're interested I can provide some instructions to install and set it up (I'll need to dig up the notes that I took when I set it up for a friend of mine about 2 years ago, and it's still running to this day, AFAIK).

 

[SheikhSheikha]

Sorry, I shouldn't have said scripts, I meant the VPN profiles. What changes there?

Two RT-AC5300 next to each other? Are you turning one off before turning the other on, to test? And are you resetting your ONT/modem too, in between the two routers?

So your ISP speeds are ~500Mbps? If you're seeing 400Mbps bypassing the VPN, then your settings are not 100% matched. You're not importing saved backup config files between the two routers, are you?

Nope 1 Gigaspeed fibre. Yes I do all the ropes. The comparison is valid. The VPN performance is as I describe. No changes in the profiles. And the difference is noticeable with both Protonvpn and expressvpn so it is not the vpn supplier. It is the router

 

[SheikhSheikha]

Your router can do about 60Mbps on OpenVPN. How come you lose 80-100Mbps? This is impossible.

Oops that was a type I meant 6mbps to 8mbps. The 80-100Mbps is the loss I have from the governmental proxy on a 1Giga internet connection (that is the connection speed without the OVPN activated).

 

[L&LD]

Hmmm, I don't know what 'yes, I do all the ropes' means.

6 to 8 Mbps less isn't anything I would worry about, particularly over VPN (too many variables to account for).