sysctl net.pf.share_forward=0 breaks captive portal redirection

[gjherbiet]

Hello,

I was testing multi-WAN this morning and I faced the problem reported in https://forum.opnsense.org/index.php?topic=4462.0

Once setting "net.pf.share_forward" to "0", multi-WAN works (I validated both fail-over and load-balancing), however this seems to break the captive portal redirection.

So, when "net.pf.share_forward=0", even for a client that does not have an active session in "Services -> Captive Portal -> Sessions" :
- it is possible to load an HTTP resource w/o being redirected to the CP
- it is possible to load an HTTPS resource w/o being redirected to the CP
- it is not possible to ping an external resource : this requires an active session to be enabled.

Thanks for investigating this issue.

[gjherbiet]

Just a complementary note on the OPNsense version in use:

Code: [Select]

OPNsense 17.1.1-amd64
FreeBSD 11.0-RELEASE-p7
OpenSSL 1.0.2k 26 Jan 2017

[djGrrr]

This is the expected behavior, the share_forward feature is what allows captive portal to work with multi-wan, it is a new feature in OPNsense 17.1; but unfortunately, there are bugs in the implementation that are actively being worked on. So if you need to turn off share_forward, then the features it brings will also not function.

[Wayne Train]

Hi,
so if I understand it correctly, the redirect to captive portal is broken, if I run OPNsense in a HA-Cluster with Virtual IPs ?
Or is there any workaround till now ?
Best regards,
Wayne

[franco]

No, reply-to was misbehaving for shared forwarding when Multi-WAN *and* the captive portal is in use. In case of HAProxy that is important because the OPNsense handles incoming external traffic which it then pushes back through the default route, not the reply-to interface.

We have a test kernel for this:

# opnsense-update -kr 17.7.1-re

It includes the newer Realtek driver *and* this fix:

https://github.com/opnsense/core/issues/1865

The fix also added to the upcoming 18.1-BETA. As far as we know that was the only outstanding bug that we had and we are considering using Shared Forwarding as the default in 18.1 (for new installations).


Cheers,
Franco