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 - dmurphy

#1
Quote from: hina on December 11, 2025, 06:26:17 PMSome extra data points on my current system

Thank you!  Here's my dnsmasq config; I removed the static reservations since they are repetitive and I didn't feel like masking all of the MAC addresses ... that's just pure laziness on my part.

Nothing crazy in here I don't think!

EDIT: Oh, FYI, the hardware is a DEC2752, vanilla standard ...  the internal interfaces are an 802.3ad active-active LAGG across ax0/ax1;  WAN is on igc0.

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
#

rebind-localhost-ok
stop-dns-rebind

port=53053

# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.
interface=lagg0_vlan77,lagg0_vlan99,lagg0,lagg0_vlan91



dhcp-fqdn
domain=home
# This tells dnsmasq that a domain is local and it may answer queries from /etc/hosts
# or DHCP but should never forward queries on that domain to any upstream servers.
local=/home/
local=/dmz/
local=/winhome/
local=/guest/




# On systems which support it, dnsmasq binds the wildcard address,
# even when it is listening on only some interfaces. It then discards
# requests that it shouldn't reply to. This has the advantage of
# working even when interfaces come and go and change address. If you
# want dnsmasq to really bind only the interfaces it is listening on,
# uncomment this option. About the only time you may need this is when
# running another nameserver on the same machine.
bind-interfaces




# Never forward addresses in the non-routed address spaces.
bogus-priv

server=/plex.direct/8.8.8.8
rebind-domain-ok=/plex.direct/

# By  default,  dnsmasq  will  send queries to any of the upstream
# servers it knows about and tries to favour servers to are  known
# to  be  up.  Uncommenting this forces dnsmasq to try each query
# with  each  server  strictly  in  the  order  they   appear   in
# /etc/resolv.conf
strict-order

# Never forward to servers in /etc/resolv.conf
no-resolv






# host entries flushed via dnsmasq_watcher.py [isc] and a dump of the static reservations
addn-hosts=/var/etc/dnsmasq-hosts
addn-hosts=/var/etc/dnsmasq-leases

dns-forward-max=5000
cache-size=10000
local-ttl=1

conf-dir=/usr/local/etc/dnsmasq.conf.d,*.conf

dhcp-range=tag:lagg0_vlan77,192.168.77.50,192.168.77.200,255.255.255.0,86400

domain=dmz,lagg0_vlan77
dhcp-range=tag:lagg0_vlan91,192.168.91.20,192.168.91.50,255.255.255.0,86400

domain=winhome,lagg0_vlan91
dhcp-range=tag:lagg0_vlan99,192.168.99.100,192.168.99.190,255.255.255.0,86400

domain=guest,lagg0_vlan99
dhcp-range=tag:lagg0,192.168.0.100,192.168.0.245,255.255.252.0,86400

domain=home,lagg0
dhcp-range=tag:lagg0,192.168.1.100,192.168.1.250,255.255.252.0,86400

domain=home,lagg0
dhcp-range=tag:lagg0,::,constructor:lagg0,ra-names,ra-stateless,64,86400

domain=home,lagg0
ra-param=lagg0,60,1200

dhcp-range=tag:lagg0_vlan77,::,constructor:lagg0_vlan77,ra-stateless,64,86400

domain=dmz,lagg0_vlan77
ra-param=lagg0_vlan77,60,1200

dhcp-range=tag:lagg0_vlan91,::,constructor:lagg0_vlan91,ra-names,ra-stateless,64,86400

domain=winhome,lagg0_vlan91
ra-param=lagg0_vlan91,60,1200

dhcp-range=tag:lagg0_vlan99,::,constructor:lagg0_vlan99,ra-stateless,64,86400

domain=guest,lagg0_vlan99
ra-param=lagg0_vlan99,60,1200


===== 8< 24 static reservations, all in the same format ... >8 =====
dhcp-host=08:00:20:00:00:00,192.168.0.3,sun-microsystems-forver
===== 8< 24 static reservations, all in the same format ... >8 =====

dhcp-option-force=tag:lagg0_vlan99,3,192.168.99.1
dhcp-option-force=tag:lagg0_vlan99,6,192.168.99.1
dhcp-option-force=tag:lagg0_vlan91,3,192.168.91.1
dhcp-option-force=tag:lagg0_vlan91,6,208.67.222.222,208.67.220.200
dhcp-option-force=tag:lagg0,1,255.255.252.0
dhcp-option-force=tag:lagg0,6,192.168.0.1
dhcp-option-force=tag:lagg0,3,192.168.0.1

# default dns mapped to this server (0.0.0.0)
dhcp-option=6,0.0.0.0


no-ident

Looks like your dnsmasq has a large memory footprint as well - keep an eye on it and see if it continues to grow.

I saw the same post about the dnsmasq 2.92RC3 but didn't have time last night to dig into the patch; seems it's related to parsing some static host files which "shouldn't" be the issue here, but who knows!  Worth checking out.

Thanks so much for digging into this ... thankfully the hourly restart is getting me through but it's certainly not ideal.
#2
Good morning!  Until I can figure this out I setup a cron job to restart the dnsmasq process hourly so the network doesn't fold in on itself. :-)

I've got somewhere around 120 leases or so; it's not extraordinary by any means.

As soon as I'm back at my desk, I'll post my dnsmasq.conf.  Nothing extraordinary or terribly unusual.  I do have DNS listening on port 5353, as I'm using Unbound as the primary DNS.  (Unbound forwards my local zones to dnsmasq) - but very common config.

#3
The restarted process has been running for 12 minutes .. memory size has ballooned to 98MB already (67MB resident) ...

Yikes.

Don't see any errors in the dnsmasq log - just the usual DHCPREQUEST/DHCPACK/RTR-SOLICIT/RTR-ADVERT etc.
#4
For sure having an issue with dnsmasq.  Restarted the process not 24 hours ago, and its memory consumption continues to balloon.

The process has a 9.5gb memory size, 5.4gb resident.

We have some kind of a memory leak.  About to restart the process - when (not if) it crashes my entire network takes a nosedive with no DHCP or local zone DNS service.

Any suggestions or ideas?

Opnsense 25.7.9

edit: Just restarted the process; now the process size is 17MB; resident less than 5MB.  This is a lot more in line with what I'd expect.
#5
Had a similar issue today.

[759718] swap_pager: out of swap space
[759718] swp_pager_getswapspace(7): failed
[760739] pid 88184 (dnsmasq), jid 0, uid 65534, was killed: failed to reclaim memory

I restarted dnsmasq - right now ooks like it's currently consuming > 1G memory.  Surprised it's that large.  Any idea if that footprint for dnsmasq is normal? I just switched over from ISC dhcp yesterday so don't need to induce instability ...

last pid: 63926;  load averages:  0.62,  0.46,  0.40                                            up 9+01:02:06  21:00:08
95 processes:  2 running, 93 sleeping
CPU: 16.7% user,  0.0% nice,  1.0% system,  0.1% interrupt, 82.2% idle
Mem: 453M Active, 1960M Inact, 10M Laundry, 2537M Wired, 104K Buf, 2895M Free
ARC: 1252M Total, 308M MFU, 847M MRU, 26M Anon, 7437K Header, 63M Other
     1077M Compressed, 3074M Uncompressed, 2.86:1 Ratio
Swap: 8192M Total, 338M Used, 7854M Free, 4% Inuse

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 2049 nobody        1  20    0  1194M  1022M select   3   4:23   0.01% dnsmasq
25353 root          5  20    0   789M   535M kqread   0  55:23   0.00% python3.11
20699 unbound       4  20    0   754M   405M kqread   0  16:43   0.04% unbound
32880 root          1  20    0    89M    40M nanslp   2  95:37   0.75% php
38754 root          1  21    0    67M    39M accept   3   0:00   0.00% php-cgi
38980 root          1  24    0    66M    38M accept   1   0:01   0.00% php-cgi
39173 root          1  20    0    63M    36M accept   2   0:01   0.00% php-cgi
34530 root          1  20    0   132M    36M accept   3   0:49   0.00% python3.11
94077 root         12  20    0  1322M    35M uwait    2   1:49   0.00% tailscaled
85867 root          1  20    0    66M    35M accept   1   0:00   0.00% php-cgi
40453 root          1  47    0    60M    34M CPU2     2 484:29  64.90% python3.11
85405 root          1  20    0    61M    33M accept   0   0:00   0.00% php-cgi
85656 root          1  20    0    57M    30M accept   3   0:00   0.00% php-cgi
39215 root          1  66    0    46M    29M nanslp   1   0:00   0.00% python3.11
85460 root          1  26    0    57M    29M accept   2   0:00   0.00% php-cgi
68339 root          1  26    0    70M    28M accept   3   0:01   0.00% php-cgi
69129 root          1  20    0    66M    25M accept   3   0:01   0.00% php-cgi
39250 root          1  29    0    53M    24M accept   3   0:00   0.00% php-cgi
39218 root          1  28    0    53M    24M accept   1   0:00   0.00% php-cgi
38386 root          1  31    0    53M    24M wait     3   0:00   0.00% php-cgi
16645 root          1  20    0    66M    24M accept   2   0:01   0.00% php-cgi
#6
Thank you for the invite!  So far, everything is working great.

There's some inconsistency between the install guide and the actual install (i.e. the firewall alias name, etc.) but nothing that wasn't simple enough to understand.

I echo the above - would be great to have a button to auto-create floating in/out rules rather than doing so manually, but the task really is not difficult.

For others, I also inquired and IPv6 is indeed supported and in the IP lists.  It's obviously clear that there's a lot less malicious traffic on V6, but I still love the idea of blocking it where I can.

One thing that was interesting (for me) was adding logging to the rules.  As they are floating rules, they apply before my interface rules, so I'm seeing lots and lots of blocking going on that I really wasn't seeing previously (as I don't have logging turned on for the default "block in all" rule on my WAN.

Dang is it hostile out there.
#7
I'd be interested in trying the Q-Feeds plugin as well, if there's still room.

Not doing much publicly but to protect my home LAN and some small services.

Thanks!
#8
24.7, 24.10 Legacy Series / Re: 24.7.1 perfect
August 12, 2024, 07:42:44 PM
Quote from: franco on August 11, 2024, 08:37:00 PM
Soon ;) https://github.com/opnsense/core/pull/7749

Finally the world is catching up to Solaris circa 2011... ;-)

(BEs are a thing of absolute glory, for the record.)
#9
24.1, 24.4 Legacy Series / Re: Upgraders beware
February 11, 2024, 03:27:44 AM
Disagree.  I have a half dozen VLANs, a set of LAGGs and no issues.  Upgrade was easy.
#10
Quote from: dmurphy on January 24, 2024, 03:49:52 AM
Are you using the "VGA" or "Serial" version of the OPNsense image to start with?

I had similar issues using the VGA image ... had to use serial, and then I didn't get those same hangs.

I already had a USB key made up for a different box with the VGA image .. didn't think twice about it, but made a tremendous difference.

I wish I had a better suggestion.  The only thing I can consider is maybe to pull the SFPs out of ax0/ax1, and see if it finishes the boot.  Then possibly patch 23.7 to current if that works.

Worth a try?
#11
Are you using the "VGA" or "Serial" version of the OPNsense image to start with?

I had similar issues using the VGA image ... had to use serial, and then I didn't get those same hangs.

I already had a USB key made up for a different box with the VGA image .. didn't think twice about it, but made a tremendous difference.
#12
Replying to myself, but appears I'm back under control.

I was using the vga OPnsense image; that appears to have some bad interactions with the axp driver.  Reloaded with the serial image and so far, so good.  Looks like we're approaching stable!
#13
Hi all -

Have a brand new, out of the box DEC2752, and I'm having big issues with it.

Basically, configuration goes OK right until I try to use the ax0/ax1 interfaces for anything.  Once I enable those interfaces - I have all kinds of odd issues.   The links come up but never pass traffic.  I've tried multiple SFP+ modules - both fiber and copper - to no avail.

To make it worse, not only do the connections not work, but I also end up with serial console port issues.  The console port stops giving me output.  If I then reboot the box, the boot sequence seems OK right until it outputs the IP assignments ... as it's printing the SSH SHA256 fingerprints, the console comes to a full hang.

This is really, really problematic.

I did a full reinstall of OPNsense - both the business and the community versions - to absolutely no avail.

Any ideas?  Is there something I'm missing about these AMD chipsets?

I'm really stuck right now.
#14
Hardware and Performance / Re: Decisio Dec750
January 04, 2024, 03:54:33 AM
I do not believe that to be the case at all.

The SFP+ ports are driven by the AMD network driver (app) and the copper ports are driven by an Intel i210 chip.

No reason they can't be used concurrently.
#15
Upgrade went perfectly well.

Took the opportunity to update my boot drives from 120gb to 250gb SSDs and move from UFS to ZFS.

Popped the old disks out, put the new drives in, installed 23.7, restored my config, and back in business.

Fantastic job.  Only issue I ran into was reconfiguring Tailscale, but that was my fault - I was too lazy to pull the config from the 23.1 boot disks.