Allowing certain traffic (WhatsApp) for a user before he logs in to captive portal
-
I've set up a captive portal on pfSense with a RADIUS backend.
Everything works like a charm. I am using it to sell users 5GB Total traffic credentials and limit their bandwidth to 5down/3up Mbits (with exceptions for some users)Now, I would like to allow everyone connected to the WiFi (even non RADIUS users or when RADIUS rejects auth requests) to still use WhatsApp (including text, calls, and attachments).
I found resources to set up firewall rules to allow for WhatsApp:- https://tweenpath.net/pfsense-firewall-rules-whatsapp/
- https://developers.facebook.com/docs/whatsapp/guides/network-requirements
The captive portal config allows us to whitelist IPs and Hostnames. I mean, I could probably add all the IPs to the whitelists, however there are many. If there was at least a way to use IP aliases in the captive portal whitelist, but that doesn't seem to be the case?
Alternatively, I could live with allowing a very small bandwidth for unauthenticated users like 250kbits so that they at least can send and receive WhatsApp text messages.
I couldn't find any documentation on how the captive portal is working in the backend, which makes it hard for me to come up with a solution.
-
The captive portal is an all or nothing approach.
"Close to Nothing" ** is possible, you need to idenify first.
After that, the your GUI captive portal firewall rules apply.** edit : DHCP must / will function - DNS, the device should use the 'DNS IP' it got using DHCP request.
@PaulSzymanski said in Allowing certain traffic (WhatsApp) for a user before he logs in to captive portal:
I mean, I could probably add all the IPs to the whitelists, however there are many. If there was at least a way to use IP aliases in the captive portal whitelist, but that doesn't seem to be the case?
The "whitelist IP" or "hostname" solution might work. But not for sites like facebook (whatsapp) as these use these host names can point to random thousandth of IPs. Worse : they are taken out of circulation and new ones are addend all the time.
Remember : firewall uses IP addresses and doesn't know (can't use) host names, as it can't resolve host names on the fly : traffic would stall severally. Firewalls filter IP packets, and don't no sh*t about what host names are ^^ Host names exist for humans.To implement what you want, you have to 'mix in' your "whatsapp firewall pass rule" somewhere in between the current 'pf' captive portal rule set. that means some pretty serious 'portal script' rewriting.
And you still have to have an alias with all known IP addresses, that you have to keep up to date somehow.@PaulSzymanski said in Allowing certain traffic (WhatsApp) for a user before he logs in to captive portal:
I couldn't find any documentation on how the captive portal is working in the backend, which makes it hard for me to come up with a solution.
The device that actually make the captive portal work, isn't pfSense. It's, mostly, the device you use.
Also : use the console, or SSH, and
cat /tmp/rules.debug
Look for all the comment line that say " Captive Portal" :
Here is mine :.... # Captive Portal table <cpzoneid_2_cpips> { 192.168.2.1} ..... # Captive Portal ether pass on { igc1 } tag "cpzoneid_2_rdr" ether anchor "cpzoneid_2_auth/*" on { igc1 } ether anchor "cpzoneid_2_passthrumac/*" on { igc1 } ether anchor "cpzoneid_2_allowedhosts/*" on { igc1 } .... # Captive Portal rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8003 rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002 .... # Captive Portal pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy) pass out quick on igc1 proto tcp from 192.168.2.1 port 8003 to any flags any ridentifier 13002 keep state(sloppy) pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy) pass out quick on igc1 proto tcp from 192.168.2.1 port 8002 to any flags any ridentifier 13004 keep state(sloppy) block in quick on igc1 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13005 .... [ Your own GUI portal rules will be here ]
Now, all that matters is "how good is your 'pf'" ^^
(don't worry, even after xx years I have still to look up things) -
@Gertjan Thanks for your reply. Your pointer to /tmp/rules.debug was a good hint for me. I found the relevant scripts as well.
I will first have to learn about pf and will then decide if I want to continue efforts to adjust the scripts.It's just weird that there is no documentation. Even the scripts are very sparsely commented.