Messages

Thanks, everyone.  This is all most informative.

Reading over the posts here, I think I'm in danger of making things a little more complicated for myself than I need to at this point (it's good to learn two new things at once; three starts to get confusing...).  But I'm reassured that OPNsense+bhyve+jail configurations are possible and reasonable, in various combinations, so that can come back on the menu later.

Best wishes,

Norman

Yes, jails do typically share the kernel – that's what makes them lightweight.  So running OPNsense as a complete OS would indeed require something like bhyve.

But OPNsense is to a substantial extent a layer on top of FreeBSD (someone will surely shout if I'm muddled about this), so given a suitable FreeBSD install, there will (?) be some set of installed userland software which would turn a FreeBSD install into a OPNsense install (this, as far as I understand it, is what opnsense-update does).  And walling different userlands off from each other is to some extent what jails are for.

I'm guessing, though, that opnsense-update won't work in a jail, simply because the jail won't have the right degree of access to (inter alia) the pf firewall in the host.

(To be clear, I'm running FreeBSD anyway, and it looks like running a full OPNsense install virtualised under bhyve is the next thing to explore, but I'm just trying to confirm I should rule out opnsense-in-jail as a more lightweight alternative).

Is there a way of installing and running OPNsense within a jail on a standard FreeBSD host?  And if there is, is that a supported mode, rather than a works-by-accident configuration?

It's looking very much as if the answer to the question is 'no'; is that right?  That means I can rule it out of my considerations, but it would be good to get that confirmed in words of one syllable.

I can see why one might not want to do this (for a firewall, a standalone box is mentally tidy, if nothing else), and I can see why this might be hard in principle (pf really wants to run in the host, so at the very least the jailed OPNsense would have to have some suitably tunneled way of communicating with the host).  But it would potentially be useful for experiments, and for the phase of the moon when I think 'the more in jails the better' rather than the phase where I think 'let's have lots of little boxes'.

I see a 2017 post (see [1]) which is titled 'Can I install Opnsense in an existing FreeBSD installation ?', but while that answer reiterates/reassures/illustrates that OPNsense is indeed layered on top of FreeBSD, it doesn't say 'jail' anywhere.  Also, the page [3] makes it clear that opensense-bootstrap is for converting a FreeBSD install into an OPNsense one.

There's a 2016 discussion [2] about jails, but that's really about whether more of OPNsense's services can or should be put in jails.

The 'Virtual and cloud' documentation [3] mentions various virtualisation options.  The absence of the word 'jail' on this page is probably telling me what the answer is here.

Best wishes,

Norman


[1] https://forum.opnsense.org/index.php?topic=4472.0
[2] https://forum.opnsense.org/index.php?topic=4078.msg22706
[3] https://docs.opnsense.org/manual/virtuals.html

Greetings.

The docs at https://docs.opnsense.org/manual/how-tos/user-ldap.html outline setting up LDAP-based authentication.  I can authenticate a user against my LDAP server, but I can't work out how to restrict this to users in a particular group.

The almost-relevant docs there describe doing so using the memberOf attribute (on a posixAccount object; this is the RFC 2307bis schema), but my LDAP directory uses the RFC 2307 schema, where group membership is defined using the memberUid attribute on a posixGroup object.

The documentation on that page is a little brief, and to some extent focused on how to use the interface, rather than going any deeper.  So is there any other documentation I should be consulting, but which I haven't yet found?

Specifically, I'm trying to find answers to the following (question 3 might render the answers to Q1 and 2 redundant).

  (1) In Step 1, I find "The Extended Query can be used to select users who are member of a specific group " -- great, just what I want.  But in Step 1.1 (optional) the page first of all talks about _importing_ users rather than calling out to a directory (ie, a one-time operation), and then in a 'note' says "This feature needs the remote ldap server to respond with memberOf when queried"  It's not completely clear what 'this feature' is referring to -- does this mean that OPNsense will only work directly with an LDAP server which uses the RFC 2307bis schema? (it's possible to play tricks on the server to synthesise some attributes when necessary, but I'd rather not go down that path unless I absolutely have to).

  (2) What is the actual query that's sent to the LDAP server?  Looking at the help for 'Extended Query', it appears that it's something like &(<usernamingattribute>=<requestedusername>)(<extendedquery>)  Is that right?  I don't think there's any way I can craft an <extendedquery> that checks that &(objectclass=posixgroup)(memberuid=<requestedusername>) has a non-null response.

But...

  (3) I found https://docs.opnsense.org/development/components/authentication.html which suggests that the OPNsense authentication defers to the underlying PAM system as much as possible.  If I were to configure the PAM system as I do on other FreeBSD machines, which successfully calls out to the LDAP directory, would I be able to leave all of the OPNsense authentication settings at (effectively) 'local' and leave everything to PAM?  In other words, is there a 'just do what PAM says' configuration setting? (or is simply failing to configure an LDAP server effectively that?)  Myself, I'd be more comfortable managing this via the PAM configuration, than via the GUI, as long as that's not a deprecated procedure.

Please do point me towards any forum posts which touch on this.  On a brief search, the nearest I found was https://forum.opnsense.org/index.php?topic=12558.msg60555 which suggests that group tests might be dependent on RFC 2307bis memberOf

Thanks for any pointers.

Norman