opennds redirect me to localhost

[ghost]

Hello, I have set up OpenNDS on a Raspberry 4. I have no errors and allseems to work fine.

Only when I start with FAS I have an issue. When I connect my iPhone i get redirected to localhost/fas/fas.php not to the IP address I have set up in the config file.

This is my OpenNDS config :

config opennds option fasport '80' option faspath '/fas/fas.php' option fasremoteip '192.168.178.100' option faskey 'mysecret' option fas_secure_enabled '0' option gatewayinterface 'wlan0'

Some more info on the issue:

sudo journalctl -u opennds.service

Here is same issue, something wrong with url:

Jun 28 20:54:11 raspberrypi opennds[2202]: FAS Enabled. Jun 28 20:54:11 raspberrypi opennds[2202]: FAS URL is http://:80/fas/fas.php

For testing I have just set up a fas.php which echoes the text Succes!.

Any ideas?

[bluewavenet]

@shivaa4256 I assume you are using openNDS version 10.1.0, the current release.

I also assume your fas server is on another device (192.168.178.100) and the ip address of the openNDS router is something like 192.168.178.1.

FAS URL is http://:80/fas/fas.php

There is a known bug in 10.1.0, where option fasremotefqdn MUST also be set. You should add to the dnsmasq config, a hostname for your fas server, something like 'fas.lan'

eg, add the following line to /etc/dnsmasq.conf:

--address=/fas.lan/192.168.178.100/

Then restart dnsmasq.

[bluewavenet]

@shivaa4256 I forgot to say the line to add to /etc/config/opennds will be: option fasremotefqdn 'fas.lan'

Then restart opennds for it to take effect.

[ghost]

Thanks for the reply. I have done like you said but now I have internet access without any message. The captive portal doesnt show up anymore.

These are my configurations:

dnsmasq.conf

interface=wlan0 # Use interface wlan0
server=1.1.1.1 # Use Cloudflare DNS
dhcp-range=192.168.220.50,192.168.220.150,12h # IP range and lease time
dhcp-option-force=114,http://status.client address=/fas.lan/192.168.68.103/

hostapd.conf

interface=wlan0 driver=nl80211

hw_mode=g channel=6 ieee80211n=1 wmm_enabled=0 macaddr_acl=0 ignore_broadcast_ssid=0

auth_algs=1 wpa=2 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP

This is the name of the network

ssid=RasPi

The network passphrase

wpa_passphrase=mysecret

config opennds

option gatewayinterface 'wlan0'
option fasport '80'
option faspath '/fas/fas.php'
option fasremoteip '192.168.68.103'
option faskey 'secretpass'
option fas_secure_enabled '0'
option gatewayinterface 'wlan0'
option fasremotefqdn 'fas.lan'

[ghost]

EDIT

Now when i choose the wifi AP on my iPhone, its going to fas.lan/fas/fas.php but it doesnt show the page. It says server unreachable. Its seems fas.lan is not working in dnsmasq.

ping fas.lan
ping: fas.lan: Name or service not known

[ghost]

Its working now. I needed to change this in dnsmasq.conf:

# Force this option to clients (the splash page URL)
dhcp-option-force=114,http://192.168.68.103/fas/fas.php

[ghost]

I have a new issue. With default initial install of openNDS the captive portal popped up the moment i clicked on the wifi SSID on my phone. After I have set up FAS the popup does not show up when i click my SSID. Now I need to visite http://neverssl.com first. Any ideas about this issue?

[bluewavenet]

@shivaa4256

Any ideas about this issue?

Yes, you have misunderstood how opennds works and are misconfiguring it.

We should go back to "first principles" and review the requirements.

1. openNDS must be run on a router that has at least 2 network interfaces (in your case ethernet for Internet feed and wireless for client devices to attach to.
2. The openNDS local lan (the rpi wireless interface) must be configured such that the wlan0 has its own ip subnet ie is the default gateway for wlan0.
3. The wlan0 subnet must be different to that of your isp's router (the network the rpi's ethernet is connected to.
4. The rpi must be running dnsmasq to provide both dhcp and dns services to clients connected to wlan0.
5. openNDS has its own built in web server (MHD). This serves both splash pages and rfc 8910 status pages for non-FAS configurations, and just the status pages when a FAS is configured.
6. A FAS can be another web server running on the openNDS router, another web server running on another device on the local network, or a remote web server hosted somewhere on the Internet.

You have a remote FAS on a different ip subnet to that of the openNDS router. This is fine but the openNDS router MUST be configured to route packets to the FAS subnet.

The dhcp-option-force=114 setting is dynamic and it placed in the dnsmasq config by openNDS as it starts up, and removed again when openNDS is stopped. The setting is vital for proper operation of the RFC 8010 CPI and must not be changed.

First, I suggest you test if the FAS subnet is accessible by trying to ping the fas server by ip address. Then try pinging by fas.lan. Both should work if you have configured everything correctly.

[ghost]

Thanks but all things you mentioned, I already did. So where did I misconfigure??

@shivaa4256

Any ideas about this issue?

Yes, you have misunderstood how opennds works and are misconfiguring it.

We should go back to "first principles" and review the requirements.

1. openNDS must be run on a router that has at least 2 network interfaces (in your case ethernet for Internet feed and wireless for client devices to attach to.

YES, I have wlan0 and eth0

2. The openNDS local lan (the rpi wireless interface) must be configured such that the wlan0 has its own ip subnet ie is the default gateway for wlan0.

that is the case

3. The wlan0 subnet must be different to that of your isp's router (the network the rpi's ethernet is connected to.

that is the case

4. The rpi must be running dnsmasq to provide both dhcp and dns services to clients connected to wlan0.

that is the case

5. openNDS has its own built in web server (MHD). This serves both splash pages and rfc 8910 status pages for non-FAS configurations, and just the status pages when a FAS is configured.

that is the case

6. A FAS can be another web server running on the openNDS router, another web server running on another device on the local network, or a remote web server hosted somewhere on the Internet.

that is the case

You have a remote FAS on a different ip subnet to that of the openNDS router. This is fine but the openNDS router MUST be configured to route packets to the FAS subnet.

that is the case

The dhcp-option-force=114 setting is dynamic and it placed in the dnsmasq config by openNDS as it starts up, and removed again when openNDS is stopped. The setting is vital for proper operation of the RFC 8010 CPI and must not be changed.

ok

First, I suggest you test if the FAS subnet is accessible by trying to ping the fas server by ip address. Then try pinging by fas.lan. Both should work if you have configured everything correctly.

Right now all is working fine, the FAS does what it need to do. The only issue i am facing is that we have to go to neverssl.com to see the captive portal. As without the FAS the popup activates the moment you click on the SSID, so you dont need to go to neverssl.com first.

[bluewavenet]

@shivaa4256 You say all is working fine, yet:

we have to go to neverssl.com to see the captive portal

Then, clearly, it is not working fine.

For your information: https://opennds.readthedocs.io/en/stable/howitworks.html#captive-portal-detection-cpd

As a test, set in the config: option login_option_enabled '1'

This should return operation to the basic "click to continue mode after restarting opennds.

Test with the same client device that was not popping up the splash page.

However, you should logout on your test client as openNDS will pre-emptively re-authenticate any clients on a restart.

To logout, open a browser and go to http://status.client then click or tap "logout".

It is possible that the particular client has effectively "blacklisted" the portal due to previous failures (this can happen on both iOS and Android and is usually cleared by rebooting the phone.

[ghost]

Thanks, I tested like you said with the default continue mode, and also first logged out on the status page. But the splash page doesnt popup when clicking the SSID. I have to go to a http page.

[ghost]

It working now, I cleared all, rebooted all and now the page popups on choosing the SSID. Thanks for all the help and this fantastic tool.

[bluewavenet]

@shivaa4256 Excellent! Good luck with your project :-)

[bluewavenet]

@shivaa4256

A quick note about dhcp-option-force=114: This is not supposed to be the splash page. It is the RFC 8910 CPI (Captive Portal Information) page. It should be the same page as http://status.client and is there to inform clients that they are connected to a captive portal and where to get information about it - for clients that support it (It is a new standard and not many clients support it yet).

[ghost]

Hello, some last issues. I moved my FAS page to the same device (rasp 4) as where OpenNDS is installed. So now all is on 1 device. I try to reconfigure my conf files but I can get the splash page working anymore. When the splash page is hosted on a different device it still works fine, but not with the new setup.

These are my conf files

opennds:

option gatewayinterface 'wlan0'
option fasport '80'
option faspath '/fas/fas.php'
option fasremoteip '192.168.68.120'
option faskey 'mysecret'
option fas_secure_enabled '0'
option fasremotefqdn 'fas.local'
##to activate the default click to continue mode:
#option login_option_enabled '1'

dnsmasq:

The FAS server

address=/fas.lan/192.168.68.120

dhcp-option-force=114,http://status.client

ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.68.120 netmask 255.255.255.0 broadcast 192.168.68.255 inet6 fe80::ec77:58b:5f0c:78f6 prefixlen 64 scopeid 0x20 ether dc:a6:32:45:3a:cf txqueuelen 1000 (Ethernet) RX packets 5389 bytes 714536 (697.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8352 bytes 8416856 (8.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 823 bytes 70683 (69.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 823 bytes 70683 (69.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.1 netmask 255.255.255.0 broadcast 192.168.220.255 inet6 fe80::77be:eb16:56b4:7f27 prefixlen 64 scopeid 0x20 ether dc:a6:32:45:3a:d0 txqueuelen 1000 (Ethernet) RX packets 162 bytes 20186 (19.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 199 bytes 88260 (86.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.68.118 netmask 255.255.255.0 broadcast 192.168.68.255 inet6 fe80::d68:365f:6602:7d43 prefixlen 64 scopeid 0x20 ether 06:da:35:e0:aa:39 txqueuelen 1000 (Ethernet) RX packets 2434 bytes 616764 (602.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 103 bytes 14765 (14.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[bluewavenet]

see #477