OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of msi »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Topics - msi

Pages: [1]
1
22.7 Legacy Series / LDAP user auto creation: A way to set (default) login shell for LDAP users?
« on: October 26, 2022, 07:02:09 am »
Hi there

I've realized that while LDAP autocreation of (in my case admin) users work pretty well (definitely appreciate it!) and newly-created accounts get the right permissions in the Web UI based on LDAP group memberships, even sudo worked - but the login shell defaults to /sbin/nologin.

The result is that even if they add their SSH keys such users cannot log in via SSH nor can they log into a shell on i.e. the local VGA or serial console.  ;)

I've realized this on our OPNsense cluster on 22.4 but was able to reproduce this on my personal system running 22.7 I know it's minor but I tried finding options in the UI and source code for either:

  • Define the login shell based on an LDAP attribute mapping (this can have disadvantages if LDAP is unavailable)
  • Set a selectable default shell for new-ly created users in the auth server?

It took me some time to realize what (seems) was happening at first. Looking forward to an input, maybe I can figure out a small addition to the Authentication code in the core repository.

Any other/better ideas?

2
Hardware and Performance / Intel E810 (Columbiaville): Experiences?
« on: March 28, 2022, 08:17:41 pm »
Hi there

I wanted to ask if anyone could share some experiences on the new PCIe 4.0 800er series Intel NICs as I've only found someone having intially had some performance issues with them in this thread: https://forum.opnsense.org/index.php?topic=24302

Global delivery chain issues have now come to the point where obtaining known-to-work Intel 700 series NICs has become difficult. After considering more readily available Broadcom NICs instead, I realized that Netmap support, as required by Suricata and Zenarmor looks dim with bnxt(4) based on reading FreeBSD manpages. So I was looking at the 800 series cards like the E810-XXVDA2.

However I'm partially burned by the ugly issues the earlier firmware I've initially faced when I got the first 700 series NICs. Most of these stability issues and bugs I've faced on FreeBSD, Linux and Windows are now fixed by current firmware (which for some OEM cards can be difficult) and drivers. They are not new anymore and usually they are now "OK to work with" in my opinion.

The 800 series however are using new chips have more feature-rich firmware (read: potential for new bugs) and use a new driver ice(4) instead...

3
Development and Code Review / RADIUS authentication: Thinking abut
« on: October 29, 2021, 04:55:01 pm »
Hi

A colleague and I have mostly migrated from pfSense to OPNsense since summer and besides of some human habits that need to change a bit, the migration has been very smooth. (and we definitely plan on getting a business subscription).

While migrating the remaining OpenVPN service to it, my colleague and I ran into an issue that is due to the divergence between OPNsense and pfSense: Our 3 OpenVPN instances (that have different access policies) are currently authenticated against RADIUS backend and therein lies the issue:

Currently we are not able to clearly identify if a RADIUS Access-Requests coming from the OpenVPN server, nor which instance it is.
  • On pfSense NAS-Identifier is "openVPN" while NAS-Port contains the port on which the OpenVPN server is running (i.e. 1194, 1195 etc.).
  • On OPNsense NAS-Port seems to always be 0 while NAS-Identifier is a random string per RADIUS server backend defined in OPNsense (as <refid></refi> on config.xml)

Technically we can move that to LDAP, but we have been quite happy with the fact that we delegated the authorization part to our FreeRADIUS servers instead of implementing this logic on the Firewall side.

Based on checking both source code repos, this differentiation in RADIUS requests was only added after the split between both projects. And that code was only added when pfSense has switched their license and has diverged quite a bit by now.

It seems that expanding some bits in https://github.com/opnsense/core/blob/96214877bef00c196903a9ec8b4e1afac75b7a18/src/opnsense/mvc/app/library/OPNsense/Auth/Radius.php#L106

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2