Topics

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.

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;

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.

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 ?

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.

I have purchased an Deciso appliance with OPNSense pre installed. I have managed to get the serial console working where I can see the boot sequence but I do not have serial console access.
System -> Administration settings are:
Console    
Console driver    Use the virtual terminal driver (vt)
Primary Console    Serial Console
Secondary Console  Serial Console   
Serial Speed     115200
USB-based serial    Use USB-based serial ports
Console menu    Password protect the console menu

Am I missing something ?

I am experiencing a problem on several installations where the DHCP server stops sending out DHCP addresses and if we manually address we still cannot ping the router. It is as if the Interface has suddenly started blocking all traffic on that VLAN.

We started experiencing this after upgrading ZenArmor mid November. I am not sure it is definitely a ZenArmor issue or something else. Nothing in the logs to indicate any issues.

I have an issue booting the latest on a Deciso a10. I have 2 different boxes identical. 2 different USB disks. All show the same.

unzipped OPNsense-20.7-OpenSSL-serial-amd64.bz2 after checking the SHA256.

Remove all partitions from the  USB disk

jon@jon-MACH-WX9:~$ sudo dd if='/home/jon/Downloads/OPNsense-20.7-OpenSSL-serial-amd64.img' of=/dev/sda bs=16k;sync
[sudo] password for jon:         
114084+0 records in
114084+0 records out
1869152256 bytes (1.9 GB, 1.7 GiB) copied, 217.081 s, 8.6 MB/s
jon@jon-MACH-WX9:~$ screen /dev/ttyXRUSB0 115200

In every case even manual select of the USB drive it continues to boot from the HDD boot log follows.

I have done this many many times in the past so not sure what the issue is here.



Scan for option roms
Running option rom at c000:0003
pmm call arg1=1
pmm call arg1=0
pmm call arg1=1
pmm call arg1=0
Searching bootorder for: /rom@genroms/pxe.rom

Press ESC for boot menu.

Select boot device:

1. AHCI/0: TS128GSSD420K ATA-9 Hard-Disk (119 GiBytes)
2. USB MSC Drive USB Flash DISK 1100
3. iPXE (PCI 00:00.0)
4. Payload [memtest]

Searching bootorder for: HALT
drive 0x000f3280: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=31703040
drive 0x000f32b0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=250069680
Space available for UMB: c1000-ee800, f0000-f3280
Returned 253952 bytes of ZoneHigh
e820 map has 7 items:
  0: 0000000000000000 - 000000000009fc00 = 1 RAM
  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 00000000df175000 = 1 RAM
  4: 00000000df175000 - 00000000e0000000 = 2 RESERVED
  5: 00000000f8000000 - 00000000fc000000 = 2 RESERVED
  6: 0000000100000000 - 0000000120000000 = 1 RAM
enter handle_19:
  NULL
Booting from Hard Disk...
Booting from 0000:7c00
/boot/config: -S115200 -D

We had our captive portal hacked and some research showed duplicate IP/MACs

Doing some research it appears very simple to compromise layer 2 by doing an ARP  scan and finding who is authenticated by spoofing the MAC and IP address and hijacking an authenticated session.

I downloaded a proof of concept script here : https://github.com/systematicat/hack-captive-portals

Worked after 3 tries.

Does OPNSense have any defense against this ?

Thanks

Jonathan

We have been running Unifi controller very nicely on the older versions of opnSense. using the link https://github.com/gozoinks/unifi-pfsense

Now we have an issue - starting MongoDB we have a library missing

root@gabtest:~ # mongod
Shared object "libdl.so.1" not found, required by "mongod"

Incorporating the controller has been a key part of our deployments and would be nice to keep everything in the one box if possible.

I realize this may void the warranty but if the pieces could play nice together it would be great and any ideas I can try in my sandbox would be much appreciated.