Cloudron Forum

@robi Wow Robi, this is a great feature request!!! Just yesterday one of my Cloudron instances got a lot of traffic to email for a bruteforce attack. @girish I think this feature have to put on the top of the list to improve safety but also to reduce workload of instances and network traffic... [image: 1610527791540-schermata-2021-01-13-alle-09.49.21-resized.png] This is a statping how network performances was impacted before and later bruteforce. Also, need a robust alert system - email or other - to let us know that something is happens.

@dkdkdkk what I do in similar cases is quite simple : allow routing between the 2 VLANs on the router. So, your Cloudron and the camera would be able to talk to each other directly. And you can still only allow the first VLAN to route to the internet. That's what I'm doing for my "smart home" stuff. This should check all your boxes

Looks like this is fixed upstream with next release then https://github.com/nextcloud/richdocuments/pull/1412

@shai said in Format for IP Blocking: If you are curious, blocking China and Russia came to 19,000 rows. Cloudron didn't stutter. The firewall does. It will take progressively longer to make fw changes as you keep adding IP blocks. Not an issue for one time things, but something to keep in mind.

@hillside502 yes, would be cool to map home networks and the upcoming Cloudron Multiserver.. and any ActivityPub App federations.

Follow up from the customer: "The issue here turned out to be that in Wordpress, WP Rocket caching plugin was used. This plugin automatically starts to preload the cache of each page once something in the site has been updated. The preload itself causes some stress on the CPU and maybe some other processes. Turning off the plugin, the products were sent for less than 2 mins." They are working with the WP Rocket team to find a workaround.

@girish I did not know the term. I certainly did know the effect ^^ (I might have to invest in an actual rubber duck... maybe they are especially effective)

@girish Hey, did just that, and I'm having trouble resolving names AFTER setting them. Cloudron is able to set dns records on aws just fine, but then the check to see if the records are created never gets done. Checked the logs and it's server timeouts. Tried running an nslookup query, to no avail as well. Kinda weird, seems like the same problem I had on the hosting provider, with unbound, maybe? When I try to sudo, it also says sudo: unable to resolve host ubuntu: Resource temporarily unavailable, but it gets me to root anyway. I'm a bit beyond my skills here, though, if anyone would like to chime in, I'd appreciate it.

Oh, interesting, I hadn't thought of those other use cases for this, but I really like that you brought them up, thanks for the feature request! I'll keep this thread updated with any development on that end if @girish doesn't beat me to it! ️

@robi Ahh, i completely understand now. This is a much complex level of what @girish and I are building right now with the VPN Client being one network you can choose to connect multiple other networks to. We’ve scoped that out pretty well so as we work on that and as it gets more fleshed out, I’ll update this ticket with advancements of how we might be able to have take this “sharing networks” basic concept further. I really like this train of thought though so I won’t forget it! ️

@girish https://www.ipdeny.com/ipblocks/data/countries/all-zones.tar.gz But I did get that from your blog post for 5.6: https://blog.cloudron.io/cloudron-5-6-released/ so maybe you're looking for better ones?

I use gluetun at home with an OpenVPN-based VPN service, and it works like a charm. Not sure how we would implement it in cloudron, though. At my home server I use a docker-compose file with all the services, and on the ones I want to use the VPN, I use network_mode: service:gluetun. Gluetun also needs NET_ADMIN capability enabled.

@girish stellar service as usual, of course it was the old node version, login works as expected now!

@girish confirmed - it works now. thanks.

@girish So, it was the TLS. Changed it to 1.2 and the requests went smooth and fast. Thanks for the tips