Closed chGoodchild closed 1 month ago
Based on the information you've provided, it appears that OpenNDS is detecting your client and attempting to redirect to the captive portal, but the client is unable to load the portal page. Let's address this step by step:
Firewall Configuration: Your firewall configuration looks generally correct. The OpenNDS include is present, which is good.
OpenVPN is inactive, so it's not interfering.
The client is detected by OpenNDS and is in a "Preauthenticated" state.
The redirect to the captive portal is happening, but the client can't load the page.
Here are some steps to troubleshoot and resolve the issue:
Ensure HTTP access is allowed: Add this rule to your firewall configuration:
config rule
option name 'Allow-OpenNDS-Portal'
option src 'lan'
option proto 'tcp'
option dest_port '2050'
option target 'ACCEPT'
Then restart the firewall:
service firewall restart
Check OpenNDS configuration:
Ensure your OpenNDS configuration in /etc/config/opennds
includes these settings:
config opennds
option enabled '1'
option gatewayinterface 'br-lan'
option gatewayname 'OpenNDS Captive Portal'
option maxclients '250'
option authidletimeout '120'
option debuglevel '3'
list authenticated_users 'allow all'
list users_to_router 'allow tcp port 22'
list users_to_router 'allow tcp port 53'
list users_to_router 'allow udp port 53'
list users_to_router 'allow udp port 67'
list users_to_router 'allow tcp port 80'
list users_to_router 'allow tcp port 443'
Restart OpenNDS:
service opennds restart
Clear DNS cache on the client device: The "status.client" domain might be cached. Clear your browser cache and DNS cache on your device.
Try accessing the portal directly:
On your client device, try to access http://192.168.8.1:2050/opennds_preauth/
directly in a browser.
Disable HTTPS redirection: If you've previously set up HTTPS redirection for LuCI, it might interfere with the captive portal. Temporarily disable any HTTPS redirection.
Check for any blocking rules: Ensure there are no firewall rules blocking access to port 2050 or HTTP traffic on the LAN.
Verify DNS resolution: On your OpenWrt router, try:
nslookup status.client
It should resolve to 192.168.8.1
Add a hosts entry:
If DNS resolution fails, add this to /etc/hosts
on your OpenWrt router:
192.168.8.1 status.client
Check OpenNDS logs: After making these changes, try to connect again and check the logs:
logread | grep opennds
Verify iptables rules: After restarting OpenNDS, check if it has added its rules:
iptables -L -n -v | grep 2050
Try a different browser or device: Sometimes, certain browsers or devices handle captive portals differently.
Temporarily disable IPv6: If you're still having issues, try temporarily disabling IPv6 on your LAN interface to rule out any IPv6-related problems.
If after trying these steps you're still unable to access the captive portal, please provide:
cat /etc/config/opennds
)iptables -L -n -v
after restarting OpenNDSThis will help in further diagnosing the issue.
Based on the information you've provided, there are several issues that need to be addressed:
DHCP Issue: The DHCP configuration looks correct, but there's still an issue with IP allocation. The "IP not allocated by dhcp" messages in the logs are concerning.
Disk Space: You mentioned earlier that the root filesystem was 100% full. This can cause various issues, including preventing services from writing logs or temporary files.
iptables Segmentation Fault: This is a critical issue. iptables is essential for the firewall and NAT functionality, which openNDS relies on heavily. The segmentation fault suggests a serious system problem.
openNDS Process: openNDS appears to be running, but it might not be functioning correctly due to the iptables issue.
Here are some steps to troubleshoot and potentially resolve these issues:
Address the Disk Space Issue:
df -h
If the root filesystem is still full, try to free up some space:
opkg clean
rm -rf /tmp/*
Check System Logs:
logread | tail -n 100
Look for any error messages related to iptables or other system issues.
Reinstall iptables:
opkg update
opkg remove iptables
opkg install iptables
Check iptables Version:
iptables --version
Verify Network Interface:
ifconfig br-lan
Ensure the interface is up and has the correct IP address.
Check openNDS Configuration: Review the openNDS configuration file again, especially the GatewayInterface setting:
cat /etc/config/opennds
Ensure it's set to the correct interface (usually br-lan).
Restart Network and openNDS:
/etc/init.d/network restart
/etc/init.d/opennds restart
Check openNDS Logs:
logread | grep opennds
Verify Firewall Rules: Since iptables is not working, check if nftables is being used:
nft list ruleset
Check if the Captive Portal is Listening:
netstat -tuln | grep 2050
This should show that openNDS is listening on port 2050.
Test Basic Connectivity: From a client device, try to ping the router's IP address and an external IP (like 8.8.8.8).
Check DNS Resolution: From a client device, try to resolve a domain name:
nslookup example.com
The iptables segmentation fault is the most critical issue here. It suggests there might be a more fundamental problem with your system, possibly related to the kernel or the iptables package itself. Resolving this issue is likely to be key in getting the captive portal to work correctly.
If these steps don't resolve the issue, you might need to consider:
Before:
root@GL-AR300M:/tmp# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.3M 12.3M 0 100% /rom
tmpfs 59.2M 392.0K 58.8M 1% /tmp
/dev/mtdblock5 896.0K 568.0K 328.0K 63% /overlay
overlayfs:/overlay 896.0K 568.0K 328.0K 63% /
tmpfs 512.0K 0 512.0K 0% /dev
opkg update
opkg install dnsmasq-full opennds
After:
root@GL-AR300M:/tmp# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.3M 12.3M 0 100% /rom
tmpfs 59.2M 1.8M 57.4M 3% /tmp
/dev/mtdblock5 896.0K 824.0K 72.0K 92% /overlay
overlayfs:/overlay 896.0K 824.0K 72.0K 92% /
tmpfs 512.0K 0 512.0K 0% /dev
As you can see above, installing opennds led to an increase in the size of the `/overlay` partition, but it didn't add anything to the /rom partition which was already full.
Is this to be expected? Could it be part of the cause of the problems I'm facing?
Yes, this behavior is expected, and it's indeed related to the issues you're facing. Let me explain:
Read-Only Root (/rom):
The /dev/root
or /rom
partition is typically a read-only filesystem containing the base system image. It's 100% full by design, and you can't write to it during normal operation.
Overlay Filesystem (/overlay):
OpenWrt uses an overlay filesystem. When you install packages or make changes, they are written to the /overlay
partition. The system then "overlays" these changes on top of the read-only base system, giving the illusion of a unified, writable filesystem.
Limited Space:
Your /overlay
partition is very small (only 896KB), and it's now 92% full. This limited space can cause several issues:
Impact on OpenNDS and iptables: The limited space could be contributing to the issues you're experiencing with OpenNDS and iptables. There might not be enough space for these services to write necessary temporary files or for the system to load all required modules.
To address these issues:
Free up space:
opkg clean
rm -rf /tmp/opkg-lists
Remove unnecessary packages: Identify large or unused packages and remove them.
Consider expanding storage: If possible, consider expanding the overlay partition or adding external storage.
Minimal installation: Try a minimal installation of OpenNDS and only add features as needed.
Check for alternatives: Look for lightweight alternatives to some of your installed packages.
Factory reset: As a last resort, you might consider a factory reset, but be sure to backup your configuration first.
Hardware limitations: Be aware that your device (GL-AR300M) has limited flash storage, which can constrain your ability to install and run certain packages.
The root cause of your issues is likely the very limited storage space. This can lead to incomplete package installations, inability to write necessary files, and system instability. Addressing the storage issue should be your primary focus in resolving the problems with OpenNDS and iptables.
Filesystem before sysupgrade (GL Firmware):
root@GL-AR300M:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.3M 12.3M 0 100% /rom
tmpfs 59.2M 296.0K 58.9M 0% /tmp
tmpfs 59.2M 304.0K 58.9M 1% /tmp/root
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mtdblock5 896.0K 296.0K 600.0K 33% /overlay
overlayfs:/overlay 896.0K 296.0K 600.0K 33% /
Filesystem after sysupgrade (plain openwrt):
~ # df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 12.0M 12.0M 0 100% /rom
tmpfs 59.3M 100.0K 59.2M 0% /tmp
tmpfs 59.3M 124.0K 59.1M 0% /tmp/root
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mtdblock5 1.3M 244.0K 1.0M 19% /overlay
overlayfs:/overlay 1.3M 244.0K 1.0M 19% /
Based on the information you've provided, it seems that the OpenNDS captive portal is running correctly, but the automatic redirection isn't working as expected. Here are some steps to troubleshoot and ensure automatic redirection:
Check OpenNDS configuration: On the OpenWRT router, examine the OpenNDS configuration:
cat /etc/config/opennds
Look for these important settings:
option enabled '1'
(make sure OpenNDS is enabled)option gatewayname 'OpenNDS'
option gatewayinterface 'br-lan'
(or whatever your LAN interface is)option redirecturl 'http://status.client'
Verify firewall rules: Ensure that the necessary firewall rules are in place:
iptables -t nat -L
Look for rules related to OpenNDS, particularly in the PREROUTING chain.
Check DNS settings: Your router's DHCP configuration looks good, with the option:
list dhcp_option_force '114,http://status.client'
This should help with redirection.
Flush DNS cache on your laptop:
sudo systemd-resolve --flush-caches
Restart OpenNDS: On the OpenWRT router:
/etc/init.d/opennds restart
Check OpenNDS status:
/etc/init.d/opennds status
Verify that OpenNDS is listening on all interfaces: In the OpenNDS config, ensure you have:
option gatewayinterface '*'
This will make OpenNDS listen on all interfaces.
Check client isolation: Ensure that client isolation is disabled on your Wi-Fi network if you're connecting wirelessly.
Try a different browser or device: Sometimes, certain browsers can cache previous successful connections and bypass the captive portal.
Manually trigger a captive portal check: On your laptop, try accessing a specific URL that should trigger captive portal detection:
curl http://captive.apple.com
This should redirect you to the captive portal if everything is set up correctly.
Check for any VPN or custom DNS settings on your laptop that might be interfering with the redirection.
Ensure that your laptop is actually getting an IP from the DHCP server on the router and not using a static IP.
If after trying these steps you're still not getting automatically redirected, we might need to dive deeper into the OpenNDS and OpenWRT configurations. Let me know the results of these steps, and we can proceed from there.
# GatewayFQDN
# Default: status.client
# This is the simulated FQDN used by a client to access the Client Status Page
# If not set, the Status page can be accessed at: http://gatewayaddress:gatewayport/
#
# Warning - services on port 80 of the gateway will no longer be accessible (eg Luci AdminUI)
#
# By default, the Error511/Status page will be found at http://status.client/ by a redirection
# of port 80 to http://gatewayaddress:gatewayport/
#
# Disable GatewayFQDN by setting the option to 'disable'
# ie:
#option gatewayfqdn 'disable'
#
# Alternate Useful Example:
#option gatewayfqdn 'login.page'
# Set Fasport
# This is the Forwarding Authentication Service (FAS) port number
# Redirection is changed to the IP port of a FAS (provided by the system administrator)
# Note: if FAS is running locally (ie fasremoteip is NOT set), port 80 cannot be used.
#
# Typical Remote Shared Hosting Example:
#option fasport '80'
#
# Typical Locally Hosted example (ie fasremoteip not set):
#option fasport '2080'
###########################################################################################
# Option: fasremotefqdn
# Default: Not set
# If set, this is the remote fully qualified domain name (FQDN) of the FAS.
# The protocol must NOT be prepended to the FQDN (ie http:// or https://)
# To prevent CPD or browser security errors NDS prepends the required http:// or https://
# before redirection, depending upon the fas_secure_enabled option.
#
# If set, DNS MUST resolve fasremotefqdn to be the same ip address as fasremoteip.
#
# Typical Remote Shared Hosting Example (replace this with your own FAS FQDN):
#option fasremotefqdn 'onboard-wifi.net'
#
# Note: For a CDN (Content Delivery Network) hosted server,
# you must also add fasremotefqdn to the Walled Garden list of FQDNs
#
# Typical Remote Shared Hosting Example (replace this with your own remote FQDN):
#option fasremotefqdn 'portal.mydomain.com'
# Option: fas_secure_enabled
# Default: 1
# ****If set to "0"****
##
# WARNING This mode is insecure and is not recommended.
##
# The FAS is enforced by NDS to use http protocol.
# The client token is sent to the FAS in clear text in the query string of the redirect along with authaction and redir.
# Note: This level is insecure and can be easily bypassed
Should I be modifying the above? When does it make sense to modify these things?
You're correct in your assessment. For Bitcoin payments, you need direct access to the original payment string provided by the user. Based on the description of the FAS security levels, here's what we can conclude:
FAS Level 0: This would allow you to receive the original string, but it's highly insecure and not recommended for handling payments.
FAS Level 1: This level hashes the token, which means you wouldn't have access to the original string.
FAS Level 2: This level encrypts several parameters, including the hashed token (hid), but not the user input directly.
Given these options, you have a few potential approaches:
Use FAS Level 0: This is not recommended due to security concerns, especially for handling payments.
Use FAS Level 2 with a custom parameter: You can modify the OpenNDS code to include an additional encrypted parameter in the query string that contains the Bitcoin payment string. This would require changes to the OpenNDS source code.
Use FAS Level 2 with a two-step process: a. In the first step, collect the Bitcoin payment string and store it temporarily (e.g., in a session or a temporary file) along with a unique identifier. b. Pass this unique identifier through the encrypted parameters to your FAS script. c. In the FAS script, use this identifier to retrieve the original Bitcoin payment string.
Use a hybrid approach: a. Use FAS Level 2 for the initial redirect and authentication. b. Once the user reaches your FAS script, present another form where they can enter the Bitcoin payment string. c. Process the payment in your FAS script and then complete the authentication process.
Recommendation: The hybrid approach (option 4) is likely the most secure and easiest to implement without modifying OpenNDS itself. Here's how you could structure it:
Set up FAS Level 2 in your OpenNDS configuration:
option fas_secure_enabled '2'
Create your FAS script (e.g., bitcoin_fas.php
) that does the following:
a. Decrypt the parameters passed by OpenNDS.
b. Present a form to the user asking for the Bitcoin payment string.
c. When the form is submitted, verify the Bitcoin payment.
d. If the payment is valid, complete the authentication process by returning the required hash to OpenNDS.
This approach maintains the security benefits of FAS Level 2 while allowing you to collect and process the Bitcoin payment string securely.
Remember to implement proper error handling, input validation, and security measures in your FAS script to protect against potential attacks or misuse.
Plan: Use level 0 for proof of concept, then upgrade to level 2...
You're absolutely right. The error message indicates that there isn't enough space on the router's filesystem to install php8-cgi. This lack of PHP support could indeed be why your curl request is failing.
Your suggestion about using sysupgrade.bin files to include more packages is an excellent approach. Here's how you can proceed:
Rebuild OpenWrt Image: When building your custom OpenWrt image, include the following packages:
Generate sysupgrade.bin: Use the OpenWrt build system to generate a new sysupgrade.bin file with these packages included.
Flash the New Image: Use the new sysupgrade.bin to update your router. This will give you a fresh system with the necessary packages pre-installed.
Alternative for Testing: If you want to test without rebuilding immediately, you can try using a lighter PHP version or a different lightweight web server:
Try lighttpd instead of uhttpd + PHP:
opkg update
opkg install lighttpd
Or, use a simple Python-based HTTP server (if Python is available):
opkg update
opkg install python3-light
python3 -m http.server 2080
Temporary Workaround: You can also create a simple shell script that mimics the basic functionality of your PHP script for testing purposes.
Here's a basic shell script version of your FAS (/www/bitcoin_fas.sh
):
#!/bin/sh
echo "Content-type: text/html"
echo ""
cat << EOF
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bitcoin Payment</title>
</head>
<body>
<h1>Bitcoin Payment Portal</h1>
<form method="GET" action="/cgi-bin/bitcoin_auth.cgi">
<label for="bitcoin_payment">Enter Bitcoin Payment String:</label><br>
<input type="text" id="bitcoin_payment" name="bitcoin_payment" required><br>
<input type="submit" value="Submit Payment">
</form>
</body>
</html>
EOF
And a simple CGI script to handle the "authentication" (/www/cgi-bin/bitcoin_auth.cgi
):
#!/bin/sh
echo "Content-type: text/html"
echo ""
# Parse query string
eval $(echo "$QUERY_STRING" | sed 's/&/;/g;s/\([^=]*\)=\([^;]*\)/\1="\2"/')
if [ -n "$bitcoin_payment" ]; then
echo "Payment accepted. Redirecting..."
echo "<meta http-equiv=\"refresh\" content=\"2;url=http://$gatewayname:2050/opennds_auth/?tok=$tok&redir=$redir\">"
else
echo "Invalid payment. Please try again."
fi
Make both scripts executable:
chmod +x /www/bitcoin_fas.sh /www/cgi-bin/bitcoin_auth.cgi
Update your OpenNDS configuration to use the shell script:
option faspath '/bitcoin_fas.sh'
This basic shell script approach doesn't require PHP and should work with uhttpd's built-in CGI support.
Remember, this is just for testing. For a production environment, you should definitely use the sysupgrade approach to include proper PHP support and implement secure, robust payment processing.
You're right to notice the inconsistency between ports 2080 and 2050. This could indeed be part of the problem. Let's clarify and correct this:
Port Configuration:
Check OpenNDS Configuration:
In your /etc/config/opennds
file, ensure you have the correct fasport
setting:
option fasport '2080'
Firewall Rule:
Make sure you have a firewall rule allowing incoming connections on port 2080. Add this to /etc/config/firewall
:
config rule
option name 'Allow-OpenNDS-FAS'
option src 'lan'
option proto 'tcp'
option dest_port '2080'
option target 'ACCEPT'
Then restart the firewall:
/etc/init.d/firewall restart
Verify OpenNDS is Running:
/etc/init.d/opennds status
Check if Something is Listening on Port 2080: On the OpenWrt router, run:
netstat -tuln | grep 2080
You should see a line indicating that port 2080 is being listened to.
Check OpenNDS Logs:
logread | grep opennds
Look for any error messages related to starting the FAS service.
Ensure uhttpd is Configured Correctly:
Check /etc/config/uhttpd
and ensure there's a section for the FAS:
config uhttpd 'fas'
option listen_http '0.0.0.0:2080'
option home '/www'
option index_page 'bitcoin_fas.sh'
Restart Services:
/etc/init.d/uhttpd restart
/etc/init.d/opennds restart
Test Locally: On the OpenWrt router itself, try:
wget -O - http://localhost:2080/bitcoin_fas.sh
This should return the content of your script if everything is set up correctly.
Path Issue:
Your curl command is trying to access /etc/opennds/bitcoin_fas.sh
, but if you're using uhttpd, the script should be in /www/
. Make sure the script is in the correct location.
Try a Different Port: If 2080 is causing issues, try changing to a different port (e.g., 2090) in both the OpenNDS configuration and the firewall rule.
After making these changes, try your curl command again, but update the path:
curl "http://192.168.8.1:2080/bitcoin_fas.sh?authaction=http://192.168.8.1:2050/opennds_auth/?clientip=192.168.8.152&gatewayname=TollGate%20Node%3a9483c423e42d%20&tok=1b824f53&redir=http%3a%2f%2fdetectportal.firefox.com%2fcanonical.html"
If it still doesn't work, please provide:
/etc/config/opennds
netstat -tuln | grep 2080
This information will help pinpoint the exact issue.
Based on the information you've provided, it seems that the issue is indeed related to firewall rules and network routing. The fact that the VPS is accessible from the router but not from the client devices suggests that there might be a problem with NAT (Network Address Translation) or forwarding rules. Let's address this step by step:
Firewall Configuration:
Your iptables -L -n -v
output shows empty chains, which is unusual. We need to set up proper firewall rules. Add the following rules:
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 80 -j DNAT --to-destination 192.168.8.1:2050
iptables -t nat -A POSTROUTING -o br-lan -j MASQUERADE
iptables -A FORWARD -i br-lan -o br-lan -j ACCEPT
These rules will redirect HTTP traffic to OpenNDS and allow forwarding between LAN interfaces.
OpenNDS Configuration:
Ensure your /etc/config/opennds
file includes:
option enabled '1'
option gatewayname 'TollGate Node'
option gatewayinterface 'br-lan'
option fasport '80'
option faspath '/cgi-bin/bitcoin-fas.cgi'
option fasremoteip '37.27.205.50'
option fas_secure_enabled '1'
option debuglevel '3'
DNS Resolution:
Add an entry to /etc/hosts
on the router:
37.27.205.50 helsinki.orangesync.tech
Network Configuration:
Make sure your /etc/config/network
file has proper configuration for the br-lan
interface:
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.8.1'
option netmask '255.255.255.0'
DHCP Configuration:
Ensure your DHCP server is configured correctly in /etc/config/dhcp
:
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
Restart Services: After making these changes, restart the following services:
/etc/init.d/network restart
/etc/init.d/dnsmasq restart
/etc/init.d/firewall restart
/etc/init.d/opennds restart
Debug OpenNDS: Increase the debug level in OpenNDS config and check the logs:
logread | grep opennds
Check Client Connectivity: On a client device, try the following:
ping 192.168.8.1
ping helsinki.orangesync.tech
curl -v http://helsinki.orangesync.tech/cgi-bin/bitcoin-fas.cgi
VPS Apache Configuration: Ensure your VPS Apache server is configured to handle CGI scripts and that the scripts have the correct permissions.
CGI Script Debugging: On your VPS, check Apache error logs:
tail -f /var/log/apache2/error.log
Also, try running the CGI script directly:
/usr/lib/cgi-bin/bitcoin-fas.cgi
If after implementing these steps you're still having issues, please provide:
/etc/config/opennds
fileiptables -t nat -L -n -v
from your routerThis additional information will help in further diagnosing the problem.
I'm setting up opennds with FAS running on a VPS to authenticate internet access.
I have a simple FAS script running behind: http://helsinki.orangesync.tech/cgi-bin/bitcoin-fas.cgi?fas=aGlkPWFmZDg2MWRiZjRlMGM0NGRhODM0MjgyYzY4NzQ0ODFiNzllZWM5OTdlYWVjNzU3MDE3YzUxZGU4M2JhN2Y2MjYsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFdGbVpEZzJNV1JpWmpSbE1HTTBOR1JoT0RNME1qZ3lZelk0TnpRME9ERmlOemxsWldNNU9UZGxZV1ZqTnpVM01ERTNZelV4WkdVNE0ySmhOMlkyTWpZc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd1RtOWtaU1V6WVRrME9ETmpOREl6WlRReVpDVXlNQ3dnWjJGMFpYZGhlWFZ5YkQxb2RIUndKVE5oSlRKbUpUSm1jM1JoZEhWekxtTnNhV1Z1ZEN3Z2RtVnljMmx2YmoweE1DNHpMakFzSUdkaGRHVjNZWGxoWkdSeVpYTnpQVEU1TWk0eE5qZ3VPQzR4T2pJd05UQXNJR2RoZEdWM1lYbHRZV005T1RRNE0yTTBNak5sTkRKa0xDQnZjbWxuYVc1MWNtdzlhSFIwY0NVellTVXlaaVV5Wm1obGJITnBibXRwTG05eVlXNW5aWE41Ym1NdWRHVmphQ1V5Wm1ObmFTMWlhVzRsTW1aaWFYUmpiMmx1TFdaaGN5NWpaMmtsTTJabVlYTWxNMlJoUjJ4clVGZEdiVnBFWnpKTlYxSnBXbXBTYkUxSFRUQk9SMUpvVDBSTk1FMXFaM2xaZWxrMFRucFJNRTlFUm1sT2VteHNXbGROTlU5VVpHeFpWMVpxVG5wVk0wMUVSVE5aZWxWNFdrZFZORTB5U21oT01sa3lUV3BaYzBsSFRuTmhWMVoxWkVkc2QxQlVSVFZOYVRSNFRtcG5kVTlETkhoT1ZFbHpTVWRPYzJGWFZuVmtSekZvV1hvd2VVOUVjR3ROYW04d1RrUnZNazVFY0cxTlZIQnRUbmwzWjFreWVIQmFWelV3V0ROU05XTkhWVGxaTTBKd1dETldlV0pEZDJkWk0wSndXRE5HTVZwWVNqVlFWMmd3WkVoQmJFMHlSV3hOYlZsc1RXMWFlbVJIUmpCa1dFMTFXVEo0Y0ZwWE5UQktWRXB0WWtjNWJtRlhOSE5KUjJSb1pFZFdNMWxZYkhWWlZ6RnNVRlpTZG1KSGVFaFpXRkpzU2xSSmQxUnRPV3RhVTFWNldWUnJNRTlFVG1wT1JFbDZXbFJSZVZwRFZYbE5RM2RuV2pKR01GcFlaR2hsV0ZaNVlrUXhiMlJJVW5kS1ZFNW9TbFJLYlVwVVNtMWpNMUpvWkVoV2VreHRUbk5oVjFaMVpFTjNaMlJ0Vm5sak1teDJZbW93ZUUxRE5IcE1ha0Z6U1Vka2FHUkhWak5aV0d4b1drZFNlVnBZVG5wUVZFVTFUV2swZUU1cVozVlBRelI0VDJwSmQwNVVRWE5KUjJSb1pFZFdNMWxZYkhSWlYwMDVUMVJSTkUweVRUQk5hazVzVGtSS2EweERRblpqYld4dVlWYzFNV050ZHpsaFNGSXdZME5WZWxsVFZYbGFhVlY1V20xb2JHSklUbkJpYlhSd1RHMDVlVmxYTlc1YVdFNDFZbTFOZFdSSFZtcGhRMVY1V20xT2JtRlRNV2xoVnpSc1RXMWFhV0ZZVW1waU1teDFURmRhYUdONU5XcGFNbXRzVFRKYWJWbFlUV3hOTWxKb1VqSjRjbFZHWkVkaVZuQkZXbnBLVGxZeFNuQlhiWEJUWWtVeFNGUlVRazlTTVVwdlZEQlNUazFGTVhGYU0yeGFaV3hyTUZSdWNGSk5SVGxGVW0xc1QyVnRlSE5YYkdST1RsVTVWVnBIZUZwV01WcHhWRzV3Vmswd01VVlNWRTVhWld4V05GZHJaRlpPUlRCNVUyMW9UMDFzYTNsVVYzQmFZekJzU0ZSdVRtaFdNVm94V2tWa2MyUXhRbFZTVkZaT1lWUlNORlJ0Y0c1a1ZUbEVUa2hvVDFaRmJIcFRWV1JQWXpKR1dGWnVWbXRTZWtadlYxaHZkMlZWT1VWalIzUk9ZVzA0ZDFSclVuWk5helZGWTBjeFRsWklRblJVYm13eldqRnJlV1ZJUW1GV2VsVjNWMFJPVTA1WFRraFdWR3hhVFRCS2QxZEVUbGRsVjBwRVpESmtXazB3U25kWFJFNUhUVlp3V1ZOcVZsRldNbWQzV2tWb1FtSkZNSGxTVjNoT1lsWnNjMVJYTVdGbGJWSklVbXBDYTFkRk1URlhWRW8wWTBad1dFNVVRa3RXUlhCMFdXdGpOV0p0UmxoT1NFNUtVakpTYjFwRlpGZE5NV3haWWtoV1dsWjZSbk5WUmxwVFpHMUtTR1ZGYUZwWFJrcHpVMnhTU21ReFVuUlBWM1JoVlRGV05sZFdVbkpOUlRsRlZHMXdUMUpGYkRaWGJGSlNaVlp3UkZaWWJFNVJNMlJ1VjJwS1IwMUdjRmxhUjJoc1YwWmFOVmxyVVhoaU1sSkpWVzVrUzFaRk5XOVRiRkpMWWxWd1ZWTnRNV3BOTVVwdldrVm9WMlZyZUhSVWJrNW9WakZhTVZwRlRqTmFNbEowVm01c2FrMXRlREpaYlc5M1pVVXhSRTVJY0UxaGEwWjZVMVZrYTJGSFVraFdhazVhVjBkNGIxZHJaRk5sVm5CWlZHNXdVVlpGVlRGVVYyc3daVVUxY1ZvelZsQlJlbEkwVkRKd1NtUXdOVlZSV0U1S1VqSlNiMXBGWkZkTk1XeFpZa2hTV2xZd01EVlVNVkpTVGtVd2VWUlVRazVoYXpWelZHdFNTMkV3ZUVSUmJscHFZbGQ0ZFZsV1l6Rk5WMDUwWkhwc2FGTkdTWGRaTUU1V1pXeHNWRlpZYkdGaFZsWTFWMjB4YjJKSFNrbFVia0pwWWxoU2QxUkhNRFZsVm14WVRsYzFZVmRGTkRGWmJURk9aRmRTU0ZadGNHaFJNVlkxVjIweFQySnRSbFJOVjJ4b1ZucFNjMVJYTVdGaFYwWlpWVzF3YVUxdGVERlVSbVJoWVVkT05VNVhjR0ZOYlhSelZGUktZV0pXYkZsVVYzaE9UV3hLYjFWcVNqUmpiRlpIV2tWa2FWWnVRa1pYYm5CTFZHeFplRk51UWxoaVdFSlVXV3RWZUZOR1VsVlJhemxUVFZWd2RsWkVRbE5VYXpGR1RWaEdZVTB5ZUdGYVYzaHlUVVpTZFdOR1NrNVNWR3hHVlcweGMxUXlWblJsU0U1WVlrZFNUMVJzVlRWV1ZuQklaVVp3VjAxV2NIaFdSelYzVm1zd2QwMVZWbE5XUlRWaFdsZDRWMDVHWkhKYVJscFBVbFJDTlZVeU1XOVVNREZ6WVROc1ZWWXpRbUZaZWtKelUwWlNkVlJ0YUZkTlZtOTRWMnRXYTJNeVVYaFJiRlpUVmtaYVQxbFdVbE5PUmxKMFkwYzFhMVpVYkVWVWEyaHZWREZhUm1KSWNGUldWMUpRV1hwS1IxZEdXblZXYlhSVFpXdGFkbFl4YUhaa01sWldUMVZXYWxJelVrOVpWekEwWkRGU2NsVnVXazVoZWxaR1dUQmplRlJzV2tsUmJsSlZZbTEzZWxkcVJuSmxWMVpKVVcxR1YyVnNWak5XTUZKUFZUQTFXRlJyYUZkV1IzaGhWRlJDUzJReFpFVlViR1JzVmpCd1JWcEVTbXRYYXpCM1UyNWtXRkpGTlVoVVZscDNWMVpPY1Zac1JsZE5iV1F6VjJ0V2IxRnRTa1pOU0d4VFZqTm9UMWxzV25Oak1WSllUVmRHYkdKV1NrbFZiWEJEWVRGa1JrMVVSbGhXUlc4d1dUQmFkMWRGTlZWUmEzUlhVbGhDTUZkWGRHcE9WMHAwVW14b1QxTkZOVXRWYWtwVFlqRndSbHBHWkU1TlYzaGFXV3RvVjFkc1dqWlNiazVXVW14d1ZGcEhNVXRUUjFaR1lVWndXRkpyY0hwVk1uaFRVMjFSZUZWdVVsQldNMUpvVmxSR1YwNXNaRmRWYmtwT1VsUnNSbFpITVhkVU1VcEdZa1JhV0dKR1NsTmFWbHAzVWtaYVdXSkZOVkpOTWxKMVZqSndTMUl3TVVkalJteGhVakpvYzFZd1dtRk9WbXh5VlZob2FVMXNTa3BXVnpWclV6RmFSazVYT1ZSaVJrcE1XV3hXZDFaV1RuUk5WM0JPVFZWd2RsZHJWbTlXTWxaeVpVaFNWV0pyTlc5V2FrWmhUVlp3UmxScVRtRk5iRW93Vm0wMWMyRnJNWFJsUkVwYVlsYzVNMXBWVlhoU1JUVkpZMFV4YUdFd1dqWlZNVlpyWVRKR1NGVnJhRmRoYXpWaFZqQmtOR0l4WkhKYVJrNXNWbTVDV2xaSE5YZFZWbHBHVmxSR1ZWWXljM2RhVlZVeFkxWnZlbFpzUWxKbGJFa3dWa1JLZDFOdFVYZE9WbFpTVjBVMVMxVnFTbE5pTVhCR1drWmtUazFYZUZwWmEyaFRWMnhaZDAxRVZsVk5Wa3BUVkd0VmQyVldVbFZSYXpWb1lYcFdlbFpIZEZOVE1rVjNaVVZTVW1Kc2NIRlpiR1EwWkZac1YxbDZSazVXTURVd1draHdjMkZHVGtkVFdHUmFUVVUxVjFwWGVITldSbHBaWWtkR2FGWnNXVEZXTWpCNFlqSktTRk5yYkZWaWEwcHdXV3hvVTJReFVraE5SRlpzVm0xNFdWUnNZekZaVm1SR1RrUkdXbUpVUms5YVJtUlRVMFphZEdOSGFGSk5WbGt4VmpJd2VGUXlTblJTYkZKT1ZqSjRiMVp1Y0ZOak1WSllUVmRHYUZZd1dscFdWekYzWVZVeGRHVkVSbFZTYlZKb1dWVmtUMDVWTlZoalIwWk9ZbGhTZWxaR1VrdFpWMHBYWWtac1ZWWXphRTlVVjNoTFlqRldjVk5xVW1waVJscElWMnRXYTJGV1duVlJhMXBZWW01Q1RGWkhlRnBsUms1MVVXeG9hVmRGU2xWWFYzUldaVVpPUjFWc1ZsSmhlbXhVVkZaV2QyUnNXa1ZSYkU1VllYcEdSMVJXYUVkWlZUQjVaVWRHWVZZemFIbFVWVnBUWkZkT1IxTnJOVk5XUjNoSFZsY3dlR014VVhsV2JsSnNVMFUxV1ZsclpGTlVNVkp6VmxSV1YxWnVRa2xhVlZwM1ZqQXhWMk5JYUZkU2VsWXpWbTF6ZDJRd01WWldiRTVYVWxSV2FGZHNaRFJXTURWSFdraEtZVkpzY0ZCVmJGSkRUbFpWZVUxWE9WVk5SRVo2V1ZST2MxWldXWHBSYlVaYVpXdEtlbFV3V2xOa1ZsSjBZVVprVGxadE9UUldNblJYWVRKTmVWVllhRkppUmxwVVZtdGFZVlF4YkZkVmJFNVBVbXhLTUZrd1l6RmhNVnBWWWtWV1ZXRXlhSFpXUkVaaFVtMUtTV05HVWxkV01VcFJWMWh3UzFJeFpFZFhibFpYWWxoU1ZGcFhkR0ZrYkZsNFlVaGFhMDFzV2xkVU1WWlhZV3hKZWxWck9WcFdla0V3V2tSR1UyTnNWblZYYXpWb1pXeGFSMWRVUW1wbFJsSnpWMnRzVW1Kc1NsWlpiVEV6Wld4a2NWSnVTbXhXTVZwS1ZWY3hSMVl5Vm5OV2FrNVhUVVpLVUZaVVFURlhSbEp5WVVaa1YxSXphR2hXUmxKRFV6SlJlRnBGVmxWaVIxSnpWbXBDZDFKV2NFVlRiWFJZWVhwQ00xVXlOV3RYUmtwR1RsVm9WVlpzY0ROV01WcFBZMVphYzFKc1pFNWlWMUY2VmpKMFYySXhSblJUYTFwT1UwZDRWRlpxVG05VU1XeHpWMjVPYWsxV1NsbFVWbVJIWWtkS1YxTnJiRlppV0VKRVdWUkdhMUpyTVZWU2JHaFhVbGM0ZDFkVVFtRmtNV1JHVGxaV1VtRXpVbGhWYkdoRFRVWmtXR1JIY0U5V01IQXdWVzE0YjFReFRrWk9WWFJXWVd0d1ZGbHFSbmRTYkhCSFdrVTFUbFl6YUdGWFYzUnZWakZrYzFkcVdsTmlhelZYVlcxNGQxWkdjRWhOVlhSVVVqRmFSMWxWV25kWFJrcHlZMGh3VmsxdWFGUlZNakZTWlVaV2RWVnNRbGROTVVwdlZteFNSMVl3TlhOYVJtUldZbXR3VDFWc1VuTlNiRnBJVFZoa1ZVMVZjRWRaYTFKaFYwZEtSMU5zVG1GV2JIQXpWV3RhWVZkWFNrWk9Wa3BPVFd4S01WWnFTbmRUTVVsM1RWVmthbEp0ZUdoVmFrcHZZekZaZDFkdFJrOVdiWGg1Vmxab2IyRlZNWE5UYTNCWFZucFdjbFY2Um1GU2F6VllUMVpTYVZKcmNFMVhWM2hYWkRGYVYxUnVVazVXTTBKUFZGWldkMlJzWkhKV2JUbFhUV3hhZVZwVmFGTldWMHB5VGxjNVYyRnJXbWhVVmxwM1VteFNjVlJ0Ums1aVJXOTNWbTB3TVdNeVJuSk5XRkpzVWtWd1lWbHNZelZOTVhCV1ZsaG9VMUpVVmtwWk1GVjRZVWRGZDFkcVdsWk5WbHB5V1ZSS1IxTkdWbkpoUm1Sb1lYcFdhRlpxUW10T1IwbDRXa2hLWVZKck5YTldiVFZEVjJ4YVNFNVlaRlpXYkgsIGNsaWVudGlmPWJyLWxhbiwgdGhlbWVzcGVjPSwgKG51bGwpKG51bGwpKG51bGwpKG51bGwp
And the router redirects from http://192.168.8.1/ to the FAS script. However, I'm unable to reach the endpoint on the VPS unless if I use a different internet gateway to connect to the internet.
Perhaps this has something to do with my firewall rules or my opennds configurations.
Here are some of my configurations:
option enabled 1
option gatewayname 'TollGate'
option gatewayinterface 'br-lan'
option fasport '80'
option faspath /cgi-bin/bitcoin-fas.cgi
option fasremoteip '37.27.205.50'
option fas_secure_enabled '1'
option faskey 'b37a6672d84622b262b8336fd283e670e2b80b75a520c1e711204b881e4c466a'
option fasremotessl 'yes'
Here are my opennds related logs when my computer has access to a second internet gateway in order to communicate with the VPS:
~ # logread | grep "opennds" | tail -n 100
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: Getting query, separator is [&].
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: query is []
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: Query string is [ ]
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fconnectivity-check.ubuntu.com%2f, length: 45
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: originurl_raw: http://connectivity-check.ubuntu.com/
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: originurl: http%3a%2f%2fconnectivity-check.ubuntu.com%2f
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: safe_snprintf: [ 20 ]
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fstatus.client, length: 26
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: gw_url: http%3a%2f%2fstatus.client
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: hid=1b6b6edb7a57a1cb63e547a32515aed590ec70078c811516f5a30a63b88fde7d
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: safe_snprintf: [ 58 ]
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/get_client_interface.sh 28:d2:44:64:f1:f7
Tue Sep 24 11:45:43 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: command output: [br-lan]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: Client Mac Address: 28:d2:44:64:f1:f7
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: Client Connection(s) [localif] [remotemeshnodemac] [localmeshif]: br-lan
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: clientif: [br-lan] url_encoded_gw_name: [TollGate%20Node%3a9483c423e42d%20]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: string to b64 encode: hid=1b6b6edb7a57a1cb63e547a32515aed590ec70078c811516f5a30a63b88fde7d, clientip=192.168.8.152, clientmac=28:d2:44:64:f1:f7, client_type=cpi_url, cpi_query=http%3a%2f%2fstatus.client%2flogin, gatewayname=TollGate%20Node%3a9483c423e42d%20, gatewayurl=http%3a%2f%2fstatus.client, version=10.3.0, gatewayaddress=192.168.8.1:2050, gatewaymac=9483c423e42d, originurl=http%3a%2f%2fconnectivity-check.ubuntu.com%2f, clientif=br-lan, themespec=, (null)(null)(null)(null) length 460
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: b64 encoded string: aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmNvbm5lY3Rpdml0eS1jaGVjay51YnVudHUuY29tJTJmLCBjbGllbnRpZj1ici1sYW4sIHRoZW1lc3BlYz0sIChudWxsKShudWxsKShudWxsKShudWxsKQ==, encoded length: 616
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: Constructed Query String [?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmNvbm5lY3Rpdml0eS1jaGVjay51YnVudHUuY29tJTJmLCBjbGllbnRpZj1ici1sYW4sIHRoZW1lc3BlYz0sIChudWxsKShudWxsKShudWxsKShudWxsKQ==]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: safe_snprintf: [ 679 ]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: splashpageurl: http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmNvbm5lY3Rpdml0eS1jaGVjay51YnVudHUuY29tJTJmLCBjbGllbnRpZj1ici1sYW4sIHRoZW1lc3BlYz0sIChudWxsKShudWxsKShudWxsKShudWxsKQ==
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: safe_snprintf: [ 1440 ]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: MHD_create_response_from_buffer. url [http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmNvbm5lY3Rpdml0eS1jaGVjay51YnVudHUuY29tJTJmLCBjbGllbnRpZj1ici1sYW4sIHRoZW1lc3BlYz0sIChudWxsKShudWxsKShudWxsKShudWxsKQ==]
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Redirect to [<html><head></head><body><a href='http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmNvbm5lY3Rpdml0eS1jaGVjay51YnVudHUuY29tJTJmLCBjbGllbnRpZj1ici1sYW4sIHRoZW1lc3BlYz0sIChudWxsKShudWxsKShudWxsKShudWxsKQ=='>Click here to continue to<br>http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Response created
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Location header added to redirection page
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Connection header added to redirection page
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Queueing response
Tue Sep 24 11:45:44 2024 daemon.debug opennds[1738]: send_redirect_temp: Response is Queued
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Attempting to get mac of interface: br-lan
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh "gatewaymac" "br-lan" "9483c423e42d"
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: command output: [9483c423e42d]
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Watchdog: Gateway Interface [br-lan], mac [9483c423e42d]
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh mhdcheck "192.168.8.1:2050"
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: client access: GET /mhdstatus
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: MHD Status Request - /mhdstatus
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: command output: [1]
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: MHD Test Result: 1
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Starting Refresh Client List
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh gatewayroute "br-lan"
Tue Sep 24 11:45:45 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: command output: [online:192.168.123.177,phy0-sta0 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Online Status [ 1 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: safe_snprintf: [ 67 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: safe_snprintf: [ 64 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Rate Check Window is set to 2 period(s) of checkinterval
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Locking client list
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Client list locked
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: conn_state [0]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Unlocking client list
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Client list unlocked
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: safe_snprintf: [ 67 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_list_from_config 'preemptivemac'
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: command output: []
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: preemptivemaclist is empty
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: safe_snprintf: [ 55 ]
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_next_preemptive_auth
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: command output: []
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: done with preemprive_auth checks
Tue Sep 24 11:45:46 2024 daemon.debug opennds[1738]: Client List Refresh is Done
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Attempting to get mac of interface: br-lan
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh "gatewaymac" "br-lan" "9483c423e42d"
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: command output: [9483c423e42d]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Watchdog: Gateway Interface [br-lan], mac [9483c423e42d]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh mhdcheck "192.168.8.1:2050"
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: client access: GET /mhdstatus
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: MHD Status Request - /mhdstatus
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: command output: [1]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: MHD Test Result: 1
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Starting Refresh Client List
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh gatewayroute "br-lan"
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: command output: [online:192.168.123.177,phy0-sta0 ]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Online Status [ 1 ]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: safe_snprintf: [ 67 ]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: safe_snprintf: [ 64 ]
Tue Sep 24 11:46:01 2024 daemon.debug opennds[1738]: Rate Check Window is set to 2 period(s) of checkinterval
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Locking client list
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Client list locked
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: conn_state [0]
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Unlocking client list
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Client list unlocked
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: safe_snprintf: [ 67 ]
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_list_from_config 'preemptivemac'
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: command output: []
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: preemptivemaclist is empty
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: safe_snprintf: [ 55 ]
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_next_preemptive_auth
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: command output: []
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: done with preemprive_auth checks
Tue Sep 24 11:46:02 2024 daemon.debug opennds[1738]: Client List Refresh is Done
~ # ndsctl json
{
"client_list_length":"1",
"clients":{
"28:d2:44:64:f1:f7":{
"gatewayname":"TollGate%20Node%3a9483c423e42d%20",
"gatewayaddress":"192.168.8.1:2050",
"gatewayfqdn":"status.client",
"version":"10.3.0",
"client_type":"cpi_url",
"mac":"28:d2:44:64:f1:f7",
"ip":"192.168.8.152",
"clientif":"br-lan",
"session_start":"0",
"session_end":"null",
"last_active":"1727178151",
"token":"5dacd6be",
"state":"Preauthenticated",
"custom":"none",
"download_rate_limit_threshold":"null",
"download_packet_rate":"null",
"download_bucket_size":"null",
"upload_rate_limit_threshold":"null",
"upload_packet_rate":"null",
"upload_bucket_size":"null",
"download_quota":"null",
"upload_quota":"null",
"download_this_session":"0",
"download_session_avg":"0.00",
"upload_this_session":"0",
"upload_session_avg":"0.00"
}
}
}
And here are the logs that I get when I don't have access to the VPS with the FAS via a different internet gateway:
~ # logread | grep "opennds" | tail -n 100
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: client access: POST /ts2021
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Unsupported http method POST, Network Authentication required (Error 511)
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: safe_snprintf: [ 56 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/client_params.sh err511 '192.168.8.152'
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: command output: [br-lan]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Client Mac Address: 28:d2:44:64:f1:f7
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Client Connection(s) [localif] [remotemeshnodemac] [localmeshif]: br-lan
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: clientif: [br-lan] url_encoded_gw_name: [TollGate%20Node%3a9483c423e42d%20]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: string to b64 encode: hid=1b6b6edb7a57a1cb63e547a32515aed590ec70078c811516f5a30a63b88fde7d, clientip=192.168.8.152, clientmac=28:d2:44:64:f1:f7, client_type=cpi_url, cpi_query=http%3a%2f%2fstatus.client%2flogin, gatewayname=TollGate%20Node%3a9483c423e42d%20, gatewayurl=http%3a%2f%2fstatus.client, version=10.3.0, gatewayaddress=192.168.8.1:2050, gatewaymac=9483c423e42d, originurl=http%3a%2f%2fhelsinki.orangesync.tech%2fcgi-bin%2fbitcoin-fas.cgi%3ffas%3daGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUy
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: b64 encoded string: aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd1RtOWtaU1V6
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Constructed Query String [?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: safe_snprintf: [ 2659 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: splashpageurl: http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bm
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: safe_snprintf: [ 5400 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: MHD_create_response_from_buffer. url [http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWx
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Redirect to [<html><head></head><body><a href='http://helsinki.orangesync.tech:80/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZE
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Response created
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Location header added to redirection page
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Connection header added to redirection page
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Queueing response
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: send_redirect_temp: Response is Queued
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: client access: GET /cgi-bin/bitcoin-fas.cgi
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: safe_snprintf: [ 66 ]
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_interface_by_ip "192.168.8.152"
Tue Sep 24 11:47:52 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client access: POST /ts2021
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Unsupported http method POST, Network Authentication required (Error 511)
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: safe_snprintf: [ 56 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/client_params.sh err511 '192.168.8.152'
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client access: GET /canonical.html
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: safe_snprintf: [ 66 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/libopennds.sh get_interface_by_ip "192.168.8.152"
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client access: POST /ts2021
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Unsupported http method POST, Network Authentication required (Error 511)
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: safe_snprintf: [ 56 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/client_params.sh err511 '192.168.8.152'
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client access: POST /ts2021
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Unsupported http method POST, Network Authentication required (Error 511)
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: client ip address is [ 192.168.8.152 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: safe_snprintf: [ 56 ]
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/client_params.sh err511 '192.168.8.152'
Tue Sep 24 11:47:53 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: command output: [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Interface used to route ip [192.168.8.152] is [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Gateway Interface is [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Client ip address [192.168.8.152] is on our subnet using interface [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: host [helsinki.orangesync.tech] url [/cgi-bin/bitcoin-fas.cgi]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: url is [ /cgi-bin/bitcoin-fas.cgi ], checking for [ opennds_preauth ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: url is [ /cgi-bin/bitcoin-fas.cgi ], checking for [ opennds_deny ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: Requested Host is [ helsinki.orangesync.tech ], url is [/cgi-bin/bitcoin-fas.cgi]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Our host: 192.168.8.1:2050 Requested host: helsinki.orangesync.tech
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: foreign host [helsinki.orangesync.tech] detected
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Getting query, separator is [&].
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: cumulative element length is [2600]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: element [0] is [fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd1RtOWtaU1V
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: query is [?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd1RtOWtaU1V6WVRr
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Query string is [ ?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXNHNJR2RoZEdWM1lYbHVZVzFsUFZSdmJHeEhZWFJsSlRJd1RtOWtaU
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fhelsinki.orangesync.tech%2fcgi-bin%2fbitcoin-fas.cgi%3ffas%3daGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cF
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: originurl_raw: http://helsinki.orangesync.tech/cgi-bin/bitcoin-fas.cgi?fas=aGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEptYkc5bmFXN
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: originurl: http%3a%2f%2fhelsinki.orangesync.tech%2fcgi-bin%2fbitcoin-fas.cgi%3ffas%3daGlkPTFiNmI2ZWRiN2E1N2ExY2I2M2U1NDdhMzI1MTVhZWQ1OTBlYzcwMDc4YzgxMTUxNmY1YTMwYTYzYjg4ZmRlN2QsIGNsaWVudGlwPTE5Mi4xNjguOC4xNTIsIGNsaWVudG1hYz0yODpkMjo0NDo2NDpmMTpmNywgY2xpZW50X3R5cGU9Y3BpX3VybCwgY3BpX3F1ZXJ5PWh0dHAlM2ElMmYlMmZzdGF0dXMuY2xpZW50JTJmbG9naW4sIGdhdGV3YXluYW1lPVRvbGxHYXRlJTIwTm9kZSUzYTk0ODNjNDIzZTQyZCUyMCwgZ2F0ZXdheXVybD1odHRwJTNhJTJmJTJmc3RhdHVzLmNsaWVudCwgdmVyc2lvbj0xMC4zLjAsIGdhdGV3YXlhZGRyZXNzPTE5Mi4xNjguOC4xOjIwNTAsIGdhdGV3YXltYWM9OTQ4M2M0MjNlNDJkLCBvcmlnaW51cmw9aHR0cCUzYSUyZiUyZmhlbHNpbmtpLm9yYW5nZXN5bmMudGVjaCUyZmNnaS1iaW4lMmZiaXRjb2luLWZhcy5jZ2klM2ZmYXMlM2RhR2xrUFRGaU5tSTJaV1JpTjJFMU4yRXhZMkkyTTJVMU5EZGhNekkxTVRWaFpXUTFPVEJsWXpjd01EYzRZemd4TVRVeE5tWTFZVE13WVRZellqZzRabVJsTjJRc0lHTnNhV1Z1ZEdsd1BURTVNaTR4TmpndU9DNHhOVElzSUdOc2FXVnVkRzFoWXoweU9EcGtNam8wTkRvMk5EcG1NVHBtTnl3Z1kyeHBaVzUwWDNSNWNHVTlZM0JwWDNWeWJDd2dZM0JwWDNGMVpYSjVQV2gwZEhBbE0yRWxNbVlsTW1aemRHRjBkWE11WTJ4cFpXNTBKVEp
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: safe_snprintf: [ 20 ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fstatus.client, length: 26
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: gw_url: http%3a%2f%2fstatus.client
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: hid=1b6b6edb7a57a1cb63e547a32515aed590ec70078c811516f5a30a63b88fde7d
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: safe_snprintf: [ 58 ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/get_client_interface.sh 28:d2:44:64:f1:f7
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Reading command output
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: command output: [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Interface used to route ip [192.168.8.152] is [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Gateway Interface is [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Client ip address [192.168.8.152] is on our subnet using interface [br-lan]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: host [detectportal.firefox.com] url [/canonical.html]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: url is [ /canonical.html ], checking for [ opennds_preauth ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: url is [ /canonical.html ], checking for [ opennds_deny ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: Requested Host is [ detectportal.firefox.com ], url is [/canonical.html]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Our host: 192.168.8.1:2050 Requested host: detectportal.firefox.com
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: preauthenticated: foreign host [detectportal.firefox.com] detected
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Getting query, separator is [&].
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: query is []
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Query string is [ ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fdetectportal.firefox.com%2fcanonical.html, length: 54
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: originurl_raw: http://detectportal.firefox.com/canonical.html
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: originurl: http%3a%2f%2fdetectportal.firefox.com%2fcanonical.html
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: safe_snprintf: [ 20 ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: URL encoded string: http%3a%2f%2fstatus.client, length: 26
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: gw_url: http%3a%2f%2fstatus.client
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: hid=1b6b6edb7a57a1cb63e547a32515aed590ec70078c811516f5a30a63b88fde7d
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: safe_snprintf: [ 58 ]
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Executing command: /usr/lib/opennds/get_client_interface.sh 28:d2:44:64:f1:f7
Tue Sep 24 11:47:54 2024 daemon.debug opennds[1738]: Reading command output
Any idea what I'm doing wrong? How can I ensure that the FAS is reachable via the openwrt router that is running opennds even though I don't have any secondary internet gateway?
Based on your configuration and logs, it seems the issue persists despite the walled garden configuration. Let's try to debug this step-by-step:
DNS Resolution: First, we need to ensure that DNS resolution is working for preauthenticated clients. Try this on a client device:
nslookup helsinki.orangesync.tech
If this doesn't resolve, we need to ensure DNS queries are allowed for preauthenticated clients.
Firewall Rules: Your firewall configuration looks good, but let's add a specific rule for the FAS:
uci add firewall rule
uci set firewall.@rule[-1].name='Allow FAS'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].proto='tcp'
uci set firewall.@rule[-1].dest_port='80 443'
uci set firewall.@rule[-1].dest_ip='37.27.205.50'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart
OpenNDS Configuration:
Modify your OpenNDS configuration (/etc/config/opennds
) as follows:
config opennds
option enabled '1'
option debuglevel '3'
option fwhook_enabled '1'
option gatewayinterface 'br-lan'
option gatewayname 'TollGate'
option fasport '80'
option faspath '/cgi-bin/bitcoin-fas.cgi'
option fasremoteip '37.27.205.50'
option fasremotefqdn 'helsinki.orangesync.tech'
option fas_secure_enabled '1'
option faskey 'b37a6672d84622b262b8336fd283e670e2b80b75a520c1e711204b881e4c466a'
option fasremotessl 'yes'
option preauth_dns_enable '1'
option allow_preauth_remote_dns '1'
list preauthenticated_users 'allow tcp port 80 to helsinki.orangesync.tech'
list preauthenticated_users 'allow tcp port 443 to helsinki.orangesync.tech'
list preauthenticated_users 'allow udp port 53 to 0.0.0.0/0'
The allow_preauth_remote_dns
option and the additional preauthenticated_users entry for UDP port 53 should help with DNS resolution.
Restart OpenNDS: After making these changes, restart OpenNDS:
/etc/init.d/opennds restart
Debug Logging: Increase the debug level in OpenNDS to get more detailed logs:
uci set opennds.@opennds[0].debuglevel='7'
uci commit opennds
/etc/init.d/opennds restart
Then monitor the logs:
logread -f | grep opennds
Network Trace: On the OpenWrt router, install tcpdump and capture traffic:
opkg update
opkg install tcpdump
tcpdump -i br-lan host 37.27.205.50
This will show you if the traffic is reaching the router and if it's being forwarded correctly.
Client-side Debugging: On your client device, try to access the FAS URL directly:
curl -v http://helsinki.orangesync.tech/cgi-bin/bitcoin-fas.cgi
This will show you the full HTTP request and response, which can be helpful in identifying where the connection is failing.
Check OpenNDS Status:
Run ndsctl status
to see the current state of OpenNDS and any connected clients.
Verify FAS Accessibility: Ensure that your FAS is actually running and accessible from the internet. Try accessing it from a device not connected to your OpenWrt router.
IP Tables: Check the iptables rules to ensure traffic is being properly redirected:
iptables -t nat -L PREROUTING -n -v
iptables -L -n -v
After making these changes and gathering more debug information, we should be able to pinpoint where the connection is failing. If you're still having issues, please provide the output of these debug steps, especially the OpenNDS logs and the tcpdump output when trying to access the FAS.
This works now, but without FAS... Part of the problem was that the router sometimes doesn't assign a DHCP lease.
Based on the information you've provided, it appears that OpenNDS is running, but clients are not being captured by the captive portal. Also, you mentioned:
ndsctl json
output shows that there are no connected clients.iptables
) chains are empty, indicating that no firewall rules are being applied.Given these observations, the most probable cause of the issue is that the firewall is not running or not configured correctly. OpenNDS relies heavily on firewall rules to redirect client traffic to the captive portal and control access.
Steps to Debug and Resolve the Issue
1. Verify Firewall Status and Functionality
Check if the firewall is running:
Try to start the firewall:
Check the firewall status again:
Verify if the firewall rules are loaded:
Check for any errors in the firewall logs:
2. Ensure Firewall Packages Are Installed and Up-to-Date
Update package lists:
Reinstall the firewall package:
Depending on your OpenWrt version, you might need to install
firewall3
orfirewall4
. Run:Note: Installing
firewall
should pull in the appropriate version for your OpenWrt release.Restart the firewall service:
3. Validate Firewall Configuration
Check the firewall configuration for errors:
Validate the firewall configuration:
/etc/config/firewall
file for syntax errors or invalid settings.If validation fails:
/etc/config/firewall
for any mistakes or misconfigurations.4. Restart Networking and OpenNDS Services
After ensuring the firewall is running correctly:
Restart the network service:
Restart OpenNDS:
Check the status of OpenNDS:
5. Verify iptables Rules
Check the iptables rules again:
For example, there should be chains like
ndsRULES
,ndsOUT
,ndsIN
, etc.6. Test Captive Portal Functionality
Connect a client device (like a smartphone or laptop) to the router's Wi-Fi network.
Ensure the client device is set to obtain IP and DNS settings automatically (via DHCP).
Try accessing a website (e.g.,
https://www.example.com
).If not redirected:
Try accessing a non-HTTPS site, e.g.,
http://neverssl.com
.Some devices and browsers don't redirect HTTPS requests to the captive portal due to security reasons.
Check the client list in OpenNDS:
Check OpenNDS logs for client activity:
7. Additional Debugging Steps
Check DHCP and DNS Services
Ensure that the DHCP service (
dnsmasq
) is running correctly:Check the
/etc/config/dhcp
file for any misconfigurations.Ensure clients are receiving correct IP addresses and DNS settings.
Clear any Existing Client Entries
If your device was previously authenticated or whitelisted, it might bypass the captive portal.
Clear the client entries:
Test with Different Devices
Try using another device to rule out client-side caching issues.
Disable Wi-Fi and re-enable it on the client device to refresh connection settings.
8. Review OpenNDS Configuration
Ensure Basic Configuration is Correct
Here's a minimal working configuration for
/etc/config/opennds
:Ensure
gatewayinterface
matches your LAN interface.Set
debuglevel
to '3' to get detailed logging:9. Ensure No Conflicts with Other Services
Since you mentioned that OpenVPN was previously running:
Make sure OpenVPN is stopped and not interfering:
Disable OpenVPN from starting automatically:
Check for any other services that might be interfering with network configurations or firewall rules.
10. Check for Software Bugs or Compatibility Issues
If after all these steps, OpenNDS is still not functioning correctly:
Check the OpenNDS and OpenWrt versions:
Ensure compatibility between OpenNDS and your OpenWrt version.
Consider downgrading OpenNDS to a previous version if you suspect a bug in the latest release.
11. Reinstall OpenNDS
As a last resort, you can remove and reinstall OpenNDS:
Remove OpenNDS:
Update package lists:
Install OpenNDS:
Use the default configuration generated upon installation, and only make minimal necessary changes.
Summary
Fixing the Firewall: Your firewall is not active or not functioning correctly, which prevents OpenNDS from manipulating network traffic as needed.
Ensuring OpenNDS Configuration is Correct: Using a minimal and correct configuration will help eliminate potential misconfigurations.
Restarting Services and Testing: After making changes, always restart services and test with client devices.
Checking Logs and Status Outputs: Monitoring logs and the output of status commands helps identify where the issue lies.
Final Notes
Firewall is Crucial: Since OpenNDS relies on the firewall to intercept and redirect traffic, the firewall must be running and correctly configured.
OpenNDS Logs: Increasing the debug level helps provide more detailed logs, which are essential for troubleshooting.
Client Device Behavior: Sometimes, client devices cache network information that may bypass the captive portal. Resetting network settings on the client can help.
Alternative Solutions: If issues persist, consider trying another captive portal solution like NoDogSplash.
Please let me know if you need further assistance or if any step is unclear.