"Your Freedom" app😡

[pe1chl]

Again - in your scenario, there is no need to block “Your Freedom” selectively. Until a client has authentified himself via your login page, you can block everything except the login page. Once he has authentified himself, there is no need to block anything for him, as your interest is only to be able to charge a particular customer account for the traffic volume, and you don’t care what kind of traffic it is.

Well, that is not entirely true. In many cases where you want portal detection to work correctly, you need to enable DNS traffic even to unauthenticated users.
So most of these environments have DNS enabled all the time. You need at least to allow DNS towards the DNS servers advertised in the DHCP reply (maybe the router itself, maybe google DNS) so the client device can resolve DNS names outside your network and check the presence of a portal.

Now this opens a gap for a special VPN app that uses only DNS traffic, either to its own servers (you could block that) or to DNS in general.
You would need a quite tricky firewall rule to e.g. limit the number of DNS queries available to unauthenticated users. Not something that a user who needs to ask here is going to be able to create himself.

And indeed, according to their webpage, “your freedom” offers this mode of operation (alongside easily blocked techniques like PPTP).

[sindy]

In many cases where you want portal detection to work correctly, you need to enable DNS traffic even to unauthenticated users.

It depends on the overall environment. In public wireless networks - yes, the client types in any web page address, and to get redirected to the hotspot page, they must first be served a DNS response for that page so that their device would ever send a HTTP request that could be redirected to the hostspot page. Which is an approach that already fails as browsers remember that particular web pages use https and skip the initial connections to port 80 for these urls. And in this case, the DNS response must be correct, because the client device caches it, so once it gets past the login phase, it must be able to reach the actual server rather than land at the hotspot page again.

But even in this scenario, there is a way, I just don’t want to describe it to all the censors of the world. So @Sahafi2001, if your configuration export confirms that this is actually your issue, we’ll have to set up a private communication channel. Same offer to @pe1chl of course.

[anav]

Why the big secret.
If its a legitimate use of the MT OS, to ensure that any user on your Router gets redirected to the hotspot portal then it should be okay??

My question was is the OP, attempting to do this through the MT provided hotspot or through some other 3rd party portal system.
If so, isnt the right response use the MT provided portal??

[rextended]

@Sahafi2001
Where is Pablo Vidal, your MikroTik Certified Consultant?
Are you on forced leave for Covid?
He was fired?
He has been missing since May 30, 2018…

[sindy]

If so, isnt the right response use the MT provided portal??

No, it is not, because as @pe1chl has pointed out, you need to provide DNS service to clients not yet logged in order that any kind of captive portal worked, be it the Mikrotik one or a 3rd party one.

[anav]

If so, isnt the right response use the MT provided portal??

No, it is not, because as @pe1chl has pointed out, you need to provide DNS service to clients not yet logged in order that any kind of captive portal worked, be it the Mikrotik one or a 3rd party one.

Hmmm, so someone directly connected to the MT via an access point, has to go outside the router (to the internet) to get back to the router???
That is confusing to me, in other words, its not logical.
The only avenue for external DNS should be via hotpot portal after connection.
AKA
user/client not signed in ----------> no external DNS ------> go directly to internal hotspot login process (which may or may not include radius server etc).
user/client signed in ------------> traffic flow to hotspot (checks if logged in - yes) use DNS allocated to hotspot.
at no point in time should use ever be allowed to bypass hotspot control and use their own DNS.

Who designed this hotspot anyway LOL (okay so it boils down to I dont understand networking but an explanation to see the light would be most appreciated)

[rextended]

For all VPN by ICMP and DNS…

For block ICMP VPN, just limit all ICMP on HotSpot client side to 1 for second and drop ICMP with payload over 1500Bytes,
and VPN using ICMP port is not impossible, but is extremely slow.

For block “port 53” VPN, redirect all DNS call to 53 TCP and 53 UDP with NAT to RuterOS, and use RouterOS to solve the DNS,
any packet that are not DNS are discarded because uncomphrensible, and VPN using DNS port are impossible.
OR
Check all traffic directed to port 53 TCP and 53 UDP and DROP anything not matched by this layer 7 matcher, than match only valid DNS query:

/ip firewall layer7-protocol
add name=prot-dns regexp="^.\?.\?.\?.\?[\\x01\\x02].\?.\?.\?.\?.\?.\?[\\x01-\?][a-z0-9][\\x01-\?a-z]*[\\x02-\\x06]\
    [a-z][a-z][a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[a-z]\?[\\x01-\\x10\\x1C][\\x01-\\x04\\xFF]"

[anav]

hahah, what does all that code say in plain italian… (assuming its not in the 2021 MT Users Manual for Dummies.)

[honeyfairy]

Is there a solution to prevent the “Your Freedom” app from unauthorized access to the internet in my network through a firewall or something like that other than using pppoe server

Freedom App uses DNS as a transport. So block all TCP/UDP port 53, besides to 1.1.1.1 and 8.8.8.8

[rextended]

hahah, what does all that code say in plain italian…

Is a POSIX regular expression (regex) describing the start of packet containing DNS request.
f the packet are not matched, is not a valid DNS request, can be a VPN packet, for example…

^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[\x01-\x10\x1C][\x01-\x04\xFF]

[pe1chl]

Freedom App uses DNS as a transport. So block all TCP/UDP port 53, besides to 1.1.1.1 and 8.8.8.8

Do they use direct DNS traffic to their own servers? Is it only “the use of port 53” or is it real DNS traffic?

Because, it is perfectly possible to use real DNS traffic as a transport protocol and it would also work when you do it via another DNS resolver!
So such blocks will accomplish nothing if they do that.

[rextended]

If you limit the DNS packet, for example, to max 64B, and max request to 1 per seconds, the VPN is extremely slow…
Just the space for the fake domain name and some extra bytes

[Sahafi2001]

Thank you for your efforts and cooperation
I contacted a well-known programmer and he did hack protection, I’m not sure how it works, but I think he blocked port 80 and 67 and they worked if the hotspot page was logged in

[arkan7rb]

@Sahafi2001

Is there a solution to prevent the “Your Freedom” app from unauthorized access to the internet in my network through a firewall or something like that other than using pppoe server

can you post the solution that your friend has provided you with ? plz