Messages

If you look at the status output from my previous post you see that the queues always show zero flows and also the schedulers show either none of a single 0.0.0.0/0 flow, even for IPv6.

For example the low prio inbound rule:

Code Select Expand

sequence: 6
interface: WAN
proto: IP (i'm dual stacked)
source: any
invert source: unchecked
src-port: any
destination: any
invert destination: unchecked
dst-port: 12345
target: low-prio download queue

This is the status output:

Code Select Expand



Limiters:
10000:  10.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
sched 75536 type FIFO flags 0x0 0 buckets 0 active
10001:  40.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
sched 75537 type FIFO flags 0x0 0 buckets 0 active


Queues:
q10004  50 sl. 0 flows (1 buckets) sched 10001 weight 10 lmax 0 pri 0 droptail
q10002  50 sl. 0 flows (1 buckets) sched 10001 weight 100 lmax 0 pri 0 droptail
q10003  50 sl. 0 flows (1 buckets) sched 10000 weight 10 lmax 0 pri 0 droptail
q10001  50 sl. 0 flows (1 buckets) sched 10000 weight 100 lmax 0 pri 0 droptail


Schedulers:
10000:  10.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
sched 10000 type FQ_CODEL flags 0x0 0 buckets 1 active
FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 ECN
   Children flowsets: 10003 10001
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip           0.0.0.0/0             0.0.0.0/0        4     4696  0    0   0
10001:  40.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
sched 10001 type FQ_CODEL flags 0x0 0 buckets 1 active
FQ_CODEL target 5ms interval 100ms quantum 120 limit 120 flows 1024 ECN
   Children flowsets: 10004 10002
  0 ip           0.0.0.0/0             0.0.0.0/0        3      120  0    0   0



I was expecting the four queues to show flow counters not equal zero or even the individual flows.

My configuration consists of two pipes (40MBit down, 10MBit up), four queues (two down, two up, each a pair of normal and low prio traffic with a weigth of 10 (low prio) and 100 (normal prio)), and four rules matching the traffic. All are assigned to the WAN interface, the low prio (6 and 7) are before the normal prio rules (11 and 21) and match on the source and destination port only.

Ok.
I checked by having two downloads, one per queue and checking their speeds.
Status only shows a single line in the last section. I can't access the firewall from here, will post the output when at home.

Thanks!
That's almost exactly what I've configured.
I don't have checked the CoDel or PIE checkboxes in either the queues nor the pipes, still the status output shows fq_codel. Do I have to enable one of those in one of the teo locations?
How should the status output look like?

@Animosity022: can you please document your setup in more detail as I'm trying to replicate the same thing but failed so far, thanks!

For me the upgrade went fine without any problems via GUI.
I'm running the following services:

• IPv4/IPv6 dual stack PPPoE WAN (DSL)
• Internal network is untagged, guest and DMZ tagged on the same Realtek NIC
• DHCPv4 and DHCPv6 server
• Traffic shaper against bufferbloat
• OpenVPN Server
• IKEv2 Client VPN Server
• HAProxy
• Network Time
• Unbound DNS

I get the same error message and disabled the bogon blocking again.

I found the url in rc.update_bogons and it seems to be hosted by OPNsense itself, seems you backend needs the filter too.
Deleting /tmp/bogons/* and rerunning rc.update_bogons leads to the same HTML content.

I've run rc.update_bogons manually twice.
Deleting /usr/local/etc/bogonsv6 doesn't help, the same HTML is in the file after the update has run.

screen output:

No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled

clog system.log output:

Mar 26 19:25:57 firewall root: rc.update_bogons is starting up
Mar 26 19:25:57 firewall root: rc.update_bogons is beginning the update cycle
Mar 26 19:25:57 firewall root: Bogons V4 file downloaded: 77 addresses added.
Mar 26 19:25:57 firewall root: Bogons V4 file downloaded: 27 addresses deleted.
Mar 26 19:25:57 firewall root: Bogons V6 file downloaded but not updating IPv6 bogons table because IPv6 Allow is off
Mar 26 19:25:57 firewall root: rc.update_bogons is ending the update cycle
Mar 26 19:26:43 firewall root: rc.update_bogons is starting up
Mar 26 19:26:43 firewall root: rc.update_bogons is beginning the update cycle
Mar 26 19:26:43 firewall root: Bogons V4 file downloaded: no changes.
Mar 26 19:26:43 firewall root: Bogons V6 file downloaded but not updating IPv6 bogons table because IPv6 Allow is off
Mar 26 19:26:43 firewall root: rc.update_bogons is ending the update cycle

After updating today to 18.1.5 no through-the-firewall connection worked, the error I've found in the log was:

Code Select Expand

Mar 26 18:47:01 firewall opnsense: /usr/local/etc/rc.filter_configure: New alert found: There were error(s) loading the rules: no IP address found for <!DOCTYPE

The number of states also remained at zero.
After disabling my spamhaus.org deny rules which are using a downloaded IP list via an alias, the error still remained.

A reboot didn't solve the issue either.

I then remembered that OPNsense has a checkbox for blocking bogons, after I've disabled it everything worked again.

I've checked /usr/loca/etc/bogons which was fine, but /usr/local/etc/bogonsv6 contained HTML!

I've further found:

Mar 21 03:01:00 firewall root: rc.update_bogons is starting up
Mar 21 03:01:00 firewall root: rc.update_bogons is sleeping for 86 seconds
Mar 21 03:02:26 firewall root: rc.update_bogons is beginning the update cycle
Mar 21 03:02:26 firewall root: Not updating IPv4 bogons (increase table-entries limit)
Mar 21 03:02:26 firewall root: Not saving or updating IPv6 bogons (increase table-entries limit)
Mar 21 03:02:26 firewall root: rc.update_bogons is ending the update cycle

From which URL are the bogons downloaded? Can you implement a safety check which validates the received list?
Thanks, Alex

I followed https://forum.opnsense.org/index.php?topic=6376.0 which fixed the issue but a reboot should fix such an issue as well, so I'm not sure if someone else is also affected.

Sadly not entirely successful for me as OpenVPN Server doesn't start, a reboot didn't solve it either: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)

I remember I had a hard time choosing the correct image when installing OPNsense for the first time myself as usually the CDROM images can be written to USB stick as well which isn't the case here (for whatever reason, FreeBSD?).

As the installation with a USB stick is the #1 method these days I'd suggest renaming the images to at least also include the word 'usb' in addition to 'vga' and 'serial'.

'vga' is a bit misleading too in the days of UEFI.

When I reinstalled by box due to a different SSD last week I struggled with the installation of 17.1.0. It was the day when 17.1.4 was released but the install images didn't exist. The UEFI seems to cause that a different screen output is displayed then documented, there was no choice between installing and live boot, I had to login with an 'installer' user instead.

Thanks Frank!
It only affects certificate chains with intermediate CAs as far as I can tell.
Regarding contributing the github fork/pull-request process should be added to the manual.