I cannot used google analytics for captive portal
-
Not sure I can. Sorry. You might be trying to do the impossible from behind a captive portal. You'll have to wait to see if someone else chimes in.
-
This may not be what you are talking about. Here is how I use the captive portal to get a count of how many users connect to our library wireless. Setup a redirect in CP. Use the file manager in CP to save an HTML page with the GA code embedded near the top of the page. Just put whatever you want on the page itself. Every time a user accepts the Captive Portal terms ( or authenticates if that is what you are doing) it redirects to the page with the GA code and counts the login.
-
That sounds like it is post-auth so there is no need to pass the traffic to google analytics. The portal is already bypassed in that case.
-
@derelict said in I cannot used google analytics for captive portal:
That sounds like it is post-auth so there is no need to pass the traffic to google analytics. The portal is already bypassed in that case.
I dont think so. I had added domain www.google-analytics.com to Allowed Hostnames. This is domain Google's endpoint for track GA. But sometime client in private network cannot connect to https://www.google-analytics.com.
The same thing happens with the case domain ww.google.com.
I think google used many ip for www.google-analytics.com and Allowed Hostnames can not update mapping ip with domain. -
Is there a solution to this issue so that we can track user interactions in Google Analytics for a site opened within a captive portal?
-
@_malek said in I cannot used google analytics for captive portal:
opened within a captive portal
As soon as the device (user) as authenticated against the portal network, it behaves as any other LAN interface.
So, your question get somewhat simplified tocan we track user interactions in Google Analytics ?
Imho : Google Analytics traffic, is as any other traffic TLS, so start with an MITM "solution'.
( real pain is insight ) -
Just to clarify the situation a bit better:
the issue is not happening after the user is authenticated.
Once the user gets internet access, yes — everything works normally on the LAN.The problem appears before that point, when the website is displayed inside the captive portal environment inside an iFrame.
In this specific context, Google Analytics doesn’t track anything.To be more concrete:
If I open the advertiser’s website directly in the browser → Google Analytics tracks correctly.
If the same website is displayed inside an iFrame used by the portal→ Google Analytics stops tracking.
This behavior is consistent and reproducible.
So my question is simply whether there is any known workaround or technical solution that allows GA to collect interactions while the user is still inside the captive portal page, before they are fully released to the internet.
If you have any experience or insights about this specific constraint (iOS captive portal WebView, iFrames, cookie blocking, etc.), I’d really appreciate it.
-
@_malek said in I cannot used google analytics for captive portal:
before that point, .... Google Analytics doesn’t track anything.
Correct, before being authenticated, nearly** everything is blocked. That's what a captive portal is all about.
** Nearly, as DNS requests send the portal's network IPs (and only that IP) should work, and DHCP also works as you might have figured out already.
Edit : wrong, not even DNS.
'Web' Traffic is allowed to '800x' (http) and '800x+1' if https is also allowed (bot the the portal's interface only). -
Thanks for the clarification.
Yes, I understand that before authentication, most traffic is blocked — that’s the nature of captive portals.
What I’m really trying to figure out is if there’s any workaround to track user interactions with Google Analytics while the website is still shown in the portal page inside an iFrame, without requiring the user to open the site separately after authentication.
I know DNS and DHCP work as expected, but standard GA scripts seem completely blocked in this pre-auth phase.
Has anyone encountered a way to reliably track interactions in this limited environment, or is it technically impossible due to browser/portal restrictions?
-
@_malek said in I cannot used google analytics for captive portal:
I know DNS and DHCP work as expected, but standard GA scripts seem completely blocked in this pre-auth phase.
The device using the GA (?) script, or the GA script isn't portal aware.
Be aware : most of the portal support isn't what pfSense does. The actual portal support must be build into the device you use. Most recent OS's are portal aware, but there can still be 'programs' (processes) that 'see' the Ethernet interface is 'up' so a 'Internet' connection' must be there. This is a wrong assumption.
You don't do "Google Analytics" or anything else for that matter before the user has been authenticated on the portal.
Like unlocking your phone before using it, or leaving the toilet before unlocking the door.@_malek said in I cannot used google analytics for captive portal:
or is it technically impossible due to browser/portal restrictions?
A good browser is portal aware by itself.
Stupid browser plugins might exists that break this. That's not new.@_malek said in I cannot used google analytics for captive portal:
or is it technically impossible
The portal can have "Allowed IPs" and "allowed host names" lists : these two destinations types - both are eventually the same : a list with IPs - will pass through the portal firewall even when the user (device) hasn't been granted portal access yet. So it's a matter of 'find all the IPs' and your done.
The thing is : you want to use services from the "big ones" (Meta, Google, Microsoft, Apple, etc) and that is hard. These guys have thousands of IPs, entire AS sections, and they swap them in and out all the time.
Basically, what you are trying to do isn't the correct way.
If you have to use "Google Analytics" because, for example, you sold your user's device Internet usage to Google, don't put these devices behind a portal.
Or tell the users that they should connect first, and then and only then they can do what they have to do. Like : before driving a car, they have to start it first. They'll understand.The portal is just a concept that gives you the control "who us using your Internet resources".
For example, I have a hotel, so I want to offer an Internet connection to my hotel clients as an extra service. Not everybody surrounding the hotel. After all, I am still somewhat (more or less) responsable for what these stranger 'do' with 'my' connection.
Ones connected, the entire 'Internet' opens up for them. They can even launch nukes if they have the credentials to do so. What they are doing isn't my business.
If needed, I can route all portal traffic out over a VPN connection, so my hotel visitors , who use my ISP WAN IP (!) won't blacklist my (static) WAN IP. This rarely happens though, as the portal ads - I think - a strange effect to them : they think they are watched ^^
