Messages

1

17.1 Legacy Series / Re: sysctl net.pf.share_forward=0 breaks captive portal redirection

« on: February 14, 2017, 02:01:12 pm »

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

2

17.1 Legacy Series / sysctl net.pf.share_forward=0 breaks captive portal redirection

« on: February 14, 2017, 01:59:23 pm »

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.

3

17.1 Legacy Series / Traffic Shaper schedule

« on: February 14, 2017, 11:02:41 am »

Hello,

So far Schedules can be used on firewall rules. Is it conceivable to have them also apply to Traffic Shaper rules?
One use case is to limit a Guest VLAN bandwidth during office hours only when shared on a single Internet line with business applications.

Thanks for your reply.

4

17.1 Legacy Series / Re: Captive portal shall return HTTP 302, not HTTP 301

« on: February 09, 2017, 10:16:24 am »

Works as intended. Thanks.

5

17.1 Legacy Series / [SOLVED] Captive portal shall return HTTP 302, not HTTP 301

« on: February 08, 2017, 04:12:54 pm »

Hello,

I'm fairly new to OPNsense (actually I'm just test-driving it for the moment) and I'm facing an issue with captive portal setup.

To perform redirection to the captive portal, the underlying lighttpd server replies with and HTTP 301 "Moved permanently" status (see curl output below).

Code: [Select]

$ curl -I http://www.opnsense.org
HTTP/1.1 301 Moved Permanently
Location: http://192.168.1.1:8000/index.html?redirurl=www.opnsense.org/
Date: Wed, 08 Feb 2017 14:48:41 GMT
Server: lighttpd

$ curl -I http://www.opnsense.org
HTTP/1.1 301 Moved Permanently
Location: http://portal.test.tld:8000/index.html?redirurl=www.opnsense.org/
Date: Wed, 08 Feb 2017 14:49:03 GMT
Server: lighttpd

However this has the downside effect that browsers will remember this redirection. Once the user has activated its Internet access, or even if you switch network, and type the same url that triggered the captive portal, the browser will perform the redirection by himself.

I noticed that by switching a client between a test network (behind a OPNsense RFW with captive portal enabled) and my regular network.

This was experienced with a MacBookPro7,1 running macOS Sierra 10.12.3 and impacted bot Safari 10.0.3 (12602.4. and Google Chrome 56.0.2924.87

The OPNsense version is as follows:
OPNsense 17.1-amd64
FreeBSD 11.0-RELEASE-p7
OpenSSL 1.0.2k 26 Jan 2017

I have already worked with captive portal setups and in all examples I have in mind redirection was performed using HTTP 302 "Found" status code to redirect to the captive portal page.

To comply with RFC 6585, the captive portal page should reply an HTTP 511 "Network Authentication Required" status (although I think it breaks Apple iOS captive portal detection and might be reserved to "regular" browsers only).

I would be happy to be directed to the relevant lighttpd code and issue a pull request, or to have it fixed in next release.

Regrards,