Topics

Hi!

Just wanted to mention something I've seen twice now: I'll start a Zenarmor update, only to have it seemingly stall (no connectivity to the router or the web from my PC), forcing me to power down the router and power it up again to restore connectivity.

Today was updating to 1.14.1 - in the past it was whatever the most recent 1.13 build was.

Anyone have any ideas what might be going on? At this point I'm just happy everything came back up, but I'm concerned that one of these times it won't.

Thanks!

[/usr/local/etc/unbound.opnsense.d]

Hello!

Unbound now fails to start when trying to load custom access control views, something that worked well up to this point.

Here's the content from the conf file that I drop in /usr/local/etc/unbound.opnsense.d, formatting as outlined in the unbound docs:

Code Select Expand

access-control-view: 10.0.10.0/24 trusted
access-control-view: 10.0.20.0/24 kids
access-control-view: 10.0.30.0/24 iot
access-control-view: 10.0.40.0/24 dmz
access-control-view: 10.0.50.0/24 cameras

view:
    name: "trusted"
    local-zone: "beaker.ddnsgeek.com" transparent
    local-data: "opnsense.beaker.ddnsgeek.com A 10.0.10.1"
    local-data: "opnsense A 10.0.10.1"
    view-first: yes

view:
    name: "kids"
    local-zone: "beaker.ddnsgeek.com" transparent
    local-data: "opnsense.beaker.ddnsgeek.com A 10.0.20.1"
    local-data: "opnsense A 10.0.20.1"
    view-first: yes

view:
    name: "iot"
    local-zone: "beaker.ddnsgeek.com" transparent
    local-data: "opnsense.beaker.ddnsgeek.com A 10.0.30.1"
    local-data: "opnsense A 10.0.30.1"
    local-zone: "ntp.org" redirect
    local-data: "ntp.org A 10.0.30.1"
    view-first: yes

view:
    name: "dmz"
    local-zone: "beaker.ddnsgeek.com" transparent
    local-data: "opnsense.beaker.ddnsgeek.com A 10.0.40.1"
    local-data: "opnsense A 10.0.40.1"
    view-first: yes

view:
    name: "cameras"
    local-zone: "beaker.ddnsgeek.com" transparent
    local-data: "opnsense.beaker.ddnsgeek.com A 10.0.50.1"
    local-data: "opnsense A 10.0.50.1"
    local-zone: "ntp.org" redirect
    local-data: "ntp.org A 10.0.50.1"
    view-first: yes

Any ideas of why this is failing now would be greatly appreciated!

Thanks!

Hi!

Upgraded to the latest engine (1.13), and I've noticed that Zenarmor's blocking what it calls 'Phishing access'. I'm the user being blocked (has not adversely impacted me from what I can tell, as nothing noticeable has changed), and at least some of it's tied to reddit usage.

Not knowing how it determines what and when to block, how can I tell what it's keying off of to know if they're real or just false positives?

One more thing: the one site I recognize as a tracking site (ojrq.net) - are those considered phishing sites?

Thanks!

Hi everyone,

Running 23.1.7.

I happened to reboot my router this morning after seeing a "fq_codel_new_sched cannot allocate memory" message in the logs, and discovered that I could no longer connect via either the web ui or ssh from vlan01.

Fortunately, I thought to plug a spare machine into igc0 (LAN), thinking that either something had locked me out, or that bringing a different port up might kickstart things, and it did - shortly after I tried to connect via ssh on the LAN port, the web ui and ssh came up and stayed up, including for vlan01 (igc2).

I rebooted a few times to try and catch where it happens - if I act quickly, I can log in from a machine on vlan01 (igc2), and then watch it boot me off, which happens when igc2 goes down after the 'iflib_netmap_config txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048' message.

Note as well that it's just access to the router that's blocked from igc2 - I can access the internet and other things on my network without problem.

Here are logs from dmesg:

Code Select Expand


Dual Console: Video Primary, Serial Secondary
igc1: link state changed to UP
igc2: link state changed to UP
lo0: link state changed to UP
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
pflog0: permanently promiscuous mode enabled
igc2: link state changed to DOWN
vlan0: changing name to 'vlan01'
vlan1: changing name to 'vlan02'
vlan2: changing name to 'vlan03'
vlan3: changing name to 'vlan04'
vlan4: changing name to 'vlan05'
igc1: link state changed to DOWN
igc2: link state changed to UP
vlan05: link state changed to UP
vlan02: link state changed to UP
vlan04: link state changed to UP
vlan03: link state changed to UP
vlan01: link state changed to UP
igc1: link state changed to UP
062.320591 [ 851] iflib_netmap_config       txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
062.707201 [ 851] iflib_netmap_config       txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
igc2: link state changed to DOWN
vlan05: link state changed to DOWN
vlan02: link state changed to DOWN
vlan04: link state changed to DOWN
vlan03: link state changed to DOWN
vlan01: link state changed to DOWN
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched FQ_CODEL loaded
load_dn_sched dn_sched FQ_PIE loaded
load_dn_aqm dn_aqm CODEL loaded
load_dn_aqm dn_aqm PIE loaded
igc2: link state changed to UP
vlan05: link state changed to UP
vlan02: link state changed to UP
vlan04: link state changed to UP
vlan03: link state changed to UP
vlan01: link state changed to UP
igc0: link state changed to UP


I double-checked my configuration history, and I can't see any change I've made that would cause this.

Any advice would be greatly appreciated!

Thanks!

Hi all!

I happened to notice that my swap usage was higher than normal (system's been up for 5 days now) - i.e. normally it's zero, or nearly so, but tonight I noticed it was around 1.7 - 2gb (sits on an 8gb card).

Checked top, and Unbound was using nearly 8gb (size - can't remember what res was), which also seemed really unusual. Given I've never seen things grow in this way, I can't help but wonder if perhaps something wasn't quite right?

I restarted the service, noted the initial size (1769mb size, 1378mb res), and figure I'll watch over the coming days to see if things grow again.

Is there a rational reason why unbound would grow like this?

Attached a pic of memory over the past 60 hours if that would help.

Thanks!

Hi all!

Upgraded to 23.1.2 earlier today, and I just noticed this via dmesg (never seen it before):

arp: packet with unknown hardware format 0x06 received on vlan01
arp: packet with unknown hardware format 0x06 received on vlan01

Any idea what might be causing this? I really didn't find any posts with the exact same verbiage, so I've no idea what's going on.

Thanks!

Not an issue, just something that's neat to me - it's nice to tell that unbound's doing it's job for frequently visited sites by comparing the stats found beneath 'Top passed domains' to what my DoT provider has for those sites (no surprise that unbound's stats are 10-15 times those of my DoT provider).

Thanks again for the reporting and for optimizing things - I'm having quite a bit of fun! :)

Hi all!

Noticed lately that attempts to resolve the name of my opnsense box take 30 seconds or so, so I thought I'd try pinging the name while letting the browser spin, trying to open the page.

Turns out that, rather than resolving it to 10.0.10.1 (vlan 10, where my pc sits), it somehow resolved to 10.0.40.1 (vlan 40 - dmz), where I disallow access to the web gui. _Eventually_ things must resolve, because navigation succeeds, and I'm in the gui.

Is this an issue because my PC has access to every vlan? `ipconfig` confirms the correct gateway ip (10.0.10.1) - why on earth would unbound return the router's address from a different vlan than the one I participate in?

Thanks!

Hi all,

Running 23.1_6, I've noticed that coming up from a reboot, the web gui doesn't always start cleanly - for example, the gui's usable, but says that it's stopped in the service list, and the log shows the following:

2023-02-07T21:30:00-05:00   Error   lighttpd   (gw_backend.c.360) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1 0 /tmp/php-fastcgi.socket   
2023-02-07T21:29:57-05:00   Error   lighttpd   (gw_backend.c.283) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-1: Connection refused   
2023-02-07T21:29:52-05:00   Error   lighttpd   (gw_backend.c.360) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1 0 /tmp/php-fastcgi.socket   
2023-02-07T21:29:49-05:00   Error   lighttpd   (gw_backend.c.283) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-1: Connection refused

When this happens, I cannot get things to restart cleanly through the ui, and if I try too many times (suppose I'm paying for clicking the restart button one too many times), things die and I get a 503. Fortunately, I'm able to ssh in, find an kill lighttpd, and then restart. Even then, though, it's a crapshoot as to whether it will restart cleanly.

Thoughts?

Thanks!

Hi all,

Just a quick observation - I've had unbound logging reporting (like the graphs and table btw! Table in particular helped me track down a config issue) running, and it seems like, over time (around 36 hours now) it's grabbing more of the cpu more frequently (python 3.9 process).

Is this expected as the dataset grows? Is this going to become more noticeable, or (36 hours on) have I hit a steady state?

Thanks!

Hi all,

Routing still works, can access internet and everything on my network fine, but the gui's inaccessible. Combine that with the fact that I have ssh disabled (didn't think I'd need it for a while), and I'm pretty much left without a means to get in.

At this point, I'll just cycle power and see what happens - I'm beginning to wonder, though, if I ought roll back to v22 for a bit. Is there a way to roll back that'll encompass everything, or would I be better starting from scratch?

Thanks!

Hello,

Apologies if this has already been covered, but I noticed two errors while upgrading to the latest Zenarmor:

Code Select Expand

Script action stderr returned "b'x temp/\nx temp/.snap/\nx temp/0_dns_54.ipdr\nx temp/0_tls_14.ipdr\nx temp/0_http_47.ipdr\nx temp/0_conn_15.ipdr\nx temp/0_alert_3.ipdr\nx temp/0_http_46.ipdr.ready\nx temp/0_conn_14.ipdr.ready'"

Code Select Expand

Script action stderr returned "b'a temp\na temp/.snap\na temp/0_dns_54.ipdr\na temp/0_tls_14.ipdr\na temp/0_http_47.ipdr\na temp/0_conn_15.ipdr\na temp/0_alert_3.ipdr\na temp/0_http_46.ipdr.ready\na temp/0_conn_14.ipdr.ready'"

If I hadn't noticed these in the backend logs, I never would've noticed, as everything seems to be working fine.

Does anyone know if these are of any concern?

Thanks in advance!
Bob