Open rnicolaev opened 6 years ago
rnicolaev
commented
6 years ago Actually my issue is similar to this post https://github.com/wifidog/wifidog-gateway/issues/282
but what as I see, that guy also didn't get an answer, how it can be done in a proper way
benoitg
commented
6 years ago The short answer is that as the web moves away from http towards systematic use of https, and content delivery networks (CDN) this is becoming increasingly hard to do, and there is an increasing amount of complex code to write.
Basically one needs many additional features for this to work seamlessly:
(ok, not that short an answer it seems)
rnicolaev
commented
6 years ago Thanks a lot Benoit for your quick reply. One more question, is there any advantage of using LEDE + WiFidog solution in front of Radius server, in order to prevent user from accessing Internet. As I know radius server uses Java and its quite old.
What is your personal opinion?
benoitg
commented
6 years ago It really depends on WHY you are doing it.
However, if for some reason you will have a RADIUS server anyway, you may be better served by a radius-centric solution like https://github.com/coova/coova-chilli
rnicolaev
commented
6 years ago Our primary aim is to prevent user from accessing internet until he passes verification process. On login we show captive portal with login buttons and after we show some marketing features, like survey, or sponsored ads and etc. But we noticed that sometimes combination of Lede and Wifidog not very stable within big number of connections. Our competitors are mainly using Radius server for the same reason but we don’t like that it purely work on Java.
On Thu, Jan 11, 2018 at 11:21 PM Benoit Grégoire notifications@github.com wrote:
It really depends on WHY you are doing it.
However, if for some reason you will have a RADIUS server anyway, you may be better served by a radius-centric solution like https://github.com/coova/coova-chilli
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wifidog/wifidog-gateway/issues/287#issuecomment-357033030, or mute the thread https://github.com/notifications/unsubscribe-auth/AKGvGMRGbg_SKJOCi0ZiDrs3hPvlRm16ks5tJl8ngaJpZM4Ra72Z .
-- Thank you and regards,
Ruslan Nicolaev
JJEU
commented
6 years ago hello
## about wifidog performance yeah it's really bad. they are memory leaks too if used in a crowed place for several hours. I used to install openwrt on APU2C2 router boards for crowed places (one of the most powerfull solutions available. this thing can run windows 7 !). and i added an auto reboot each night, plus a script that automatically reboot the router if wifidog can't connect to the internet (usually it means that it crashed).
with all of the above, it's a bit better.
but still far away from the performace of the "appfree" fork of wifidog. this is done by a chinese team. but uses a "custom"version of SSL for compilation, wich is fishy. see their benchmarking results : https://github.com/liudf0716/apfree_wifidog/blob/master/doc/Apfree_WiFidog%E4%B8%8E%E5%8E%9F%E7%89%88wifidog%E6%80%A7%E8%83%BD%E5%AF%B9%E6%AF%94%E6%8A%A5%E5%91%8A.md
it's mostly in chinese, but the english parts allows comprehension. if you have dev able to audit the code and remove the possible backdoors (including the SSL module needed for compilation) it could be a good solution
Wifidog :
Benchmarking: GET http://www.taobao.com/ 50 clients, running 600 sec.
Speed=752 pages/min, 22274 bytes/sec. Requests: 6691 susceed, 830 failed.
Appfree
Benchmarking: GET http://www.taobao.com/ 50 clients, running 600 sec.
Speed=1462 pages/min, 162575 bytes/sec. Requests: 14618 susceed, 8 failed.
## About portal detection i had the same problem when i worked at Ile Sans Fil
if you really want to desactivate portal detection form cell phones and new OS, add this in your wifidog.conf file. in this scenario, DNS resolution MUST be served by the openWRT router. because the names are assigned to several IP. you want your router to resolve the name once, and use the same IP afterwards. so you need to
Note : its add new kind of problems. especially if the people are using an https start page.
for this reason I usually i just leave open the 443 in "unknown users" usually when browsing there is always a moment where you are redirected to a port 80 / HTTP ressource, so then the portal would kick in. blocking the 443 in this situation is really a support nightmare. calls and calls and calls
Also, if you check the logs, you will see that wifidog check each line each time a client connects, so it adds charge on CPU/ram/etc
Rule Set: unknown-users
FirewallRule allow udp port 67
FirewallRule allow tcp port 67
#uncomment this to avoid phone support nightmare :
FirewallRule allow tcp port 443
FirewallRule allow tcp port 443
#comment this for users to be forced to use your DNS only. it's important or else
# FirewallRule allow udp port 53
# FirewallRule allow tcp port 53
#Regles pour dejouer l'autodetection des pages portails sur les elephones intelligents
#apple
#FirewallRule allow tcp to www.appleiphonecell.com
#FirewallRule allow tcp to captive.apple.com
#Android Captive Portal Detection
#FirewallRule allow tcp to clients3.google.com
#FirewallRule allow tcp to connectivitycheck.android.com
#FirewallRule allow tcp to android.clients.google.com
#FirewallRule allow tcp to ggpht.com
#FirewallRule allow tcp to play.google.com
#Apple iPhone, iPad with iOS 6 Captive Portal Detection
#FirewallRule allow tcp to gsp1.apple.com
#FirewallRule allow tcp to akamaitechnologies.com
#FirewallRule allow tcp to www.apple.com
#FirewallRule allow tcp to apple.com
#Apple iPhone, iPad with iOS 7, 8, 9 and recent versions of OS X
#FirewallRule allow tcp to www.appleiphonecell.com
#FirewallRule allow tcp to apple.com
#FirewallRule allow tcp to www.itools.info
#FirewallRule allow tcp to www.ibook.info
#FirewallRule allow tcp to www.airport.us
#FirewallRule allow tcp to www.thinkdifferent.us
#FirewallRule allow tcp to apple.com.edgekey.net
#FirewallRule allow tcp to akamaiedge.net
#FirewallRule allow tcp to akamaitechnologies.com
#Windows
#FirewallRule allow tcp to ipv6.msftncsi.com
#FirewallRule allow tcp to ipv6.msftncsi.com.edgesuite.net
#FirewallRule allow tcp to www.msftncsi.com
#FirewallRule allow tcp to www.msftncsi.com.edgesuite.net
#FirewallRule allow tcp to teredo.ipv6.microsoft.com
#FirewallRule allow tcp to teredo.ipv6.microsoft.com.nsatc.net
Is there any way to block incoming HTTPs traffic except Facebook, because we are using facebook login button in our captive portal. But the problem is that we can't specify entire list of fb domains with one command like (www.facebook.com*). And if you will not allow all domains for Facebook the login page display incorrectly.
Your advise will be highly appreciated. As far as I know this can be easily done using radius server because radius server uses DNS from the router. But unfortunately we are not using radius server.