Feature: Reverse captive portal #7161
Conversation
…oing traffic through the firewall
|
for me this is a bit too vague, which use-case are we trying to solve with this? |
|
I have a lab that is hosting services that need access to the internet, but I want users that access those services directly to authenticate with a captive portal. |
|
A network diagram might help. If I understand you correctly you're forwarding traffic to hosts which are not allowed to access the internet unless being contacted from other networks. |
|
Users must authenticate to access the services behind the portal, but the services need access to the internet for functionality.
|
|
I'm not sure this is a use-case for a captive portal to be honest. Maybe we can think of something to optionally whitelist traffic heading inbound to the zone, but when trying to safeguard internal (webservices) a reverse proxy might be a lot more logical to be honest. Leaving this open for now to see if there are more people looking for a similar feature. |
|
I was searching for a possible feature request about a user captive portal and stumbled upon this. @HawksHail Would this feature allow the following scenario ?
That's the most interesting scenario I see, especially when linked to active directory with multiple groups. |
|
A reverse proxy would not handle the authentication I need though. It would also be nice to avoid the additional complexity of a reverse proxy if possible. |
No, I do not think that this would solve your scenario. It doesn't differentiate between different users. |
|
The Captive Portal scenario that @HawksHail is trying to mimic is one implemented in ForcePoint Next Generation Firewalls and used by large organizations with multiple labs within a large datacenter. Each lab may have a different LDAP group defining the users which have access to a specific subnet of equipment. The lab equipment must always have access northbound to the WAN. Once a user authenticates at the Captive Portal, he gains access to his authorized subnet. |
|
@vincente666 how is the feature called in Forcepoint (link to documentation might help)? I'm not against (optionally) allowing stateful traffic inbound to the zone, naming is one of the issues and implementation may need some work. |
|
Greetings @AdSchellevis, Thanks for your reply and taking the time to look into this. I am not a FW expert, but I love your product. @HawksHail works for me at a large company that has a Forcepoint NGFW set up in the exact fashion that we described. I was quickly trying to find the feature description from ForcePoint, but I didn't see anything immediately on the website. I truly understand your desire to properly name the feature. I too am a stickler for proper naming. I have a strange feeling it might not have a specific feature name -- it might be just the way FP implemented the Captive Portal functionality. We do not have direct access into the FP firewall. It is managed by a different organization. I challenged my team to prove that the OPNsense router could do the same thing. They have been very diligent looking into all of the forums and didn't find much discussion on the inner workings of the OPNsense Captive Portal, so they started digging into the code. We are going to try to find more info on the ForcePoint implementation. We will discuss more at today's SCRUM. I'll have the team post more here on this thread. Thanks again for taking the time to look into this. |
|
Also a member of @vincente666 team here, if it helps further this along the changes have been implemented to also not conflict with existing "normal" Captive Portals set up on the LAN side of the router. If naming scheme is the issue, feel free to call it whatever the OPNSense team decides. We are not married to the idea of calling it a "Reverse Captive Portal." The main reason we went with adding on to the implementation of the Captive Portal rather than a reverse proxy was the implementation of a login screen was much more straight forward and authentication with LDAP groups also exists. It also fit better for our use case. Thank you all for taking a look at this pull request and please let us know if you need us to provide more info on implementation details or reasoning for this additional feature. |
|
Greetings @AdSchellevis, the team was digging today and it seems to be inherent in the "Browser-Based User Authentication" functionality. That sounds like just another name for a "Captive Portal" to me. ;-) https://help.forcepoint.com/ngfw/en-us/7.0.0/GUID-440DD0A9-82C4-4FAE-B45B-591ABD40446C.html |
|
@vincente666 that sounds like captive portal indeed, but the real question is how is allowing inbound traffic called in their case (or another vendor)? reverse doesn't really sound logical as we're trying to allow a part of the (stateful) traffic here. |
|
To me this sounds like a zero trust setup, is that what we are going for here? |
|
Yes, the primary use planned for this is for user authorization to ensure users are allowed to access different sections of a network protected by the captive portal. |
|
Any update on this? What other blockers exist besides the naming of the feature? As @JacksonPaulHeck mentioned "feel free to call it whatever the OPNSense team decides." It would be great to have this feature added, regardless of the name chosen. |
|
priority, scope, external references to similar features to name a few. Our time is limited, the feature scope and possible side affects need to be clear enough. Not against adding functionality, but currently we have enough on our plate with higher priorities. Setup examples from other vendors with clear feature descriptions might help getting it higher on the list.... |
|
Hi @AdSchellevis, Did you try calling me? I got a random phone call from the Netherlands. |
|
|
Hello, However, I do not know what the proper way to modify the ipfw.conf file so the pkg can be installed without a force flag. Thanks. |
|
you can't merge this into a plugin as there is no integration point for it. At the moment it's not a priority to work on this, my earlier questions have not yet been answered, to be honest I'm not even sure if we're trying to change something that is standard on other platforms or it's an actual feature we're looking at... There's a reason why I asked for references (documentation) how other vendors call this specific feature (assuming it is one). |
|
I know that there is no integration for a plugin for the current captive portal. The idea would be to duplicate the whole functionality in the plugin to add this feature for users that want it. To attempt to answer some of your earlier questions, the scope of this feature is to allow users to authenticate with the firewall/captive portal to allow them access to services behind it while simultaneously allowing those services to bypass the authentication to reach other external services. This is a problem with the current implementation because whitelisting the services in the captive portal will allow bi-directional access to them instead of just outgoing. Here are some examples that provide this functionality: https://docs.netgate.com/pfsense/en/latest/captiveportal/allowed-hostnames.html https://help.forcepoint.com/ngfw/en-us/7.0.0/GUID-B626C0C8-4C3D-484D-8A7A-B2FF9833A44B.html https://www.juniper.net/documentation/us/en/software/jweb-srx22.4/jweb-srx/topics/topic-map/configure-captive-portal-for-web-authentication-and-firewall-user-authentication.html https://www.juniper.net/documentation/en_US/junos-space21.3/topics/concept/junos-space-cp-unauthenticated-user-overview.html https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_IdentityAwareness_AdminGuide/Topics-IDAG/Configuring-Identity-Sources-Configuring-Browser-Based-Authentication-in-SmartConsole.htm This appears to just be a standard feature for many firewall appliances, so it is difficult to find many examples. The captive portals on these other vendors is more tightly integrated with their firewall that the end user is able to configure what ever is required of their setup. However, OPNsense is using a separate firewall (IPFW) that cannot be modified by the end user and restricting what is possible. This feature would just allow users more choice to configure to their needs. This feature will not affect users that do not need it as the standard functionality is unaffected. I am also completely open to renaming this feature and/or expanding the explanation in the UI to be more clear to end users. |
Offering something like that would take quite some work from our end, which we are currently not planning to invest (and from a code maintenance perspective is likely a very bad idea)
That was basically my point, if we're looking at standard behavior, it likely doesn't make sense to add a toggle for it, but has to be thoroughly tested, which costs (community) time that I currently can not spend. I'm not 100% sure the proposed rule is the exact one we need, but I have to setup a test environment and evaluate in order to know that. Maybe if we're looking at a new base/kernel set there's an opportunity to setup a test and evaluate the change, but no promises. Unfortunately in our experience captive portal extensions seem to be of less interest for our (commercial) customers, we have to prioritize how we spend our valuable time as well. |
|
I'm sorry there was a misunderstanding about the duplicated plugin. I have already created this plugin and am asking for advice on how to deal with the one remaining conflicting file (ipfw.conf) and if it would be accepted into the opnsense/plugins repo as a community plugin. If it wouldn't be accepted there is there another place it could be released just to make it available for those interested. I used the toggle just as a simple version to get the functionality I needed. I understand that this would take valuable time and resources, and doing this properly would be a lot more involved. I hope this feature could be implemented eventually. I also discovered that PFsense supports this already and have added it to the example list above. |
|
let's keep this PR open, at the moment there's no option to include the feature, but if I do need to do additional testing for captive portal, I'll take a look what we can offer. |
|
Would it help speed things up if we changed the Captive Portal feature interface to be more like what pfSense implemented? Overall, I prefer the OPNsense UI to that of pfSense. |
|
how on earth would that help to solve a lack of (community) time???? If you do prefer me loosing interest at all for a feature you likely (commercially) need, my advise is to keep pushing. |
|
I was talking about changing the toggle switch that @HawksHail implemented to IP address ranges like pfSense implemented. (See how pfSense did it.) We use it in a lab. Nothing commercial. We want to share it with the community. |
AdSchellevis
force-pushed
the
master
branch
2 times, most recently
from
be6c1bb
to
030ed19
Compare
Adds a new option to allow outgoing traffic through a captive portal interface.
The primary use for this feature is to place the captive portal on a WAN interface and allow services hosted on the LAN to reach out unauthenticated, but users needing to access the services directly will need to authenticate with the portal first.
The rules have been tested and work as described allowing outgoing connections and their replies. while blocking external initial connections.
A checkbox has been added to the advanced section of the captive portal zone editor that enables the new rules.