Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - JasMan

#16
That sounds good!
I will try and report the result.
#17
Thank you for your reply. That was also my first thougt.

Therefore, I checked the NTP time by requesting an update via "w32tm /stripchart /computer:OPNSENSE".
The responsed time was fine.
And I also tried to login as root, which has no TOTP configured. Same error.
#18
Hey,

I rebooted my OPNsense 24.1.10_3 after I've moved it to another location.
Now I can't login anymore via SSH and WebGUI (Wrong username or password). I tried it with three different users with and without TOTP and also with different clients. The times on the clients and on OPNsense are correct.

Next strange thing: the internal network and services are working fine (NTP, DHCP, DNS). But I've no Internet access. Tracerout dies after the default gateway (OPNsense). All DNS queries for external names run into a SERVER_FAIL.
The WAN interface is up and reachable via ICMP.

Any ideas? I guess I need to reinstall OPNsense because I can't login. Or is there another way to import the latest backup?
#19
Maybe the listening interface is not up when Unbound tries to start?

Have you checked the system logs?
#20
Check if Unbound resolves to the correct IP address: nslookup [OPNsense FQDN] [OPNsense MGMT Interface IP]
If yes, than the PiHole seems to have an (static) record which resolves to the wrong IP address.

I've enabled the "Do not register system A/AAAA records" under Services: Unbound DNS: General, and created a static record in Unbound for my OPNsense.

If "Do not register system A/AAAA records" is disabled, Unbound registers the configured name under "System: Settings: General" for all listening interfaces.

#21
Remove the "Quick" setting in the automation rule. Then the rule will match last.

Or create an Internet alias for all non-privat addresses and add it as destination in the rule:

IPv4

!192.0.2.0/24
!198.51.100.0/24
!203.0.113.0/24
!169.254.0.0/16
!10.0.0.0/8
!172.16.0.0/12
!192.168.0.0/16
!0.0.0.0/8
!100.64.0.0/10
!127.0.0.0/8
!192.0.0.0/24
!192.88.99.0/24
!198.18.0.0/15
!233.252.0.0/24
!224.0.0.0/4
!240.0.0.0/4
0.0.0.0/0

IPv6

!2001:db8::/32
!::/0
!::/128
!::1/128
!::ffff:0:0/96
!::ffff:0:0:0/96
!64:ff9b::/96
!64:ff9b:1::/48
!100::/64
!2001:0000::/32
!2001:20::/28
!2002::/16
!fc00::/7
!fe80::/64
2000::/3
#22
Same issue.

It seems that whitelisting of a wildcard domain from the OISD list doesn't work.

I added different domains from the OISD list (https://big.oisd.nl/domainswild) to the whitelist as example. When I try to resolve them I'm still getting 0.0.0.0 for A records, and an empty response for CNAMEs from the server.

The Unbound Report shows the A query as blocked, but the button at the end of the line says "Block Domain" instead of "Whitelist Domain".
Whitelisted CNAME queries are not shown in the report.

Bug? Expected behaviour?


#23
No one?  :-\
#24
YAY! It's working again!  :)

WG traffic is inspected and blocked as before the OPNsense update. Thanks a lot for your support!
#25
Quote from: wirefall on August 31, 2023, 04:07:38 PM
Any news regarding this issue? I also have the same here, no wireguard traffic in Zenarmour, engine stops with same alert "Cannot validate interface:..." so I always have to restart...

Opnsense 23.7.3
os-wireguard 2.0_2
os-sensei 1.14.5

Thanks a lot!

If you want to use Zenarmor with WG, you've to install Wireguard Go instead of Wireguard (remove os-wireguard, install os-wireguard-go (System: Firmware -> Packages))

Zenarmor is currently not able to detect the WG Kernel Module interfaces. I guess this will resolve your "Cannot validate interface" issue.

The issue that we have is, that Zenarmor is able to detect the WG interfaces, but it can't inspect the traffic due to the missing TUN  patch.
#26
Quote from: franco on August 26, 2023, 08:47:02 PM
Who should I talk to instead?  8)

I guessed it was a question for another dev. Because I understood your presumption, but I don't know how to check if the missing patch is the reason for the issue.

Anyway, thank you guys for taking care of it.
#27
Yep, with the emulated mode the downtime is near zero, and no errors appear in the log ( found no suitable IPv4 address )
#28
Uhm, is this a question to us users? I hope not  ;D

Can we test it or provide logs to check this?
#29
Hi mb.

IPv6 is enabled for all interfaces in tracking mode.


#30
Hi,

Since some month I noticed that my OPNsense needs a long time until all services are fully up after a complete reboot (up to 10 minutes).
The other day I noticed the same behaviour when I restart the Zenarmor engine.

Today I found some time to digging into this.

When I restart the Zenarmor engine several services like Unbound and NTP stop and start several times immediatly after Zenarmor is up again.
The log shows a lot of the following errors for this range of time:

/usr/local/etc/rc.linkup: dhcpd_dhcp4_configure() found no suitable IPv4 address on INTERFACE_NAME

When all calmed down, everything works fine.

I played arround and found out, that this issue is solved as soon as I choose the emulated netmap driver for Zenarmor.
The interfaces of my system are all Intel I211.

Is this an expected behaviour when the hardware/driver doesn't support the native netmap driver? Or did I configured something wrong?


Jas Man