Captive Portal problem 802.1q

[M@rch0n]

Hello,

I need help, I believe this is a bug!

I have a scenario where I use wpad for my LAN and I have a GUEST for my clients and I need Captive Portal to register these users.

My firewall

WAN (em0) - 200.199.199.100
LAN (em1) - 192.168.0.1/24
GUEST (vlan100_em1) - 192.168.100.1/24

It happens that when I have the Web GUI in HTTP to provide the wpad to LAN clients the Captive Portal page does not automatically load in the 802.1q tagg interface. If I use the same configuration on the LAN page loads automatically and enables authentication, when the clients of the 802.1q tagg interface the page does not load automatically, it is necessary to enter the URL address to be able to authenticate.

If I change my Web GUI settings to HTTPS Captive Portal works fine for all interfaces, but LAN clients can not get the wpad information because of the certificate error that is not valid.

I thought that disabling the "Disable web GUI redirect rule" redirection in System> Settings> Administration would solve my problem, but not. When HTTP redirection is disabled, HTTP is disabled.

Anyone have any ideas for workaround?

[hbc]

GUEST (vlan100_em1) - 192.168.100.1/24

I guess it is em1_vlan100 

When HTTP redirection is disabled, HTTP is disabled.

That is right. With redirection, the web gui listens on 80 and 443. Every request to port 80 is redirected to 443. Without this redirect you have to use https:// to directly load web gui on port 443. Port 80 will be closed.

But wpad with https is a pain in the ass. You should deliver wpad.dat via plain old http.
Check this post how to set your web gui to https / alternate port and keep auto proxy config on port 80: https://forum.opnsense.org/index.php?topic=12026.0

I think the problem with captive portal is the fact, that more and more websites migrate to https, but I think the portal page is only triggered by a request on http. Did you try to open a plain http page? I think most browsers nowadays check for portal pages by calling URLs like http://www.msftncsi.com/ncsi.txt or http://clients3.google.com/generate_204, ...

[M@rch0n]

Nginx's workaround worked perfectly, thanks for the tip!

I think the problem with captive portal is the fact, that more and more websites migrate to https, but I think the portal page is only triggered by a request on http.

In my case, the problem only occurs when Captive Portal over HTTP on an 802.1q tagg interface. In this scenario, the page to authenticate only loads if I enter the URL manually http: // ip_fw: 8000. However, if my firewall is working with HTTPS the page to authenticate is automatically loaded.

Did you try to open a plain http page?

Yes, the behavior is the same.

[DahOne]

I am experiencing the same issue, and my configuration is very similar.
only when a visit a website that uses http, like msftncsi.com am i redirected to the captive portal page. Every other page returns a "this site can't be reached" error.

Any guidance on how I can overcome this would be appreciated.

[Jumpy71]

It'simply. If you want solution ask me.

[lilsense]

On OPNSense you cannot have tagged and untagged on the same interface.