Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running NDS without Internet Access #328

Open
bluewavenet opened this issue Nov 19, 2018 · 34 comments
Open

Running NDS without Internet Access #328

bluewavenet opened this issue Nov 19, 2018 · 34 comments

Comments

@bluewavenet
Copy link
Member

@bluewavenet bluewavenet commented Nov 19, 2018

Running NDS without Internet Access
or more precisely
NDS Automatic Offline Support for Client CPD

The Issue:
Client CPD does not trigger the NDS captive portal if the CPD fails to resolve the ip address of its connectivity check URL.

NDS can be made to function in an offline situation by setting up the router DNS server to return an ip address, eg the gateway address, for ALL DNS requests rather than returning an error.

This is fine for a situation where the router never has an Internet feed, but of no use if the feed is only temporarily unavailable.

Proposed Solution:
NDS redirects all port 53 traffic from the local network to its own DNS handler at a different port, say 5353.

An NDS DNS handler then calls the router's actual DNS server on port 53. If it receives an ip address, it echoes this to the client. If it receives an error, ie the router is offline, then it sends its own gateway address to the client.

The client CPD will then access the ip address it receives on port 80 thus triggering the captive portal.

As NDS now knows that it is operating offline it can send an "Offline Status" splash page instead of the usual splash page.

This should be fairly simple to implement.

In addition, by using FAS and staying on the splash page without actually authenticating to NDS, this automated behavior can be used to provide offline information services, getting round the issue with the defacto standard CPD automatically closing the client CPD browser on authentication.

@mwarning

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Nov 19, 2018

Won't it be sufficient to return the gateways IP address if the router is meant to work offline?
This is already possible on OpenWrt by setting: uci add_list dhcp.@dnsmasq[0].address '/#/192.168.1.1' (we should include that into the NDS config on OpenWrt..)

EDIT: Meh, the line is wrong.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

As I said above:

NDS can be made to function in an offline situation by setting up the router DNS server to return an ip address, eg the gateway address, for ALL DNS requests rather than returning an error.

This is a config for offline use only of course and works very well.

However, what if the Internet feed fails on a normal online system? Well then the clients get either nothing or some sort of error.

What I am proposing here is a means of automating the process entirely within NDS. We could also implement a new status page to inform the client device user.

Also the "Status page" functionality could be used with FAS to provide an informational/educational local offline web service. Options available with such a service could dynamically change depending on the availability of the Internet feed.

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Nov 19, 2018

Ok, you want to have a dynamic detection. If there is not Internet => return Gateway IP, if there is Internet => return gateway IP if unauthenticated and real IP if authenticated.
Is that correct?

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

Not quite.

  1. If there is Internet => client CPD DNS query for connectivity check url gets real IP - everything as normal - splash page is triggered.
  2. Internet Down (or not even available) => client CPD DNS query for connectivity check url gets gateway address - splash page is triggered.

In case 2, if the CPD gets NACK or error from DNS server, it stops trying to connect and informs Networkmanager to try another SSID. Splash page is never shown.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

Once authenticated, the same applies.
Internet present - real ip address returned from DNS query
Internet not present - gateway address returned

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

http://gatewayaddress:80 could even be set up to display the same status page seen on first connecting or even the informational site I mentioned in the proposal. This would clash with LuCi on OpenWrt though - hence the reference to FAS.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

Once preauthenticated AND offline, if FAS is used and does not give the option to authenticate with NDS, then the CPD browser will stay open.

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Nov 19, 2018

We would need to implement a DNS proxy. I would prefer a more elegant solution with the same effect, if possible.

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Nov 19, 2018

Maybe there is a solution here: https://serverfault.com/questions/940769/dnsmasq-return-default-ip-address-if-address-cannot-be-resolved
Of course we could create a script that tests for Internet access and reconfigures the DNS server. But this would also not be very elegant.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Nov 19, 2018

We would not need a DNS proxy in the fullest sense, just something to pass through the actual DNS response if a request if successful, or gateway address if failed. This I think would be very elegant with no changes to the DNS server required. :-D
It looks like it would be simple to implement in C using sockets......

@bluewavenet

This comment has been minimized.

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Nov 19, 2018

@bluewavenet I think it is a very useful feature - either way how it is implemented.

@ikokang

This comment has been minimized.

Copy link

@ikokang ikokang commented Nov 20, 2018

@bluewavenet You have a very good idea. If the Internet cannot be accessed, relevant reminder information will be displayed. It also allows visitors to contact the administrator to deal with network problems in a timely manner.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Jan 4, 2019

I will get round to this ;-)

@martignoni

This comment has been minimized.

Copy link
Contributor

@martignoni martignoni commented Feb 21, 2019

@bluewavenet Indeed a very good idea for scenarios where Internet access is not desirable, for instance with an off-line MoodleBox, see moodlebox/moodlebox#120.

@martignoni

This comment has been minimized.

Copy link
Contributor

@martignoni martignoni commented Apr 15, 2019

Any news? I'd like to help here, but don't have capabilities do code this. How can I help (testing, eg.)?

@mwarning

This comment has been minimized.

Copy link
Member

@mwarning mwarning commented Apr 15, 2019

What is missing is documentation on how to set this up.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Apr 15, 2019

@martignoni @mwarning
I keep trying to make time to do this, then something else comes up.
To restate my original thoughts:

Proposed Solution:
NDS redirects all port 53 traffic from the local network to its own DNS handler at a different port, say 5353.

An NDS DNS handler then calls the router's actual DNS server on port 53. If it receives an ip address, it echoes this to the client. If it receives an error, ie the router is offline, then it sends its own gateway address to the client.

The client CPD will then access the ip address it receives on port 80 thus triggering the captive portal.

As NDS now knows that it is operating offline it can send an "Offline Status" splash page instead of the usual splash page.

NDS will need a DNS handler and this looks fairly easily do-able (link as indicated earlier):
http://www.firewall.cx/networking-topics/protocols/domain-name-system-dns/160-protocols-dns-query.html

Development would have to take an iterative approach at least to begin with, making documentation on how to do it a bit difficult at this stage, but I do feel confident that it can be done.

Any thoughts/ideas welcome!

@xtian777x

This comment has been minimized.

Copy link

@xtian777x xtian777x commented Jun 10, 2019

Any update on making nodogsplash work in offline mode?

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Jun 12, 2019

@xtian777x
It is on my (long) list of things to do....
You can manually configure permanent offline operation (described above).
eg on OpenWrt:
uci add_list dhcp.@dnsmasq[0].address='/#/192.168.1.1'
uci commit dhcp

@xtian777x

This comment has been minimized.

Copy link

@xtian777x xtian777x commented Jun 12, 2019

@xtian777x
It is on my (long) list of things to do....
You can manually configure permanent offline operation (described above).
eg on OpenWrt:
uci add_list dhcp.@dnsmasq[0].address '/#/192.168.1.1'

@bluewavenet Thanks. I manually edited the dnsmasq.conf file to have address = /#/the.rpi.ip.address
but when I do that, the devices connecting to the RPi access point can't get an IP address. Currently it just works with /local/the.rpi.ip.address

@SergioDG-YCC

This comment has been minimized.

Copy link

@SergioDG-YCC SergioDG-YCC commented Jun 18, 2019

I think I understand the need, I also have that dilemma. In my work, the Openwrt and Mikrotik routers that we use, in addition to providing 4G internet, in urban buses, are connected to a local server with different information for the passenger and VOD content, etc. The problem arises in the absence of 4G signal (without internet) there is no Hotspot. Although, they can connect to the wifi without going through the login / Splash, they must manually enter the browser and enter the internal address of the server, eg 'micro.tv'. But when they connect they see that they do not have internet, nothing informs them of the situation, and they believe that nothing works, if the server works, but they do not think so. I do not have how to tell them.
I have seen users of Mikrotik develop a Netwatch that, giving a ping to google knew if it had internet, if there was no answer redirects all the ip 0.0.0.0 to the gateway fooling the clients, to show a maintenance html. The problem that when returning the internet signal, it was not deactivated =D.

@ikokang

This comment has been minimized.

Copy link

@ikokang ikokang commented Jul 27, 2019

Is there any new progress on this good proposal so far?

@doxendine

This comment has been minimized.

Copy link

@doxendine doxendine commented Dec 17, 2019

I have a similar question.  I'm trying to setup a captive portal with only a Raspberry Pi. No internet & no router. The purpose is (in a no wifi situation) to have a custom portal page to allow users to connect via wifi to the page & download different files on the Raspberry Pi. Do you know if this is possible via NoDogSplash or other option?
Thanks for your help. 

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Dec 17, 2019

@doxendine
The short answer is "No" for downloads.
This is controlled purely by the client operating system (its CPD). Downloading from a captive portal could be a very severe security issue so is blocked by default by Android and iOS.

@doxendine

This comment has been minimized.

Copy link

@doxendine doxendine commented Dec 17, 2019

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Dec 17, 2019

@doxendine
moodlebox uses NDS.
You will have the same problem with any captive portal.
It might work with some devices, most likely laptops/desktops that don't have a proper CPD but even then it is not something you can rely on I'm afraid.

@doxendine

This comment has been minimized.

Copy link

@doxendine doxendine commented Dec 17, 2019

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Dec 17, 2019

@doxendine
I am trying to say that file downloads are specifically blocked on mainstream clients in the CPD.
There are no options that will work. If you were to find a security vulnerability to work around it, I am sure patches to fix the problem would very rapidly be released.

@doxendine

This comment has been minimized.

Copy link

@doxendine doxendine commented Dec 30, 2019

Thanks for your help. I think we will scrap the captive portal option & only use Moodlebox for downloading. I still would be nice to use NDS to direct users to Moodlebox, however we will not have internet & only seeing that you need internet for NDS to work.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Dec 30, 2019

@doxendine

you need internet for NDS to work

That is not strictly true.
You can manually configure permanent offline operation (described above).
eg on OpenWrt:

uci add_list dhcp.@dnsmasq[0].address '/#/192.168.1.1'
uci commit dhcp
@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Jan 18, 2020

Newer versions of client CPD seem to be checking for possible DNS rebind exploits.
Returning to 192.168.1.1 for all enquiries looks just like, or in fact is, a rebind exploit, so devices with a CPD doing this check will not connect.
The CPD is just looking for a positive return from its DNS enquiry, so any public address will do. eg:
uci add_list dhcp.@dnsmasq[0].address '/#/121.122.123.124'
uci commit dhcp

@frnhr

This comment has been minimized.

Copy link

@frnhr frnhr commented Jan 19, 2020

BTW (for any visitors from the future), on Debian / Raspbian, the way to configure permanently offline mode seems to be to add line:

address=/#/192.168.1.1

to /etc/dnsmasq.conf or to a (new) .conf file in /etc/dnsmasq.d/.

@bluewavenet

This comment has been minimized.

Copy link
Member Author

@bluewavenet bluewavenet commented Jan 19, 2020

@frnhr
Thanks!
I would suggest though, as in my previous comment, that a random public ip address is used, otherwise the client CPD might well refuse to display the NDS login page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.