Messages

@hbc because as @mimugmail pointed out, LDAP (even though the domain controllers are actually using LDAPS)
doesn't work if the password's sent cleartext. This was my logic behind using the imported users; being already in the system I'd be circumventing the sending-credentials-in-the-clear part necessary for tunneled EAP. Apparently not, plus...I think it still queries for updates the upstream servers anyway, it's in the documentation I believe.

@mimugmail Yeah I know. Unfortunately I just can't quite get it to work: I deployed a separate dedicated FreeRADIUS server, joined AD and get it to authenticate to AD, users can log in to the system with their AD credentials and Kerberos works flawlessly, also using the FR CLI tools for testing pass all tests. However when it's time to FreeRADIUS to do it's thing with an actual client something fails. :( So far the only RADIUS server I've been able to get to work using the AD base it's NPS itself! I'm OK with that but it's missing some protocols and the extra attributes from the hotspot services that make it super useful, OPNsense's got those built-in.

This leaves me more confused as there's a tiny Nextcloud instance that also uses LDAP to connect to AD, in order for it to be able to let users modify their passwords LDAPS must be used so no cleartext credentials are flying around from server to server unprotected, pretty much the same concept of FreeRADIUS's. Just as OPNsense, Nextcloud works fine with AD through LDAPS, the actual directory not that ADAM decoy thing. Other non-MIcrosoft systems work fine too, like Synology, Univention...macOS Server even "Kerberizes" services.

Anyway, thank you both for getting your answers. I'll keep trying. Maybe I have better luck on an Ubuntu-based distro or something like that. I really like the OPNsense UI though, and I had just discovered the themes too! :(

I've been trying without luck to setup FreeRADIUS with Active Directory for a while now, apparently that'll never happen for me. LDAP both OPNsense's FreeRADIUS and OPNsense itself is setup correctly; I tried starting in another system and learned in the documentation that LDAP is useless for the tunneled EAP types anyway.

But since the users from LDAP were imported into OPNsense itself, I'd be using local users, therefore tunneled EAP should work, right? That's what I hope for anyway. I don't know how exactly instruct FreeRADIUS to use the system userbase, I don't think it's automatic because I can't authenticate with any of the imported accounts.

I figured, maybe I need to add users into FreeRADIUS, but when I go there within the information I'm also asked for a password to proceed. I don't know if by entering this value the previous is going to be changed for the account in question, or if it's going to set a different password altogether which sort of defeats the purpose of the integration.

Is it doable? Are the settings elsewhere? Thanks!

I've been playing with the firewall now that's not doing anything in the network (and there can't cause any damage) and discovered this issue is triggered my enabling monitors on gateways. It will lose all connectivity on the parent interface with the monitored gateway--so, if you add a single interface like I've been doing, you'd lose ALL of it. If you want to troubleshoot from console, the console menu lacks the option to configure these values unless you're a wiz with FreeBSD's shell (I'm not) but if you happen to lose connectivity quick enough (it's not always fast, it may take a big big while) you probably didn't make enough modifications so you can still roll back changes in console.

OPNsense has the ability of increasing the rollback points history thankfully. It must be done from the web GUI, and obviously beforehand, preferably shortly after installing set that thing to something bigger, I went with 200, then you can go back to the new install wizard on the column menus anytime. :)

OPNsense has issues, a lot of them, regarding gateways. I'm starting to understand how it handles things. In my case, I have a multi-WAN setup, 3x PPPoE connections to the same ISP: this creates an unbelievably large amount of issues with random connectivity issues because I have the same gateway on the 3 links. It's fixed this by putting a pfSense edge appliance in front of OPNsense, have the edge dial the PPPoE and create 3 new PPPoE servers in the edge, so from OPNsense's point of view it would have three different gateways. pfSense doesn't have problem with this, and pfSense was (and again is for the time being) what I'm using to connect so naturally I expected OPNsense to behave the same way since both very similar to one another.

The confusion is further amplified by the fact that both pfSense and OPNsense in their documentation are ambiguous about gateways issue and what is shown are actually screenshots for the DNS servers for the firewall, how to designate a different DNS server per gateway, not how to designate the gateway. What I have not tried is creating a gateway a virtual IP to mask the same gateway. I don't think it'd work but so far what I'm expecting to do for things to work is never what needs to be done, so...yeah.

I was designing a UI for a local system and playing random stuff of YouTube as whitenoise on another computer when both suddenly lost their connection. The one playing YouTube was the odd one since usually YouTube/Netflix/... can keep on going for a while on their buffer when the network is lost. I had an IP address, but I couldn't ping my immediate gateway, not anything above it. I could still connect to another computer on the same subnet which is doubled homed and from there see what's up, I connected to the upstream router, pfSense, which basically does most of the networking, it connect via a transit network to OPNsense, and that to the first core switch, at least logically--it's all virtualized.

I logged into vCenter to get the consoles from both firewall systems, the upstream could ping out, OPNsense on the other hand showed the network interface reading "watchdog timeout on queue 0" filling the whole screen. It would keep printing that. I restarted it and as soon as it got back it wasn't finished booting when it was printing that again. Like I said, the edge firewall was doing most of the work anyway, OPNsense I was just starting to deploy to play with the things it has pfSense lacks, I just made the switch take its IP address of the /30 transit network and I got back where I was.

I'm quitting OPNsense for now, I've tried to deploy it several times but I just can't get it to be stable--and it's not like mundane things, it's a little more serious with potential for data loss, like not starting up on the update to 19.1; or connectivity problems on multi-WAN with the same ISP (hence same gateway)--I was able to spoof the gateway with another router in between, BTW, but it sort of defeat the purpose of such an advanced system. :/

Anyway, I thought I should report it. I hope it helps somebody. Also found out that to boot a failed EFI-based 19.1 upgrade, you can just change it to BIOS without reinstalling! I reported that on Github, though.

So it isn't safe to upgrade yet? I just went through this for the first time, and several boots where it says "cd0" is waiting for something or the other way around, at that point I have to hard-restart the system.

The first time it showed me the kernel error I tried booting the old kernel and it showed me the cd0 error. I begged for it to come around if I tried again and luckily it did. Right away after booting it mentioned something about upgrading the system, but it actually went to 18.7.10_4 which in a way *is* upgrading because I think I was on 18.1, I pulled the image from a local file server to get started faster.

I took two snapshops, one with memory and backed up immediately after the system came up. I'm also getting a lot of this, even before the upgrade, is this normal?

Hey guys, first post :)

I just moved to OPNsense and but it updated on me and lost the ability to import aliases and I have a ton (I'm coming from the other *sense) so I thought I'd outsmart it and deployed a local VM with it, extracted the aliases from the other platform's XMLs imported them into the dummy OPNsense to export them back out into an OPNsense native backup and merge them with the current config now almost stable.

However, when I went to the working install I couldn't quite figure out where to put merge the backup in. I only modified aliases in the dummy OPNsense, nothing else, not even the initial setup except for the interfaces (about 2 dozen vs 1 in the dummy) and the aliases there should be nothing to overwrite...I think.

I exported a backup from the working install searched for the alias lists and compared it to the backup from the dummy install and I saw that they're nothing alike, so there went my chances merging it myself, manually...plus I tried editing one of these files before and I guess it was digitally signed or something because I broke down horribly.

The best fit to restore them would be under Firewall, but there's no such option, the way it's listed it sorf of screams not here. Then I thought maybe DNS, because they're aliases...but System could work as well because they work system-wide. I'm going a little insane here. If you have any advice to offer I'd be immensely grateful ! <3

Did you have any luck? I'm new to OPNsense coming from the other *sense and I saw and actually used the feature but for a tiny list only because I had just installed and was still exploring...then updated because it told me I was vulnerable to Blah and Blah2 and I blindly hurried to click the clinical-sounding-labeled button that's basically "update" or something I forgot what it says and now I'm kicking myself for not having it used it before it went away.

How did you manage??--I'm going to try deploying the firewall on a VM, importing the aliases and making a backup of the firewall to selectively restore the aliases--and for a minute I almost missed out on that because for some reason I deleted the installer, something I never do, but the ISO server had the recycle bin feature on on that specific share. I'm pushing my luck hard here. :D