Messages

1

24.1 Legacy Series / 24.1.8 default route is picky regarding incorrect IP netmask

« on: May 31, 2024, 01:17:37 am »

Just recording my own FUBAR and fix for the community.

After updating to OPNsense 24.1.8-amd64 this morning, the default route would not come up. Trying 'route add default [gw ip]' just gave "route: writing to routing socket: Network is unreachable". 'netstat -rn' listed igb[1..5] but not igb0. The GUI did helpfully provide a clue; /ui/routing/configuration showed the WAN "Status" as yellow with a "mis-configured IP" hint.

Issue was, IP configured for the igb0 WAN interface had a /32 netmask. This was likely mis-configured while thrashing at a NAT configuration during the initial install. (But also, that mis-config has worked since August, 2020.) The fix was simply setting this to /24. The default route then autoloaded.

2

24.1 Legacy Series / Re: 24.1 - DHCP server moves to KEA - implications?

« on: February 04, 2024, 08:25:38 pm »

Just sharing a few items.

First, I'm fairly certain this has been reported previously --
The web tool for KEA apparently produces malformed JSON syntax in kea-dhcp4.conf. At issue is an extra comma after the second to last closing square bracket. As syntax checking is a core function of a web tool, this is hopefully on somebody's ToDo list.

WARN [kea-dhcp4.dhcp4.0x834b11000] DHCP4_CONFIG_SYNTAX_WARNING configuration syntax warning: /usr/local/etc/kea/kea-dhcp4.conf:85.10: Extraneous comma. A piece of configuration may have been omitted.

Second --
If KEA is disabled on the interface, the config file /usr/local/etc/kea/kea-dhcp4.conf goes to 0 bytes. Re-enable gets the file clobbered, re-written with the bad syntax. Turning the service off via the dashboard button doesn't do this, at least. (Maybe this is typical behavior with opnSense and I just haven't noticed; haven't previously had to root around tinkering config files before.)

Third --
I haven't yet gotten KEA to actually put out a lease. The closest is that the daemon seems to prepare to do so. But, the client never receives it. Presumably, the log should next note a client acknowledgment. (Or, I might be mis-remembering the basics of the protocol; it's been two decades since I spent this much time futz'ing around with a dhcpd.)


INFO [kea-dhcp4.leases.0x835789400] DHCP4_LEASE_ADVERT [hwtype=1 18:fd:cb:b0:03:ce], cid=[no info], tid=0x22348769: lease 192.168.50.202 will be advertised

Fourth --
Thanks to all putting in the effort on getting KEA integrated. Frankly, it's a Good Thing these teething issues are getting surfaced now, given the original ISC dhcpd is going to stick around for the time being. For now, I have to fall back. I'll re-try after an update or two are accomplished.

3

24.1 Legacy Series / Re: 24.1 - DHCP server moves to KEA - implications?

« on: February 03, 2024, 09:53:28 pm »

To the original question --
You'll need adjust your ruleset for UDP 67 & 68 on whichever interface(s) you expect to support. Apparently, OPNsense automatically sets up a rule for ISC dhcpd when it's enabled on an interface, but not for KEA dhcpd. (In the logging, the ISC rule shows up with the label "allow access to DHCP server").

On missing features --
OPNSense's web interface for KEA doesn't cover logging options. (Or, if it does, I haven't found it yet.) Remote syslog to a centralized server is kinda key. Mr. Google helpfully finds examples on how to set this up manually for KEA. So, it seems the KEA dhcpd has this capability.

4

20.7 Legacy Series / Log detail for errors could be improved

« on: October 28, 2020, 01:11:17 pm »

Hi, folks.

As a recommendation, consider level-setting system logging details to at least cover anything provided via the gui to the user.

Details:
I just got a pop-up error msg, (Firewall / Aliases / Apply -> "Invalid Argument"). The underlying issue was simply that I'd exceeded the default value for Maximum Table Entries. But, the logging was not helpful to figuring that out. Rambling path to a fix included checking what I'd just changed, deleting the new alias, checking the gui logs (System / Log Files / Backend), checking syslog, checking /var/log/configd.log on the device itself. Nada. Simply, there's no system level logging pertaining to this error. Usually, system level error messages are _more_ verbose than what's presented to the user, not less. (And, definitely not nada.)

The Maximum Table Entries fix was per a suggestion found by search the forum for "invalid argument aliases." (Feature for the discussion forums is awesome, btw.)

On a related matter, there's an inconsistency in what's sent via syslog vs what's reported locally.

Logged messages per System / Log Files / Backend:
2020-10-28T06:51:26   configd.py[27022]   [de4ddfb1-0764-4ead-9f14-106d4da058d5] Show log
2020-10-28T06:50:13   configd.py[27022]   [50395608-ffd5-4d9d-871b-8961eb6e47d5] refresh url table aliases
2020-10-28T06:50:12   configd.py[27022]   [6f3d93c0-e598-4c75-b534-7c26fdbb3fbb] Reloading filter
2020-10-28T06:50:12   configd.py[27022]   OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-10-28T06:50:12   configd.py[27022]   OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-10-28T06:50:12   configd.py[27022]   generate template container OPNsense/Filter
2020-10-28T06:50:11   configd.py[27022]   [e1c3a420-7add-43f2-869e-6788310a512c] generate template OPNsense/Filter

/var/log/configd.log has about the same:
configd.log:Oct 28 06:50:11 opnsense configd.py[27022]: [e1c3a420-7add-43f2-869e-6788310a512c] generate template OPNsense/Filter
configd.log:Oct 28 06:50:12 opnsense configd.py[27022]: generate template container OPNsense/Filter
configd.log:Oct 28 06:50:12 opnsense configd.py[27022]:  OPNsense/Filter generated //usr/local/etc/filter_tables.conf
configd.log:Oct 28 06:50:12 opnsense configd.py[27022]:  OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
configd.log:Oct 28 06:50:12 opnsense configd.py[27022]: [6f3d93c0-e598-4c75-b534-7c26fdbb3fbb] Reloading filter
configd.log:Oct 28 06:50:13 opnsense configd.py[27022]: [50395608-ffd5-4d9d-871b-8961eb6e47d5] refresh url table aliases
configd.log:Oct 28 06:51:26 opnsense configd.py[27022]: [de4ddfb1-0764-4ead-9f14-106d4da058d5] Show log

But, two items are absent per syslog:
user.log:Oct 28 06:50:11 opnsense.example.com configd.py[27022]: [e1c3a420-7add-43f2-869e-6788310a512c] generate template OPNsense/Filter
user.log:Oct 28 06:50:12 opnsense.example.com configd.py[27022]: generate template container OPNsense/Filter
user.log:Oct 28 06:50:12 opnsense.example.com configd.py[27022]: [6f3d93c0-e598-4c75-b534-7c26fdbb3fbb] Reloading filter
user.log:Oct 28 06:50:13 opnsense.example.com configd.py[27022]: [50395608-ffd5-4d9d-871b-8961eb6e47d5] refresh url table aliases
user.log:Oct 28 06:51:26 opnsense.example.com configd.py[27022]: [de4ddfb1-0764-4ead-9f14-106d4da058d5] Show log

NB: In /var/log/configd.log, at least, there are extra, leading spaces in the "message" aspect of the logged records for the two items missing in the syslog'd records. That might be tripping up some log parsing regular expression somewhere?

Regards,

Mandy Baxter

5

20.7 Legacy Series / No filter rule references in syslog data

« on: October 04, 2020, 11:53:09 pm »

Hi. 
How do I get filter rule reference numbers to appear in the syslog data? I expected to see references from `pfctl -vvsr`.  Instead, I'm seeing empty fields in the records ([89104]: 13,,,0,igb0,match,block,in,). Is there a knob, switch, or lever I can hit to get these?

[89104]: 13,,,0,igb0,match,block,in,

Versions    OPNsense 20.7.3-amd64
FreeBSD   12.1-RELEASE-p10-HBSD
OpenSSL   1.1.1g 21 Apr 2020

6

Tutorials and FAQs / Re: Updated Opnsense, now no Internet

« on: September 27, 2020, 06:36:40 pm »

Anth,
Just a guess based on what you're describing, but does your "No Internet" issue pertain to WiFi clients hanging off an AP router?  If so --
https://docs.opnsense.org/manual/nat.html
near the top --
(!) Note
"The NAT rules generated with enabling NAT reflection only include networks directly connected to your Firewall. This means if you have >>> a private network separated from your LAN <<< you need to add this with a manual outbound NAT rule."

To expand this a bit, an internal subnet via an WiFi AP router is a very, very common use case that would need to be addressed via a manual outbound rule for the WAN port. 

So, go to
Firewall -> NAT -> Outbound
Select the radio button for ">>>Hybrid<<< outbound NAT rule generation." Click [Save]. Click [Apply].
Click [+Add] and add a manual rule to cover your WiFi subnet. Click [Save]. Click [Apply].

If this gets your WiFi clients the the InnerTubes, consider setting up a firewall alias for the WiFi subnet(s). Particularly, if you've got more than one such subnet, an alias can help keep things tidy.