Messages

1

23.1 Legacy Series / Re: [feature request] Add emergency reboot fallback

« on: May 26, 2023, 10:09:03 pm »

Reduce your possible causes by removing bits (temporarily) until it works properly and investigate the last removal. Either that, or start with a clean slate and add features until it breaks.

Sure thing. What breaks is monitoring a wireguard interface with suricata. Taking suricata out the equation (at least on the wireguard interface) everything works as it should.

This for now, otherwise we will get more of those and then blocking reboots will be more prominent. Remember, you are asking for a manual failsafe but a lot of expectations and automation will not trigger / know when to trigger it. Worst case on major upgrades you could kill the operating system killing the upgrade taking "too long".

I wasn't thinking of such a sophisticated solution, only sticking a 'reboot' at the end of /usr/local/etc/rc.reboot just in case. Best case it wouldn't even be reached, worst case it would forcefully reboot the router if 'shutdown -or now' doesn't manage for some reason. No accidental reboot due to delay would be involved.

[edit:] it wouldn't help. '/usr/local/etc/rc.freebsd halt' is not able to kill suricata, that's why the whole shutdown process goes sideways. (Suricata on my boxes can only be killed by SIGKILL but not SIGTERM for some reason.)

2

23.1 Legacy Series / Re: Upgraded to OPNsense 23.1.8-Keeps saying "Your device is rebooting"

« on: May 26, 2023, 10:59:43 am »

I suspect the culprit might be suricata (if you are using intrusion detection), that does the same for me lately as well. (see https://forum.opnsense.org/index.php?topic=34205.0)

3

23.1 Legacy Series / [feature request] Add emergency reboot fallback

« on: May 26, 2023, 10:57:40 am »

Since a few minor versions my routers (apu3 and Fujitsu Futro thin clients) are not able to reboot properly from the webgui or after an update. I suspect this might be caused by some faulty suricata-netmap-wireguard interaction (that is giving me trouble sometimes).
The problem is that the shutdown script is able to stop enough services not to be able to log back in or continue to use the router but not enough to actually reboot the router itself. (If i am lucky i can log in to the webgui just to restart sshd to be able to log in through ssh; sshd does not accept my user/password after a failed reboot attempt for some reason unless restarted.)
Logging in through ssh and issuing a 'sudo reboot' successfully reboots the router every time (when it is possible to log in at all). So i would suggest adding a forceful 'reboot' after trying to gracefully shut down services in case it did not work as that would increase resiliency a lot.

4

23.1 Legacy Series / Re: Latest update broke dynamic dns updater

« on: May 12, 2023, 11:17:23 am »

I'm fairly certain that's the configuration required for split-tunnelling, which you would need to bypass the VPN for DDNS updates. This effectively disables the use of --redirect-gateway def1 ... when pushed (which it typically is).

Sure, it was just working differently with OpenVPN 2.4: the routes were added even with 'Don't pull routes' checked.

5

23.1 Legacy Series / Re: Latest update broke dynamic dns updater

« on: May 08, 2023, 04:05:42 pm »

Yes, I think something changed with OpenVPN 2.6. But I'm not sure if it is the intended behaviour or not (to me the current behaviour seems more logical to be honest).

6

23.1 Legacy Series / Re: DNS resolves firewall for wrong subnet

« on: May 08, 2023, 02:01:27 pm »

Hi Sam,

I did face the same problem as yourself in the past. The solution is if you are using unbound to resolve your DNS requests is to use 'access-control-view' records - there might bo something similar for the other DNS servers as well.

Under /usr/local/etc/unbound.opnsense.d create a .conf file (local.conf for example) with something like

Code: [Select]

access-control-view: 192.168.1.1/24 lan

view:
    name: "lan"
    local-data: "fw01 IN 192.168.1.1"
    view-first: yes

Reload unbound and you should be good.

7

23.1 Legacy Series / Re: Latest update broke dynamic dns updater

« on: May 08, 2023, 01:50:48 pm »

Thanks for looking into this Franco! In the meantime I found out that probably OpenVPN was the culprit in my case (at least partly): it was working fine until the 23.1.7 upgrade, then the connection would build up, but the routes were not added to the routing table. So I unchecked the 'Don't pull routes' and 'Don't add/remove routes' switches and all was well until reboot as it seems. Now I have noticed that there was a 0.0.0.0 route added to the routing table (superseding the default route!) which of course redirected all traffic through OpenVPN - the dynamic DNS request among them - but still it is strange that it also overtook the dynamic DNS's WAN interface address.

[edit] So far it seems to be working fine having 'Don't add/remove routes' checked and 'Don't pull routes' unchecked in OpenVPN, but I still need to phisically travel to all the other routers to correct this on them as well so they can interconnect again. :/

8

23.1 Legacy Series / Re: Latest update broke dynamic dns updater

« on: May 08, 2023, 10:11:19 am »

It seems like the new routing subsystem (the one integrating the gateway switching) broke the ability to determine the IP address of an interface if there are other (VPN) interfaces going through them. For me none of ddclient's methods work reliably to find out the IP of my WAN interface (was working fine until now).

I don't know if it is also stemming from this or not but my local Wireguard LAN interface does not come up on the routers, so this change entirely brought down my so-far perfectly working infrastructure interconnected thorugh Wireguard. I am eagerly waiting for a fix, now that I will have to visit all the remote places where the routers reside...

9

22.1 Legacy Series / Re: [solved] Broken OpenVPN policy routing

« on: February 17, 2022, 09:17:35 pm »

Sorry for the long delay, work happened...
I have made a secret-redacted config xml to show my config, and in the same time i figured out it was actually an OpenVPN bug, it was just a coincidence that it's rule came after the ones it broke in the firewall.
v22.1.1 fixed it.

10

22.1 Legacy Series / Re: Broken(?) firewall rule order evaluation w/ policy routing

« on: January 30, 2022, 07:41:04 pm »

It might actually not be the firewall's fault (my rules are in place and are working well for about 5 years now), but some trouble with the automatic gateway selection and/or openvpn.
I have a static route to my cable modem in the routing table through the physical interface the modem is connected to. If i disable the openvpn gateway i can ping the cable modem all right, but if i enable the openvpn gateway (the static route is not set up through it nor am i pulling routes from the openvpn server!), i cannot ping the cable modem, as the router would send the packets to it through the openvpn interface despite the static route, gateway priority and default route setting anyway!

11

22.1 Legacy Series / Re: Broken(?) firewall rule order evaluation w/ policy routing

« on: January 30, 2022, 06:40:21 pm »

what version did you upgrade from?

At first from 21.7.7 to 21.7.8 then to 22.1 back to back.

by what rule did the firewall allow this traffic before adding a new rule?

This traffic i see is mostly my pc (and other devices on the same network segment) trying to connect to the firewall for DNS and NTP (ports 53 and 123). The first example rule did allow this as the [local addresses alias] contains all unicast, multicast and local(host) addresses used on my networks. The strange thing is that the firewall tries to use the vpn gateway in the second example rule to route traffic to itself.

12

22.1 Legacy Series / Re: Can't install on a PCEngine APU4

« on: January 30, 2022, 06:27:29 pm »

No worries.
I don't have much experience yet, but the latest one (v4.15.0.2) seems to work fine, even with IOMMU (amd-v) enabled in BIOS despite the recommended and default setup. (It is needed for passing through the wifi to an OpenWRT vm running under OPNsense to have better hw support - though this should arrive in FreeBSD soon, so need for the OpenWRT vm.)

13

22.1 Legacy Series / Re: Can't install on a PCEngine APU4

« on: January 30, 2022, 03:44:22 pm »

Hey,

I have in fact just upgraded an apu4 from 21.7.1 to 21.7.8 to 22.1 a few hours ago, it went smoothly. (I do have firewalling/routing issues on my production boxes under 22.1 but that's a different question.)

I also had GPT errors at one point, for me it was because of an older linux installation existed on the apu4 at first. (I think if you install OPNsense on the internal SSD, the GPT errors should go away.)

What firmware version ( https://pcengines.github.io/ ) do you have on the apu4? That could make a difference.

14

22.1 Legacy Series / [solved] Broken OpenVPN policy routing

« on: January 30, 2022, 11:59:50 am »

Updating to 22.1 i noticed that my firewall rules stopped working as they should (they were fine up to the 22.1/FreeBSD 13 upgrade).

If i have only a single firewall rule like:

• allow in quick ipv4+6 * [local addresses alias:*] to [local addresses alias:*] through [default] gw

i can access my local machines just fine, but if i add another rule below this like:

• allow in quick ipv4+6 * [local addresses alias:*] to [local addresses alias:*] through [default] gw
• allow in quick ipv4 tcp/udp [interface net:*] to [any:*] through [vpn] gw

then the connection breaks as according to the firewall logs the router tries to route its own [interface address] through the [vpn gw]. I can see blocked outgoing packets on the vpn interface with a destination of the router's own originating interface address. (Say [interface net] is 192.168.1.0/24, [interface address] is 192.168.1.1, then i see blocked outgoing traffic on the vpn interface with destination of 192.168.1.1.)
The system routing table looks fine (though the whole 'Use' column has 'NaN' values), and all connections work from the router itself (which is not firewalled).

Has anyone also experienced this? How should it be fixed without having to have an [allow any to any through default gw] rule, which obviously makes routing and firewalling pointless?

15

21.1 Legacy Series / Re: Freeradius fails to start after update to 21.1.7

« on: June 22, 2021, 09:07:27 pm »

Can you disable LDAP in General or do you really use it?

On this instance i am really using LDAP but on an other one i don't and the result is the same (as @zeitlins also mentioned).

Health audit seems okay for me as well (sorry, i forgot to run it before):

Code: [Select]

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 21.1.7_1 (amd64/LibreSSL) at Tue Jun 22 20:53:07 CEST 2021
>>> Check installed kernel version
Version 21.1.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 21.1.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages:
acme.sh-2.9.0: missing file /var/db/acme/.acme.sh/account.conf.sample
acme.sh-2.9.0: missing file /var/db/acme/.acme.sh/deploy
acme.sh-2.9.0: missing file /var/db/acme/.acme.sh/dnsapi
acme.sh-2.9.0: missing file /var/db/acme/.acme.sh/notify
Checking all packages............. done
>>> Check for core packages consistency
Core package "opnsense" has 67 dependencies to check.
Checking packages: ..................................................................... done
***DONE***
I tried other auth modules, and the really strange thing is that radiusd always errors out loading rlm_pap even if i switch to mschapv2 or tls!

Is it maybe LibreSSL related? I just noticed @zeitlins also uses that flavour.