Messages

1

Hardware and Performance / Re: OPNSense & NanoPi R4S (RK3399)

« on: May 10, 2022, 05:26:07 pm »

If you have 1gb internet than no arm device can handle it atm unless you use macchiatobin or clearfog as most sbc are low end cpu soc with limited IO like the gigabit Ethernet are not powerful enough to give you full performance. 

Best option for you is to use x86_64 device

Sorry, but that's simply not the case. It may be true for OPNsense-based (FreeBSD kernel), but the linux-based OpenWRT works at ~940mbps bidirectionally without breaking a sweat.

I've seen posts where folks running FBSD kernel can get 940mbps, so it's quite possible that the problem lies with something poorly configured in HBSD, but I don't have the resources to purchase a second device just to troubleshoot. I don't realistically have the time, even if someone buys me one, to dig into this, but I really hate when folks say things that are clearly not the case.

I see that Sergey now has a 22.1-based image over on PersonalBSD I may try just to see if it's any better, but setting everything up over and over gets tedious...

2

Hardware and Performance / Re: [Work In Progress] OPNsense Ported into ARM Devices

« on: March 08, 2022, 04:21:25 am »

I really wanted to like OPNSense.

However, after installing it on my R4S (what an amazing tiny device!), I found that my best throughput on a hardwire to my GB fiber was about 500Mbps (usually less!).

When I installed OpenWRT, I can get 940+ (that is to say, wire speed, for a Gigabit ethernet line).

Same hardware, same connections.  Even the same plugin (AdGuardHome) running.

Open to suggestions for improving speed, but otherwise, I really can't justify sticking with OPNSense.

3

Hardware and Performance / Re: OPNSense & NanoPi R4S (RK3399)

« on: February 11, 2022, 09:09:24 pm »

root/opnsense

By default, though, on FreeBSD (inherited by most derivatives...) you cannot log in as root via SSH. On mine, I had to enable both "enable root login" and "enable password login" on the GUI to be able to log in.

The GUI allows you to create additional users, which is much preferred over allowing root logins directly. Also highly recommend using SSH keys instead (but you'll need to be in the GUI for that)...

4

Documentation and Translation / Re: AdGuard Home setup guide

« on: February 08, 2022, 08:37:28 pm »

I understand your view and opinion. But me for instance, i like the plugin concept. When being able to control opnsense and additions from the gui makes it easy and clear, gives a feeling of control compared to having to go to terminal / having to go and enable ssh for every install feels a bit threshold for me. I also like being able to get into the gui and control things in opnsense while being away by vpn and the comfort of my phone.
So with that being said; opnsense is all about being able to have many ways of control, the gui, terminal/ssh etc. So with both options available, everybody is happy :-)

I guess my main point was more for the "guide"; it really isn't difficult, and once installed the need for the cli is minimal.

It's probably also fair to note that I am the type who prefers the simplicity of a cli. Given the choice, I will almost always choose a cli over a gui because the  vast majority of the time it's faster, and the gui usually is just an abstraction around the cli anyway, and often makes assumptions that are hidden (or can't even be set).

That said, I understand that lots of people prefer a gui approach, even if it is slower and less secure. For me (and after reading this thread, I know I'm not alone...), if what I wanted was a 99%  GUI solution, I'd be running OpenWRT instead.

You *can* access your AdSense gui from a vpn easily enough. If you use the virtual IP approach, it wouldn't even feel weird because it would feel like you are logging on to a different host.  It's no more difficult to access the AdGuard gui from your phone than OPNsense (arguably easier, because AdGuard's mobile interface is well optimized).  You also can SSH on a vpn. I have a terminal program for my phone, even, that I could use.  Granted, securely using ssh requires a bit of work, but if you can install the mimugmail repo, you can run the two or three cli commands for key-based (as opposed to password-based) ssh login.  That's well out of scope *here* but I bet there's already guides for that...

5

Documentation and Translation / Re: AdGuard Home setup guide

« on: February 08, 2022, 05:51:13 pm »

I recently acquired a NanoPi R4S. Amazing router, and trivial to run OPNsense.  However, the mimigmail repo doesn't work on aarch64.

Which leads to the question of why it's even necessary.

Installing the mimugmail repo already implies SSH access to run the requisite `fetch` command.  So why not simply `fetch` the freebsd native adguard home?  At that point, you just have to extract the archive, and then follow Adguard's own installation steps.  Nothing terribly complicated there, beyond knowing that OPNsense is Freebsd-based, and what architecture you are running (likely 95%+ AMD64).

Yes, adguard will complain that port  80 is in use. Pick another one! (3000 works, unless you are running graphana on the same host. 8080 works too, unless you are running nginx on that port.)

If you don't stop unbound, it will complain about port 53, too, but you can either move adguard (and then point unbound to adguard), move unbound to a different port, or stop unbound. (adguard already does most of what unbound does).

As an alternative, you can load adguard (and other!) lists to unbound.  A few years ago I wrote a script to "manage" black- and white- lists with unbound (whitelists being local overrides to the public lists, much like adguard does), but I abandoned that work after I found Adguard Home and realized they had already solved (better!) the big problem I was trying to solve: given a device trying to access a site, how do I know which site is blocked. It's easy to whitelest the site, but fairly difficult to parse the logs to see.  Adguard gives me a simple interface to see that, and with a click I can whitelist the domain, either everywhere, or just for that one device.

I really don't think a scratch install is any more complicated than installing a custom repo...