Messages

1

General Discussion / Netdisco LLDP discovery

« on: May 25, 2024, 04:37:37 am »

This is kind of a longshot...

I use netdisco to keep track of layer 2 topology, and most of its data comes from lldp, which it accesses via SNMP downloading the results of lldp discovery of neighbors.

lldp is available for OPNsense (and I'm running it).  OPNsense sees its neighbors.

Netdisco does not see neighbors, or connected devices, and I think it is because the snmp implementation is not providing data on macs on ports, neighbors from lldp, etc.  Emphasis on "think", a brief look through snmpwalk didn't see that kind of data.

Anyone been down this path - is this a restriction in the snmp implementation?  Some mibs not turned on (and can they be)?  Something in netdisco?

It's a minor nit -- OPNsense is not connected to much as it is on the edge. But I was hoping for consistency.

Linwood

2

Hardware and Performance / Wifi USB adapter Linksys AC1200 WUSB6300 V2

« on: April 05, 2024, 06:44:29 pm »

I screwed up.  Due to a move going to be without internet for a week or so, and on a whim stopped and picked up a Wifi USB adapter thinking I could just plug it in and connect to my phone's hotspot.

I got the above mentioned device, plugged it in and... doesn't work.

On searching it looks like FreeBSD will add support in 14, not in the current version.

But I also see this page:

https://man.freebsd.org/cgi/man.cgi?query=rtwn_usb&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html

That seems to indicate since 12 it could be added.  I'm hesitant to screw around with kernel changes in my (working, happy, stable) OPNsense system, especially since it is the only place I use FreeBSD.

Did I just simply screw up and should throw this ouit, or is it safe to add drivers as that link indicates?

Linwood

3

23.7 Legacy Series / Where is this DNS resolution IP coming from?

« on: November 18, 2023, 10:41:39 pm »

This seems like a simple question but I am baffled.

I am running unbound and dns and dhcp4, but not adguard.

I created a new esp32 device, it probably pulled a dhcp address at some point, but I gave it a static address of 192.168.130.53.

Now OPNsense as a DNS server is giving out a pair of addresses for its name:

Code: [Select]

Name:    frontdoorpanel.xxxxx.com
Addresses:  192.168.130.53
          192.168.130.72

Simple (I think), the DHCP is hanging around.  But it's not there, even with show expired (I am not certain it ever pulled a DHCP address, that's supposition, usually these things do and I just delete them).

I have looked in the Unbound overrides and only the .53 address is there.  I have looked in DHCP leases and DHCP reservations, it is not in either place. 

There are no unbound aliases defined.

The above is nslookup, so it's not some broadcast mDNS answer from a device.

I asked unbound to log queries and replies and it does so but just basic info, at least I do not see where the detail may be. But showing details in nslookup shows it responding with both.

It's really acting like there is a unbound override in there (or a dhcp4 address), but ... it's not showing up.

I have restarted dhcp4, unbound, and rebooted the OPNsense firewall (in that order) and nothing changes.

I don't know if there is a text file where overrides are stored -- is there?   That I could search?

Where else could this value be?  What could I be missing?  This looks so simple.

Opnsense 23.7.8 on FreeBSD 13.2-Release-p5 on Intel.

Any advice?   It's not actually causing much of a problem, just a network monitoring device (zabbix) is complaining about the DNS vs IP mismatch since it expects only the .53.

Linwood

4

23.7 Legacy Series / Re: Removing Interface and "opt#" numbers

« on: October 09, 2023, 02:54:24 pm »

Perfect, thank you.  I've been burned by ASA's when you change interfaces and suddenly lines of config disappear due to removing and re-adding an interface name (I realize this is different) that was just a bit paranoid.

5

23.7 Legacy Series / Removing Interface and "opt#" numbers

« on: October 09, 2023, 12:47:50 am »

I think this is a silly question but prefer not to make a mess.

I had a bunch of VLAN's, assigned to opt1, opt2, opt3, opt4, etc

I no longer use the one assigned to opt2.  I've disabled it which takes care of most important stuff, but I'd like to just remove it.

I don't know what happens when I do relative to the opt numbers, and if that matters for any configuration purpose.  Nothing currently refers to the interface name (e.g. this is "Automation"), but I have no idea how it all connects under the covers.

If I just delete it from the assignments page does everything else stay the same?

(On 23.7.5 on FreeBSD amd64)

6

23.1 Legacy Series / Re: Unbound restarts, per monit, several times a day (actually more)

« on: July 07, 2023, 04:28:07 pm »

No one?

Does Unbound not restart for others?

7

23.1 Legacy Series / Re: OpenVPN all config for client disappeared after latest upgrade

« on: July 04, 2023, 06:01:26 pm »

I'm kind of a novice at this but my OpenVPN configuration still works after upgrading from 22 to 23.

8

23.1 Legacy Series / Re: zabbix how to help

« on: July 02, 2023, 05:56:34 pm »

As a long term zabbix fan I would suggest that installing zabbix JUST for OPNsense may not be worth the effort.  Monit may be a better alerting solution.  Zabbix is great if you want to monitor a heterogeneous network with a lot of separate devices and get consistent monitoring and alerting.  It's not that the zabbix server is hard to use, exactly, just a a fair amount of work and setup to do for monitoring one device.

If I've misread your intent my apologies.

9

23.1 Legacy Series / Re: Unbound restarts, per monit, several times a day (actually more)

« on: July 02, 2023, 03:38:48 pm »

I decided to see how often it was restarting before since I saw the logs went back quite far.  The short answer is not at all really.  On 5/2 there are a few restarts but that is when I apparently upgraded some items (notice unbound goes from 1.17.0 to 1.17.1) then once on 5/10 (maybe power failure?) then not again until I did the upgrade, which i did on 6/28 and it started the many restarts per day (I only show the first few but they continue each day to present):

Code: [Select]

root@OPNsense:/etc # grep "start of service" /var/log/resolver/resolver_2023*
/var/log/resolver/resolver_20230214.log:<30>1 2023-02-14T20:24:24-05:00 OPNsense.leferguson.com unbound 14728 - [meta sequenceId="108"] [14728:0] info: start of service (unbound 1.17.0).
/var/log/resolver/resolver_20230502.log:<30>1 2023-05-02T11:16:51-04:00 OPNsense.leferguson.com unbound 4021 - [meta sequenceId="5"] [4021:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230502.log:<30>1 2023-05-02T11:17:45-04:00 OPNsense.leferguson.com unbound 87509 - [meta sequenceId="6"] [87509:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230502.log:<30>1 2023-05-02T11:17:55-04:00 OPNsense.leferguson.com unbound 99213 - [meta sequenceId="61"] [99213:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230510.log:<30>1 2023-05-10T19:00:22-04:00 OPNsense.leferguson.com unbound 53262 - [meta sequenceId="99"] [53262:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230628.log:<30>1 2023-06-28T01:43:47-04:00 OPNsense.leferguson.com unbound 69128 - [meta sequenceId="118"] [69128:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230628.log:<30>1 2023-06-28T01:44:54-04:00 OPNsense.leferguson.com unbound 22 - [meta sequenceId="179"] [22:0] info: start of service (unbound 1.17.1).
/var/log/resolver/resolver_20230628.log:<30>1 2023-06-28T02:08:53-04:00 OPNsense.leferguson.com unbound 13803 - [meta sequenceId="72"] [13803:0] info: start of service (unbound 1.17.1).


10

23.1 Legacy Series / Unbound restarts, per monit, several times a day (actually more)

« on: July 02, 2023, 03:34:32 pm »

I recently upgraded from 23.1.11 from 22.mumble, and everything seems to work except that unbound seems to stop multiple times a day.

I say "seems" as it is monit reporting it.  It is configured as in the attached screen shots. This worked in the earlier version in that it would detect the service stopped, would restart it, but rarely gave any such indication.

Now multiple times a day I get a restarted indication.

I found the following in the log, notice the service started at 5:10 then almost to the second an hour later it shows stopped.  I can see no errors.

Code: [Select]

<30>1 2023-07-02T05:10:27-04:00 OPNsense.leferguson.com unbound 17627 - [meta sequenceId="55"] [17627:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T06:10:25-04:00 OPNsense.leferguson.com unbound 17627 - [meta sequenceId="1"] [17627:0] info: service stopped (unbound 1.17.1).
<30>1 2023-07-02T06:10:25-04:00 OPNsense.leferguson.com unbound 17627 - [meta sequenceId="2"] [17627:0] info: server stats for thread 0: 494 queries, 357 answers from cache, 137 recursions, 106 prefetch, 0 rejected by ip ratelimiting
<30>1 2023-07-02T06:10:25-04:00 OPNsense.leferguson.com unbound 17627 - [meta sequenceId="3"] [17627:0] info: server stats for thread 0: requestlist max 2 avg 0.168724 exceeded 0 jostled 0

It almost makes me wonder if unbound is automatically restarting and monit is only fast enough to see it some times.  There are a LOT of restarts, here's just todays:

Code: [Select]

root@OPNsense:/var/log # cat /var/log/resolver/resolver_20230702.log | grep "start of service"
<30>1 2023-07-02T00:31:16-04:00 OPNsense.leferguson.com unbound 99629 - [meta sequenceId="58"] [99629:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T00:38:15-04:00 OPNsense.leferguson.com unbound 57575 - [meta sequenceId="54"] [57575:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T01:38:15-04:00 OPNsense.leferguson.com unbound 32669 - [meta sequenceId="60"] [32669:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T01:47:40-04:00 OPNsense.leferguson.com unbound 95744 - [meta sequenceId="55"] [95744:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T02:47:40-04:00 OPNsense.leferguson.com unbound 46168 - [meta sequenceId="60"] [46168:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T02:54:21-04:00 OPNsense.leferguson.com unbound 94883 - [meta sequenceId="54"] [94883:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T03:54:22-04:00 OPNsense.leferguson.com unbound 26459 - [meta sequenceId="59"] [26459:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T03:59:17-04:00 OPNsense.leferguson.com unbound 89082 - [meta sequenceId="51"] [89082:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T03:59:24-04:00 OPNsense.leferguson.com unbound 22148 - [meta sequenceId="86"] [22148:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T04:59:18-04:00 OPNsense.leferguson.com unbound 59131 - [meta sequenceId="60"] [59131:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T05:10:27-04:00 OPNsense.leferguson.com unbound 17627 - [meta sequenceId="55"] [17627:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T06:10:27-04:00 OPNsense.leferguson.com unbound 52214 - [meta sequenceId="59"] [52214:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T06:10:33-04:00 OPNsense.leferguson.com unbound 90178 - [meta sequenceId="97"] [90178:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T06:13:56-04:00 OPNsense.leferguson.com unbound 75696 - [meta sequenceId="54"] [75696:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T07:13:56-04:00 OPNsense.leferguson.com unbound 34947 - [meta sequenceId="62"] [34947:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T07:22:13-04:00 OPNsense.leferguson.com unbound 63457 - [meta sequenceId="57"] [63457:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T08:22:12-04:00 OPNsense.leferguson.com unbound 23765 - [meta sequenceId="62"] [23765:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T08:31:07-04:00 OPNsense.leferguson.com unbound 76284 - [meta sequenceId="57"] [76284:0] info: start of service (unbound 1.17.1).
<30>1 2023-07-02T09:31:07-04:00 OPNsense.leferguson.com unbound 98578 - [meta sequenceId="63"] [98578:0] info: start of service (unbound 1.17.1).


It appears up often enough to work, but what is going on?   I can't see anything in the log that indicates a reason for it to have stopped (or started in the non-monit detected cases).

I am unsure where I can look, the only thing I changed was the upgrade.

Linwood

11

22.7 Legacy Series / Re: IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

« on: January 04, 2023, 02:11:13 am »

OK, this is definitely OPNsense's fault.

I set up a capture and just left it running until I got another renewal of the bogus address.



This is a somewhat redacted form, but you can see the linux box doing a renewal request, followed by OPNsense responding.  The renewal request has the correct address with "be60" but the response has BOTH the correct "be60" but also contains the incorrect "be61" that does not have the right VLAN prefix (in fact be61 is no longer valid for any interface, and it should know that).

Yet that address is not on the dhcp6 leases page anywhere, and in browsing around on disk I have yet to find it either.

How can I clean OPNsense of a bad lease that it keeps forcing back on the client?

12

22.7 Legacy Series / Re: IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

« on: January 03, 2023, 05:13:55 pm »

I can't find anything that looks like that, did a "find / -name dh*6*".  Running ubuntu 20.04.5.

I think systemd-networkd is doing it there, but /run/systemd/netif/leases is empty as well (though ../links has the interace information such as DNS server from DHCP).   I found notes saying they should be in the leases folder, but it's empty.

That's also consistent with netplan's answer:

netplan ip leases eth0
No lease found for interface 'eth0': [Errno 2] No such file or directory: '/run/systemd/netif/leases/2'


I can't recall if I have rebooted that server, trying that now in case the leases are more ephemeral.

I'm thinking if that doesn't do it, I need to sniff and see for sure that the linux dhcp6 client is requesting the address and that OPNsense is granting it, as opposed to Linux just perpetuating it on its own.

13

22.7 Legacy Series / Re: IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

« on: January 02, 2023, 09:23:54 pm »

And just like that an hour later it removed the bad address.   I'm not making any configuration changes anywhere in these times, it just comes and goes and goes and comes.

Code: [Select]

Jan  2 13:01:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 14:57:20 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 14:59:40 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.


14

22.7 Legacy Series / Re: IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

« on: January 02, 2023, 08:16:44 pm »

Well, another 4 ours later or so, the bad address came back.  I really have no idea where it is coming from:

Code: [Select]

Jan  2 11:09:50 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 12:04:36 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:01:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200



15

22.7 Legacy Series / IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

« on: January 02, 2023, 04:04:12 pm »

I have a self inflicted problem I cannot seem to resolve.  Or it may have timed out now, but not sure.

OPNSense 22.7.10 on Comcast, /60 prefix delegation.

I originally set up multiple VLAN's with different prefix ID's, and for reasons unrelated (and probably wrong) I then changed some.  So my LAN ID went from 1 to 0, and at present I have no other VLAN's set up for ipv6.

I am using track interface (WAN), and not setting any specific DHCPv6 attributes, the DHCPv6 relay is not enabled. The LAN interface gets a proper address and is pingable from outside.   The WAN interface is set to DHCPv6, hint 60, ipv4 connectivity not checked, VLAN priority not checked.

A linux box on the VLAN  is getting a correct address of 2601:xxx:xxxx:be60::11e9/128.  Note the "be60" the 0 is the prefix ID.  All good.

However, that linux box ALSO is getting an address with "be61", from (I assume) the period when I had the prefix ID = 1 on LAN.

It seems to come and go every few hours.  When it gets the "be61" address it stops working properly, as it's being used as a source address and it is no longer routable.  If I delete that address (ip -6 addr del) that linux box works again, all good.  In an hour or three it comes back.

The Services / DHCPv6 / Leases shows the bad address, but there's no delete option.  If I restart that service it vanishes from the screen, but again comes back later.  If I enable configuration of DHCPv6 options on LAN I see no place to configure leases either (I then put it back unchanged).  Browsing around in /etc doesn't show any config or leases file.

I'm hoping if I just let things sit for a day it will go away (it may have actually done so, it's now been 4 hours). But what I would like to understand is where these reside, and how I can delete/remove/change them if this happens again.

How do you delete a bad lease with the wrong prefix ID so they don't come back?

Here's the log from the linux box showing activity over night if it is helpful.  Notice the be61's coming back.  Note  I had other systems also screwed up by this one was easiest to debug (and also an NMS system so it immediate threw alarms when it got the bad address).

Linwood

Code: [Select]

Jan  2 00:37:08 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 01:35:34 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 02:33:02 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 02:33:02 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be60::11e9 on eth0.*.
Jan  2 02:33:02 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 02:37:33 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 03:27:58 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 04:27:11 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 04:27:11 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 04:29:57 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be60::11e9 on eth0.
Jan  2 05:21:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 05:21:55 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be60::11e9 on eth0.*.
Jan  2 05:21:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 05:29:10 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 06:18:23 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 07:16:16 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 07:20:21 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 08:14:08 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 09:13:52 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200