Block Wi-Fi sharing through mobile Hotspot !
-
Dear members,
We are seeking valuable solution from PFsense members on how to restrict/block users that are connected to the devices using another hotspot.Like for example :- We have wireless solution with voucher guest control (Captive Portal) and issuing limited period single user vouchers to users. Now, we came to know that,users are misusing the issued vouchers by sharing their connection to other customer through his mobile hotspot facility. As far as our concerned, this is major loophole and needs to be restrict/block at the earliest.
I hope the the issue above is clear and awaiting for somebody to help us to solve the issue as much as earlier.
Really appreciated any one prompt response.
Thank you. -
@sparktcs Yes ... exactly my problem. i hope pfsense team can help us to block that function as soon as the user is connected to psfsense database, the internet sharing or hot sporting from PC/mobile must not work.
-
@raymondchauke Needs to be escalate to concerned to sort out this issue at the earliest...
-
@sparktcs said in Block Wi-Fi sharing through mobile Hotspot !:
@raymondchauke Needs to be escalate to concerned to sort out this issue at the earliest...
It's an issue with the users.
Dude you do realise pfSense is Open source?
TAC Pro and TAC Enterprise is here if you're interested:-
https://www.netgate.com/support
-
@nogbadthebad
Through TAC or enterprise level suport is it can be sort-out this issue ASAP? -
@sparktcs said in Block Wi-Fi sharing through mobile Hotspot !:
@nogbadthebad
Through TAC or enterprise level suport is it can be sort-out this issue ASAP?I doubt it as its an issue with the user doing the hotspot activity, but if its an urgent issue ( you seem to think it is and use the term escalate ) you could try.
There are loads of other posts on this forum and other forums refreing to captive portals and hotspots.
-
@sparktcs said in Block Wi-Fi sharing through mobile Hotspot !:
Dear members,
We are seeking valuable solution from PFsense members on how to restrict/block users that are connected to the devices using another hotspot.
Like for example :- We have wireless solution with voucher guest control (Captive Portal) and issuing limited period single user vouchers to users. Now, we came to know that,users are misusing the issued vouchers by sharing their connection to other customer through his mobile hotspot facility. As far as our concerned, this is major loophole and needs to be restrict/block at the earliest.
I hope the the issue above is clear and awaiting for somebody to help us to solve the issue as much as earlier.
Really appreciated any one prompt response.Sorry for the late answer.
A "Netgate TAC Word Class black card VIP" member access won't give you an answer.
As this issue can not be solved - period.It's not a pfSense problem.
Its a router after a router problem.
pfSense being the first router - and the device sharing the connection being the second.Now go to Youtube, enter the search phrase "what is a IPv4 router - how does it work ?", look some videos, came back here and say " ..... wtf, this is an real issue, and can't be solved ".
Example,
Your ISP gives you a connection, with some IP like a.b.c.d./32
You slide in the RJ45 Ethernet cable in your PC, set up your NIC so it has a.b.c.d mask 255.255.255.255 - you add a DNS, add a gateway, the ISP gave you one, and know, your are connected !!!You'll say : one I, one IP ? What about all my other xx devices @home ?
Well, initially, you had to open xx number of connections to your ISP. Easy.But routers were defined. And 'local RFC1918 networks.
It works like this : on the local LAN, all devices can talk to each other as one big family.
Resources that are not on your LAN, like youtube.com (sorry : 216.358.209.238) do not "match" the local network (192.168.1.0/24) so the request is send to the local gateway : your router.
The router takes the incoming LAN IP (like 192.168.1.10 port 443, MAC aa.bb.cc.dd.ee.ff) as the "source" and initiates a TCP/IP session behalf of you on the WAN side, to "216.358.209.238 port 443". Answers coming back from the TCP session are converted back to 192.168.1.10, using the original requester port (not 443 per se).
Keep in mind that the 216.358.209.238 (youtube) never even sees the WAN MAC of the router (let alone le LAN PC MAC).
The beauty is : 216.358.209.238 will only see requests coming from your WAN IP, 216.358.209.238 can not see that these requests came from 192.1638.1.10 - or 192.168.1.253, or 192.168.1.58 etc. That info is on the routers WAN interface.
Internal states in the router keeps track of the "what TCP session belongs to what device on LAN".
And, no, you can "see" this state table on the WAN side. That would be a security risk.So, no, on the captive portal (just a LAN) you see "one" connected user == one IP, one MAC, and you can suspect that that single "user" using one voucher is actually generating the traffic of many users behind this "user" - as this user is a router.
Because all traffic is https these days (http is dead) you can't see a thing.
Don't feel alone here. The NSA/CIA/KGB/FBI can't see (decrypt) neither here : welcome to the club : you can't 'crack' https (TLS).So, as
@nogbadthebad said in Block Wi-Fi sharing through mobile Hotspot !:
It's an issue with the users.
said, it's a "user" thing.
When you suspect a user abuses his voucher contract, throw him of the portal.
But be careful, you can suspect, never be really sure.Btw : in a near future, when when IPv4 finally dies and IP traffic is all IPv6, there are possibilities as a single IPv6/128 can't be sub routed anymore.
Btw2: there were some tests with the TTL field in the TCP header, as every router hop decreases this field by one, but this wasn't really conclusive.
If I'm not mistaken, this was discussed in this forum, a decade or so ago. -
-