[Captive Portal] No internet access after successful authentication
-
Hello,
I am using PFSENSE 2.7.0-RELEASE with package installed (System_Patches sysutils 2.2.4, and WireGuardnet 0.2.0_2)
On a fresh installed pfsense, I have configured Wireguard with captive portal (disable mac filtering on captive portal, also not using DHCP as wireguard have IP address assigned manually),
Once user connected to Wireguard, they can manually open the captive portal login page to authenticate (example http://10.1.1.1:8002/index.php?zone=wireguard)
Authentication successful but no internet access is given to the user (if I disable captive portal, internet access works fine).This is the output of the anchor after user logged in
pfSsh.php playback pfanchordrill
---omitted---
cpzoneid_2_auth/10.1.1.2_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from 10.1.1.2 to any tag cpzoneid_2_auth dnpipe 2000
ether pass out quick proto 0x0800 l3 from any to 10.1.1.2 tag cpzoneid_2_auth dnpipe 2001Any advise or input on why the user did not get internet access after successfully authenticate ( I have tested both radius and local auth, both have same result, no internet access)
Thanks!
-
No DHCP .... No MAC filtering / let's hope the client can still do some DNS against 10.1.1.1, as that would give you (might give you) the "auto portal login page".
I guess that's not possible as your devices use static IP settings.For me, the captive portal is a LAN NIC thing.
Wireguard, is a WAN thing.I've been using an OpenVPN client for a while, and my setup was : LAN devices are all using the WAN, this was the pretty straight classic setup.
And all Captive portal users on NIC LAN2 (another LAN) are routed out over the OPENVPN client (so tunneled over my WAN) and ended up somewhere in {whatever I had chosen as an end point}.
I presume that 'OpenVPN' or 'Wireguard' is just a choice, both should work.When you say
@mindf said in [Captive Portal] No internet access after successful authentication:
I have configured Wireguard with captive portal
what do have to imagine ?
What I've said above ? Different ?Btw :
cpzoneid_2_auth/10.1.1.2_32 rules/nat contents: ether pass in quick proto 0x0800 l3 from 10.1.1.2 to any tag cpzoneid_2_auth dnpipe 2000 ether pass out quick proto 0x0800 l3 from any to 10.1.1.2 tag cpzoneid_2_auth dnpipe 2001
that looks fine. It's a authenticated portal user.
The next hurdle would by : the rules you have on the GUI portal interface firewall list.
If that one contains a pass (all), then your traffic enters the interface, is in the 'system' and ready to be routed (out == leaving some other interface).