Messages

All fixed after the patch, thanks for the super quick response Franco!

Hi team,

Thanks for the update. After updating to 24.7.9 I get a user/password wrong error when trying to log into the WebGUI. I have 2FA enabled right after the password.

Rollback to 24.7.8 fixed the issue.

Thanks!

Hi there,

Every time I restart the ipsec/strongswan service, either from the Dashboard GUI or through CLI, the strongswan service does not start again.
I have tried different commands, and it's only restart that fails (stop + start works OK). Nothing on the ipsec/strongswan logs as the service never starts again.

Code Select Expand


root@opnsense:~ # configctl ipsec restart
OK
And:
root@opnsense:~ # pluginctl -s strongswan restart
Service `strongswan' has been restarted.


I have tried adding a sleep on the actions file, but still not working (I have restarted the configd service).

Code Select Expand


[restart]
command:/usr/local/etc/rc.d/strongswan onestop; /usr/bin/sleep 5; /usr/local/sbin/pluginctl -c ipsec
parameters:
type:script
message:IPsec service restart
description:Restart IPsec service


Any ideas? Happy to run some additional tests/provide logs.
Thanks!

Missed the Advanced Settings on the Interface for the dhclient. After some tweaking, seems the error is solved. Still seems dpinger is not fast enough for some gateways that even if working, appear as offline until I change one interface or restart the specific dpinger service for that gateway.

Dear all,
After the 23.7.4 update I'm having some issues after a reboot, as the WAN interface doesn't get an IP and therefore some of the services do not work properly. I've tried waiting 10+ minutes for the dhclient to get an IP but it doesn't work, need to go into the Interfaces --> Overview and force a DHCP renew, then everything starts to work as usual.
My WAN interface is VLAN 832 on a port connected to an ONT.

Code Select Expand


/usr/local/etc/rc.bootup: The command '/sbin/dhclient -c '/var/etc/dhclient_wan.conf' -p '/var/run/dhclient.vlan083.pid' 'vlan083'' returned exit code '1', the output was 'vlan083: no link .............. giving up'
/usr/local/etc/rc.reload_all: The command `/sbin/ifconfig 'igc1' mtu '9000'' failed to execute
/usr/local/etc/rc.reload_all: The command `/sbin/ifconfig 'igc2' mtu '9000'' failed to execute
/usr/local/etc/rc.reload_all: The command '/bin/kill -'TERM' '93260''(pid:/var/run/dhclient.vlan083.pid) returned exit code '1', the output was 'kill: 93260: No such process'
unknown dhcp option value 0x5a
/usr/local/etc/rc.newwanip: The command '/bin/kill -'TERM' '5274''(pid:/var/run/unbound.pid) returned exit code '1', the output was 'kill: 5274: No such process'


Any ideas?

Edit: Removed Certifiicate errors

Thanks heaveaxy for sharing your config. I'm using RADIUS on the client side and cannot get it to work.
Here's my config:
- FreeRADIUS server on the "Mobile Clients" menu, as even if it's in the changelog, I cannot see any way to select a RADIUS server on the new "Connections" menu.
- Local Authorization to Public Key, with the public certificate of my server
- Remote Authorization to EAP-RADIUS, with no certificate selected.

When connecting, I get the following on the log:

Code Select Expand

loading EAP_RADIUS method failed

And I don't even see the auth request on the FreeRADIUS logs. I think the issue is that the RADIUS server is not correctly set up, as I cannot see the menu to select it.
With the legacy "Tunnel Settings" config everything works perfectly, with EAP-RADIUS on Phase1.

Hi Franco,
After upgrading to 23.7.3, checking the new wireguard logs, saw the following, and IPv6 on Wireguard is not working.

Code Select Expand

/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/ifconfig 'wg1' 'fc00:xyza:abcd:ab01::4:1234/127' alias' returned exit code '1', the output was 'ifconfig: fc00:xyza:abcd:ab01::4:1234/127: bad value (width too large)'

/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/route -q -n add -'-4' '10.1.1.1' -iface 'wg1'' returned exit code '64', the output was 'route: bad keyword: -4 route: usage: route [-46dnqtv] command [[modifiers] args]'

Might be caused by the backend rework, right? Happy to test if needed.

Thanks