Messages

Chalk one up for Google Gemini who proposed the following fix that worked for me.

Try Re-initializing DHCP Settings in the GUI (Safest First Step):

    Go to Services > Dnsmasq DNS.
    Even if you don't want DHCP enabled, try this:
        Select an interface (e.g., your LAN interface) in the "DHCP Server" section.
        Enable the DHCP server for that interface.
        Enter a minimal valid DHCP range (e.g., 192.168.1.200 to 192.168.1.210 if your LAN is 192.168.1.0/24).
        Click Save.
        Now, go back and disable the DHCP server for that interface if you don't need it.
        Click Save again.
    The idea is that by explicitly enabling and then disabling (or just saving with a basic enabled config), you might force OPNsense to correctly populate the dhcp section in its internal configuration data structure, even if it ends up being empty/disabled.
    After doing this, try restarting Dnsmasq from the GUI. Check the backend log again for the error.

The answer was in the documentation and a weekend of trial and error. API call is shown below


<script type="text/javascript" src="js/zone.js"></script>
<script type="text/javascript" src="js/jquery-1.11.2.min.js"></script>

<script type="text/javascript">
  // Initialize macAddress (you might want to use a default or placeholder if needed)
  var mac = "";

  $.ajax({
    type: "POST",
                     url: "/api/captiveportal/access/status/" + zoneid + "/",
                     dataType:"json",
                     data:{ user: $("#inputUsername").val(), password: $("#inputPassword").val() }
   
  }).done(function(data) {
    // Correctly extract the MAC address (assuming data['macAddress'] contains the MAC)
    mac = data['macAddress'];

    // --- Construct the redirect URL AFTER getting the MAC ---
    var externalPortalURL = "https://external.site/test/login";
    var redirectURL = externalPortalURL + "?Zone=" + encodeURIComponent(zoneid) + "&mac=" + encodeURIComponent(mac);

    // Redirect the user
    window.location.href = redirectURL;
  });
</script>

I am trying to get the captive portal to use an external commercial service.

I need to get the MAC address to send this to the external site. I have the custom template working and I have also checked the box to provide extended data (in the advanced section) I cannot see any documentation where I can get the data I need to concatenate with the redirect HTML call.

Any help or pointers would be appreciated - I have my Web call below and need to find the variables MAC and IP filled in:

     function redirect() {
            // Get the necessary parameters.  OPNsense *must* be configured to pass these.
            var mac = getParameterByName('mac');
            var ip = getParameterByName('ip');
            var sessionIp = getParameterByName('redirurl');  //Best guess, based on common practice

            //Check for ip in redirurl and extract it.
            const ipRegex = /\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b/;
            const match = sessionIp ? sessionIp.match(ipRegex) : null;

            if (match) {
                sessionIp = match[0];
            } else {
                sessionIp = ''; // Or some default value if extraction fails.
            }

            // Build the redirect URL.
            var redirectUrl = "https://wifihotspot.io/test/login?mac=" + encodeURIComponent(mac) +
                              "&ip=" + encodeURIComponent(ip) +
                              "&sessionip=" + encodeURIComponent(sessionIp);
            // Redirect.
             window.location.replace(redirectUrl);
        }

        // Redirect as soon as the page loads.
        window.onload = redirect;

Looking deeper it appears that Monit is detecting a shutdown. The event started just before reboot so the delay is probably working not sure why the behavior is different to all my other firewalls.

I am having an issue with monit failing to access the Postfix server.

I have tried a start delay from 120 to 1000 and it appears that Monit always tries to access the mail server before the system is fully booted and Postfix is not running.

As soon as I get access to the Gui I see Monit has already tried and failed to send a message:

2023-11-01T14:09:40   Error   monit   Cannot connect to [localhost]:25 -- Connection timed out   
2023-11-01T14:00:02   Error   monit   Cannot open a connection to the mailserver localhost:25 -- Permission denied

When I can access the server is accessible:
root@OADStarlink:~ # telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 oadstarlink ESMTP Postfix
HELO localhost
250 oadstarlink



Monit config follows:

root@OADStarlink:~ # cat /usr/local/etc/monitrc
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file

set httpd unixsocket /var/run/monit.sock
    allow localhost

set daemon 120 with start delay 120

set logfile syslog facility log_daemon



set mailserver localhost,10.10.11.1 port 25   

set alert jon@xaxero.com  { instance,resource }  reminder on 10 cycles

check system $HOST
   if memory usage is greater than 75% then alert
   if cpu usage is greater than 75% then alert
   if loadavg (1min) is greater than 16 then alert
   if loadavg (5min) is greater than 12 then alert

check filesystem RootFs with path "/"
   if space usage is greater than 75% then alert




include /usr/local/etc/monit.opnsense.d/*.conf

Still having issues with Dpinger dropping gateways when Starlink goes offline. Restarting the dpinger service brings it back up.
I have sledgehammered a solution while not ideal works. I am asking for this feature to be added to OPNSense:

I created a file /usr/local/opnsense/service/conf/actions.d/actions_dpinger.conf

And added the following code:



[restart]
command:/usr/local/sbin/pluginctl -s dpinger restart
parameters:
type:script
message:Restarting Dpinger
description:Restart Dpinger service

I was then able to create a Cron Job via the web interface:
*/5     *       *       *       *       (/usr/local/sbin/pluginctl -s dpinger restart

If this could be added to the main build I think it would benefit the OPNSense community.

Movistar Uruguay - got it down to 32 bytes

I am using a 4G modem and everything was working fine except DPinger. Gateway is always shown as down. Doing a TCP Dump I see ping returned when I do a normal ping all works fine.

I tried to use ChatGPT to debug and it suggested among other ideas to do a packet capture. Pings with 64 bytes were working but Dpinger's 8 were not.

Upping the packet count to 64 fixed it. - Must be an issue on the ISP end.

08:02:17.325629 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 59929, seq 39, length 8
08:02:18.326719 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 59929, seq 40, length 8
08:04:14.840672 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 45724, seq 1, length 64
08:04:14.884388 IP 151.101.195.5 > 192.168.0.173: ICMP echo reply, id 45724, seq 1, length 64
08:04:15.842099 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 45724, seq 2, length 64
08:04:15.879343 IP 151.101.195.5 > 192.168.0.173: ICMP echo reply, id 45724, seq 2, length 64

We have a ship at 80 N using Starling that occasionally has drop outs. Normally everything recovers and we go our merry way. However we have seen as we are operating in high terrain at times the router becoming unavailable and needing to be rebooted via a cold restart.

A post mortem shows the logs continually chucking out the following message:

Error   dhclient   send_packet: No buffer space available

It would appear BSD has got itself in a loop in which we cannot get in. Is there a workaround here ?

Last thought - perhaps we could include httping as an option in the future as well as dpinger. http has much higher priority.

I am collating the data from this post and others Applies to Starlink only but may be useful elsewhere. Applied the following fixes  from everyone's suggestions and the gateways are stable - We are having frequent outages as we are in laser link territory however the link is stable overall.

1/. Wan Definition Reject leases from 192.168.100.1 (note gateways are on separate router in my case)
2/. Gateway - Disable host route.
3/. Monitor IP that is not 1.1.1.1 (In my case open DNS) and bind each interface to DNS via Settings General.

Interfaces have been going up and down last 24 hours and the gateways (so far) are behaving and the routes are changing dynamically

Good Morning
    Changing to openDNS has resulted in a big improvement. 48 hours with no issues. However SL has been very stable. The second  unit I simply use the SL Gateway address.

Note: As I am using the Dual antenna setup I have put in a second router at the front end simply to NAT the traffic and so I have a unique gateway for each antenna and tagging the packets onto separate VLANS to our main router several decks down. 2 WANS with the same gateway was problematic if we had to do a full system power cycle.
With the front end router I am disabling gateway monitoring and I am doing all the DPinger stuff on the main router. Also Disable host route may have helped as well.

Another slimy hack is to force all passenger traffic through the 4G-Starlink-Primary interface via the firewall so this bypasses dpinger completely. The more critical ship traffic goes through the Gateway failover and the worst case scenario is that we are stuck on the VSAT until I can restart Dpinger.

I have attached the gateway configuration of the front and and the core routers. So far it has been working well.

OK Done as you suggested on the one interface (main) Will see how it goes.    



Name    Interface    Protocol    Priority    Gateway    Monitor IP    RTT    RTTd    Loss    Status    Description    
      StarlinkBackup_GWv4 (active)    StarlinkBackup    IPv4    199    192.168.192.1    100.64.0.1    46.8 ms    11.7 ms    0.0 %    Online
   StarBK    
      StarMain_VLAN_GWv4    4G_VLAN    IPv4    201    192.168.191.1    208.67.222.222    36.3 ms    7.8 ms    0.0 %    Online
   StrMain    
   

Good Morning
  I am trying this 2 ways (I use 2 Starlink Maritime interfaces)

StarlinkBackup_GWv4 (active)    StarlinkBackup    IPv4    199    192.168.192.1    100.64.0.1    40.0 ms    9.0 ms    0.0 %    Online
   
      Starmain_VLAN_GWv4    4G_VLAN    IPv4    201    192.168.191.1    1.1.1.1    0.0 ms    0.0 ms    100.0 %    Offline
   StrMain    
      
I use the remote gateway IP for one 100.64.0.1 and this works better than 1.1.1.1 that is down every morning.

I have an issue that seems to be ongoing and I cannot see a fix in the forums. If this has been resolved apologies.

Using starlink where the WAN frequently drops out DPinger needs to be restarted in order for the gateway monitoring to work again and the routes services restarted to get the default route back.

Has anyone found a fix for this yet? I have disabled sticky connections in the firewall settings.