Messages

Thanks for the link - that might help in some cases. In mine it was def. caused by network card hw offload. Either this setting was lost while upgrade or the new version now needs it.

Meanwhile I also upgraded my main OPNFirewall (there hw offload was already disabled) and both are working without any issues including unbound stats and report graphs on.
I like the new graph and will now also use unbound for visualizing adblocks etc. for this (I used a dockerized adguard before).

Sure I should read the question more careful :)

Code Select Expand

999.000231 [4026] netmap_transmit           igb1 drop mbuf that needs checksum offload

disabled hw offload - now all back to normal.

nothing really indicating an error.

surricated start until stop (after reaching 100% CPU for a while):

Code Select Expand

<173>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="1"] [100285] <Notice> -- This is Suricata version 6.0.9 RELEASE running in SYSTEM mode
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="2"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol sip enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="3"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol rfb enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="4"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol mqtt enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="5"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol rdp enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="6"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol http2 enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 51681 - [meta sequenceId="7"] [100285] <Warning> -- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol http2 enable status not set, so enabling by default. This behavior will change in Suricata 7, so please update your config. See ticket #4744 for more details.
<172>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="8"] [100317] <Warning> -- [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded!
<173>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="9"] [100351] <Notice> -- opened netmap:igb1/R from igb1: 0x8066f4000
<173>1 2023-02-05T11:34:05+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="10"] [100351] <Notice> -- opened netmap:igb1^ from igb1^: 0x8066f4300
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="11"] [100368] <Notice> -- opened netmap:igb1^ from igb1^: 0x8310f4000
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="1"] [100368] <Notice> -- opened netmap:igb1/T from igb1: 0x8310f4300
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="2"] [100374] <Notice> -- opened netmap:igb3/R from igb3: 0x85c0f4000
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="3"] [100374] <Notice> -- opened netmap:igb3^ from igb3^: 0x85c0f4300
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="4"] [100383] <Notice> -- opened netmap:igb3^ from igb3^: 0x886af4000
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="5"] [100383] <Notice> -- opened netmap:igb3/T from igb3: 0x886af4300
<173>1 2023-02-05T11:34:06+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="6"] [100317] <Notice> -- all 4 packet processing threads, 4 management threads initialized, engine started.
<173>1 2023-02-05T11:35:13+01:00 OPNsense-Two.dmz.ok-edv.de suricata 70881 - [meta sequenceId="1"] [100317] <Notice> -- Signal Received.  Stopping engine.


in unbound I as well do not see any issues. If there are any logs to analyse high CPU let me know. Somehow it seems like surricata triggers the issues. I would assume extrem high DNS request if unbound is going crazy as well - but not able to see stats any more after it is on high load.
attached normal situation (IDS off) and unbound stats via GUI under load (empty)

If any other logs would be helpful let me know.

For me surricata causes 100% on surricata and unbound as well after upgrade to 23.1. This even wo any rule activated
https://forum.opnsense.org/index.php?topic=32322.0

if there are any tipps to troubleshoot the behaviour it would be great.

Hello,

just did the update from latest 22.7 to 23.1 and was wondering about WAN gateways showing offline and then I spotted 100% load on CPU caused by unbound and surricata.
Restarting unbound did not help but disabling surricata solves the issue immediately.
If then surricata is enabled again it seems like working but maybe after 10-30s CPU goes up again. currently 100% reproducable.

OPNSens 23.1_6 amd
os-etpro-telemetry (installed)   1.6_1

Any tipp how to troubleshoot?
Note: this is on my backup OPNsense with currently no traffic. Live 5-10% surricata was normal but not 100% and causing unbound to go crazy as well.

surricata enabled:

Code Select Expand

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
15989 unbound       4  52    0    91M    53M kqread   2   1:01 198.03% unbound
31733 root          9  20    0  3093M   341M nanslp   2   0:40  86.33% suricata

normal load surricate disabled:

Code Select Expand

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
80557 root          1  23    0    60M    33M select   1   0:00   0.74% php-cgi
47553 root          1  20    0    57M    37M accept   3   0:01   0.32% php-cgi
  273 root          2  52    0   109M    62M accept   3   0:17   0.20% python3.9

try without any ids rules enabled - still 100% but less on unbound:

Code Select Expand

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
70580 unbound       2  21    0    91M    54M uwait    1   1:43  99.97% unbound
79961 root          9  20    0  2821M   100M nanslp   3   1:39  95.72% suricata
32905 root          1  20    0    14M  4220K CPU0     0   0:01   0.02% top

[Gruppe]

Supi Danke - das wars tatsächlich.
Ich hatte eine Regel drin die LAN traffic auf meine WAN GW Gruppe leitet.
Wenn ich die Regel abschalte geht's oder eben eine Regel die vorher ins richtige GW umleitet.

Die die Idee, die ich da wohl mal hatte, war eine Verteilung zwischen den beiden WAN GWs. Bzw ein Wechsel des default GW wenn das aktive ausfällt. Jetzt frag ich mich war die Idee prinzipiell richtig oder eher auf dem Holzweg...

Gibt es hier eigentlich danke zu verteilen ala Thumbsup oder was auch immer - echt  klasse, schnelle Hilfe hier.

[8]

Moin,

ich steh mal wieder auf dem Schlauch :( Ich muss wohl noch ne Menge lernen :)

Gewünschter trace aus dem LAN
Host -> 192.168.0.222 -> 192.168.1.2 (OPNSense) -> 192.168.89.1 -> 192.168.59.1
nicht gewünscht
Host -> 192.168.0.222 -> 192.168.1.2 (OPNSense) -> 192.168.88.1 -> * *

Von einem Windows host:

Routenverfolgung zu 192.168.59.1 über maximal 30 Hops
  1    <1 ms    <1 ms    <1 ms  192.168.0.222
  2    <1 ms    <1 ms    <1 ms  192.168.1.2
  3     1 ms     7 ms     4 ms  192.168.89.1
  4    14 ms     3 ms     1 ms  192.168.59.1

Also alles gut aber

von einem Debian:

traceroute to 192.168.59.1 (192.168.59.1), 30 hops max, 60 byte packets
1  192.168.0.222  0.281 ms  0.259 ms  0.246 ms
2  192.168.1.2  0.489 ms  0.476 ms  0.450 ms
3  192.168.88.1  1.754 ms  1.595 ms  1.995 ms
4  * * *

Warum nach 88.1?

Routen auf der OPNSense 192.168.1.2

root@OPNsense-One:~ # netstat -rn
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.89.1       UGS        igb3
8.8.4.4            192.168.89.1       UGHS       igb3
8.8.8.8            192.168.88.1       UGHS       igb1
127.0.0.1          link#6             UH          lo0
176.95.16.250      192.168.88.1       UGHS       igb1
192.168.1.0/24     link#1             U          igb0
192.168.1.2        link#1             UHS         lo0
192.168.1.5        link#1             UHS         lo0
192.168.59.1       192.168.89.1       UGHS       igb3
192.168.88.0/24    link#2             U          igb1
192.168.88.2       link#2             UHS         lo0
192.168.88.5       link#2             UHS         lo0
192.168.89.0/24    link#4             U          igb3
192.168.89.2       link#4             UHS         lo0
192.168.89.5       link#4             UHS         lo

Müsste meine ich richtig sein die 59.1 sollte über 89.1 weiter gehen.

Auf der OPNsense selber kommt

Code Select Expand

root@OPNsense-One:~ # traceroute 192.168.59.1
traceroute to 192.168.59.1 (192.168.59.1), 64 hops max, 40 byte packets
1  192.168.89.1 (192.168.89.1)  1.224 ms  1.061 ms  1.030 ms
2  * * *

Hat jemand eine Idee warum hier das falsche Gateway genommen wird? Evtl. bin ich betriebsblind? Was könnte die Routenwahl noch beeinflussen?

Hinter dem Draytek hängen "unsichere" Geräte und ich hatte das auch mal in Kombi mit Draytek Modems betrieben (mittlerweile wieder Fritzboxen weil das die Provider leider so wollen sonst nicht vernünftig supporten)

Also:
Internet - Modem - exposed host -> Draytek --- IOT und WIFI für Gäste
                                                                  - dedizierte Portweiterleitung -> OPNSense  --- LAN

>Wenn du deinen Router ausdrücklich anweist, die zu filtern, dann klappt's halt nicht.

Default setting. Macht ja evtl. auch Sinn. Erfahrung macht klug  :P
Evtl. sollte man dass gleich in die Howtos für dummies mit reinnehmen :)

Ja fast - war halt der fragende WAN Router (nicht der switch dazwischen) - aber schöner wärs, wenn OPNSense auch die SRC MAC entsprechend setzen würde oder sehe ich das falsch?

[Block ARP replies with inconsistent source MAC addresses.]

Hätte evtl. ja schon selber mal auf die Idee kommen können auf der betreffen OPNsense selber ein TCPDump laufen zu lassen

Code Select Expand

root@OPNsense-One:/dev # tcpdump -i igb1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), capture size 262144 bytes
20:02:32.568142 ARP, Request who-has 192.168.88.5 tell 192.168.88.1, length 46
20:02:32.568146 ARP, Reply 192.168.88.5 is-at 00:00:5e:00:01:02 (oui IANA), length 28

Also schickt die FW die Antwort auch raus. Das der Pi und co die nicht sieht macht ja auch Sinn, da Switch dazwischen (kein Hub - hatte ich auch mal gelernt vor langer Zeit). Aber warum trägt der WAN Router die MAC der VIP nicht in seine ARP table ein? Das der Switch die verschluckt glaube ich nicht dann müsste er das Richtung PI auch machen. Bleibt noch der Router selber, der die MAC verwirft. Oder sieht jemand noch etwas anderes?

Update wenn man mal scharf Nachdenkt:
Defense setup im WAN Router: Block ARP replies with inconsistent source MAC addresses.
Wenn man die Prüfung raus nimmt funktioniert der Traffic. ABER die MAC wird trotzdem nicht eingetragen und es kommt eine kurze flut von ARP requests.
Mit filter an kommt auch im syslog des Routers (wenn man den Filter kennt kann man auch das logging dazu einschalten:)):
2022-12-19 20:23:58    Arp address mismatch - Ethernet source address doesn't match ARP sender address

Also ist jetzt die Fragestellung was muss ich evtl. an der OPNSense ändern, damit die DefenseRule nicht zuschlägt.
laut arp table auf dem Router: 192.168.88.2      3C-EC-EF-25-A7-5B
Die OPNsense antwortet aber mit:
3c:ec:ef:25:a7:5b > 00:1d:aa:70:09:08, ethertype ARP (0x0806), length 42: Reply 192.168.88.5 is-at  00:00:5e:00:01:02, length 28
Das hier die MAC der Quelle ungleich beantwortetes Ziel ist meckert der Router denke ich zurecht an oder?

Wenn man die Regel bzgl VRRP ARP darf nicht eingetragen werden auch noch rausnimmt, steht die MAC dann endlich auch im Cache. Also Problemstellung denke ich gelöst.

Noch jemand eine Idee?
Kann es einen UNterschied machen ob der ARP request vom Gateway kommt oder von einem anderen Device/IP?
Der WAN Router ist ja als Gateway in OPNSense drin - werden Anfragen vom Gateway evtl. besonders behandelt?

OKido - über die GUI ging es dann. Ich hatte es direkt auf der OPNsense vorher editiert. Hätte den gleichen Effekt erwartet - ist aber wohl nicht so.

DANKE für den Anstoss.

Wenn ich jetzt noch einen Schubs für mein VIP Problem bekomme ist der Sonntag gerettet.

Verkabelung ist sehr einfach quasi gleich dem Bild das ich in ASCI im Ersten post gemacht habe.
Statt der VIP den Switch vorstellen. Sprich je ein Port der OPN am Switch und von dort dann ein Kabel zum WAN Router.

Code Select Expand


      Router 1 192.168.88.1/24                                            Router 1 192.168.89.1/24
                          |                                                             |
                      Switch 1                                                     Switch 2
                  |            |                                                 |        |
OPNS 1 192.168.88.2/24  OPNS 2 192.168.88.4/24                OPNS 1 192.168.89.2/24  OPNS 2 192.168.89.4/24                   
   

Dass dann symmetrisch für beide WAN strecken.

Sind alles /24 Subnetze - im ersten Posting hatte ich an einer VIP /25 geschrieben das war ein Typo.

Jetzt habe ich mal einen BanaPi (Ubuntu) als switch eingebaut. Nur um mal den Netgearswitch auszuschließen
Dassselbe Bild der Pi findet die VIP und trägt dann die MAC brav in seine ARP table ein. Der WAN Router weigert sich standhaft (aber der Ubuntu Pi steht jetzt drin - funktioniert also prinzipiell schon).
Hab echt keine Idee mehr. Könnte jetzt noch den PI in einen Router umwandeln und verschiedene Netze Verwenden, aber so recht sinn macht das jetzt vom eigentlich setup her nicht.

Code Select Expand

pi@bpi-iot-ros-ai:~$ sudo arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.89.2             ether   3c:ec:ef:e9:7c:1b   C                     eth0
192.168.89.1             ether   14:49:bc:0a:7d:38   C                     eth0
pi@bpi-iot-ros-ai:~$ ping 192.168.89.5
PING 192.168.89.5 (192.168.89.5) 56(84) bytes of data.
64 bytes from 192.168.89.5: icmp_seq=1 ttl=62 time=0.696 ms
64 bytes from 192.168.89.5: icmp_seq=2 ttl=62 time=0.771 ms
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.696/0.733/0.771/0.046 ms
pi@bpi-iot-ros-ai:~$ sudo arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.89.2             ether   3c:ec:ef:e9:7c:1b   C                     eth0
192.168.89.5             ether   00:00:5e:00:01:03   C                     eth0
192.168.89.1             ether   14:49:bc:0a:7d:38   C                     eth0
pi@bpi-iot-ros-ai:~$ sudo tcpdump arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:34:13.836225 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
...
00:34:24.620613 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
00:34:33.527139 ARP, Request who-has 192.168.89.1 tell 192.168.89.51, length 28
00:34:33.529200 ARP, Reply 192.168.89.1 is-at 14:49:bc:0a:7d:38 (oui Unknown), length 46
00:34:58.991837 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
...
00:35:09.618950 ARP, Request who-has 192.168.89.5 tell 192.168.89.1, length 46
00:35:30.119232 ARP, Request who-has 192.168.89.51 (0e:5f:b1:1e:2f:54 (oui Unknown)) tell 192.168.89.1, length 46
00:35:30.121295 ARP, Reply 192.168.89.51 is-at 0e:5f:b1:1e:2f:54 (oui Unknown), length 28
00:35:40.527160 ARP, Request who-has 192.168.89.1 tell 192.168.89.51, length 28
00:35:40.529282 ARP, Reply 192.168.89.1 is-at 14:49:bc:0a:7d:38 (oui Unknown), length 46

Kabel: Das ist symmetrisch aufgebaut

Das mit Ändern in /conf/config.xml funktioniert aber leider nicht. Nach reboot stehen die vorherigen Werte wieder drin. Wo ist da denn die "Quelle"?