Captive portal - what am i missing

michmoor

Rules look legit.
I have it enabled on two interfaces for testing and neither of them are able to redirect to the pfsense log-in CP page.

# Captive Portal
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass out quick on igc2.17 proto tcp from 192.168.17.1 port 8003 to any flags any ridentifier 13002 keep state(sloppy)
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
pass out quick on igc2.17 proto tcp from 192.168.17.1 port 8002 to any flags any ridentifier 13004 keep state(sloppy)
block in quick on igc2.17 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13005
pass in quick on igc2.141 proto tcp from any to <cpzoneid_4_cpips> port 8005 ridentifier 13006 keep state(sloppy)
pass out quick on igc2.141 proto tcp from 192.168.141.1 port 8005 to any flags any ridentifier 13007 keep state(sloppy)
pass in quick on igc2.141 proto tcp from any to <cpzoneid_4_cpips> port 8004 ridentifier 13008 keep state(sloppy)
pass out quick on igc2.141 proto tcp from 192.168.141.1 port 8004 to any flags any ridentifier 13009 keep state(sloppy)
block in quick on igc2.141 from any to ! <cpzoneid_4_cpips> ! tagged cpzoneid_4_auth ridentifier 13010

stephenw10

How are you testing? Almost all browsers and mobile devices these days will detect the redirection and open the login page directly.

If something doesn't do that and really gets redirected you will still see a cert error even with a valid LE cert on the login page because it won't be valid for the site the user tried to reach.

michmoor

@stephenw10
I would normally agree but I tried on a Windows laptop on chrome and Firefox,
Then I tried on my wireless vlan on my safari browser.
I never had an issue in the past so I’m more than willing to toss it to a config error but I don’t see how. Additionally I got those ssl nginx errors which correlate to CP

stephenw10

If you visit the portal login page directly does it display correctly?

michmoor

@stephenw10
Great question.

portal.xxx.com is a IP Alias i made - 192.168.50.211

pingable and resolvable.
going to the page on port 8003 doent work
I tried from a trusted LAN which has a permit-all and still nothing. ERR_CONNECTION_TIMED_OUT

michmoor

Ive turned off authentication and just have CP working. When i visit a site like bing.com i get th e"Your connection is not private". I look at the certificate error and i do see the CP cert 'portal.xxx.com' but of course doesnt match up with the domain name BUT i should be redirected anyway never seeing the cert error.
This is strange to me and never seen this behavior in the past when i enabled this.

stephenw10

Are you blocking http?

You should be able to hit the CP login page directly though if you're in the CP subnet.

michmoor

@stephenw10
I re-arranged the Reject rules to the bottom for now.

From the other CP zone you see a permit any/any rule.

michmoor

@stephenw10
Update. I am able to hit the CP site from an interface not behind a captive portal - a super trusted segment.
So the question is, why isnt pfSense redirecting properly?

stephenw10

Hmm, do you have IPv6 enabled there?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html#captive-portal-does-not-redirect

Is it listening on port 8003 in sockstat?

stephenw10

Ah can you hit it using https?

michmoor

@stephenw10
I can hit it via HTTPS plus i see open sockets for it.
This is just very strange behavior.

stephenw10

So it seems like it's just not redirecting at all?
Do you see states to port 8003?

Do you see the redircet rule in the ruleset? Like:

# Captive Portal
rdr on bridge0 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.221.1 port 8002

Is you test client in the CP table already so it's not being redirected?

michmoor

@stephenw10
This seems to be a failure in redirection. I see states. at least.

For good measure i rebooted my pfsense (this is my home) just to make sure there isnt any issues. This also means the boot env loaded is still 23.09.01 but the config it decided to load was where my portal IP is 192.168.11.1
Thats ok because it should work on that IP as well considering i have a permit any rule

 cat /tmp/rules.debug | grep cpzone
table <cpzoneid_2_cpips> { 192.168.17.1}
ether pass on { igc2.17  } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/*" on { igc2.17  }
ether anchor "cpzoneid_2_passthrumac/*" on { igc2.17  }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc2.17  }
rdr on igc2.17 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.17.1 port 8003
rdr on igc2.17 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.17.1 port 8002
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
block in quick on igc2.17 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13005

stephenw10

If you view that in Diag > States do you see the redirect happening?

michmoor

@stephenw10
Is this accurate? portal.example.com has a DNS entry of 192.168.11.1. But it seems i see CP grabbing the internet flows to the clients gateway (192.168.141.1) on port 8003

stephenw10

Yup. And on port 80. Yet you don't see the browser detect it's behind a portal? Hmm

michmoor

@stephenw10
Thats exactly right. On paper everything should work. DNS entry is good, States on the firewall are shown. We see redirection happening at least on the output above.

Yet the "Made with Love" Netgate page does not show up. This happens on any interface i enable CP on.
I honestly don't get it and i dont know a way to do more verbose output within PF to see whats going on.

The closest i can find to this behavior in the forums is here. https://forum.netgate.com/topic/178297/help-needed-captive-portal-not-working-no-login-page/15

No resolution sadly

stephenw10

Do you see any traffic from that client that isn't redirected? That just passes the firewall directly?

In that other thread the users test client was somehow still seeing successful responses to Apples CP test.

michmoor

@stephenw10
No internet connectivity is possible.
In fact i get SSL Warning messages in my browser. The cert given is a valid ACME certificate but of course the domain doesnt match up to the CN hence the warning.