@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.
