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.

Messages - endurance

Pages: [1] 2

23.1 Legacy Series / Re: Surricata causing 100% CPU load after upgrade on 23.1

« on: February 06, 2023, 01:09:05 pm »

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).

23.1 Legacy Series / Re: Surricata causing 100% CPU load after upgrade on 23.1

« on: February 05, 2023, 07:25:55 pm »

Sure I should read the question more careful

Code: [Select]

999.000231 [4026] netmap_transmit igb1 drop mbuf that needs checksum offload
disabled hw offload - now all back to normal.

23.1 Legacy Series / Re: Surricata causing 100% CPU load after upgrade on 23.1

« on: February 05, 2023, 03:14:21 pm »

nothing really indicating an error.

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

Code: [Select]

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

Intrusion Detection and Prevention / Re: OPNSense 23.1 suricata Keeps stopping.

« on: February 05, 2023, 11:17:23 am »

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.

23.1 Legacy Series / Surricata causing 100% CPU load after upgrade on 23.1

« on: February 05, 2023, 10:59:15 am »

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]

  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]

  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]

  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

German - Deutsch / Re: Routing experten gefragt

« on: December 21, 2022, 10:53:59 pm »

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.

German - Deutsch / Gelöst: Routing experten gefragt - Einfluss von Rules auf Gateways

« on: December 21, 2022, 10:16:13 pm »

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:

Quote

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:

Quote

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

Quote

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]

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?

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 19, 2022, 10:28:48 pm »

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

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 19, 2022, 10:07:24 pm »

>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

Evtl. sollte man dass gleich in die Howtos für dummies mit reinnehmen

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 19, 2022, 09:25:22 pm »

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?

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 19, 2022, 08:21:23 pm »

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]

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.

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 19, 2022, 12:55:53 pm »

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?

German - Deutsch / Re: HA Setup mit PFSync - Wie IF Namen anpassen?

« on: December 18, 2022, 06:52:07 pm »

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.

German - Deutsch / Re: Router findet VIP (CARP) nicht (ARP problem?)

« on: December 18, 2022, 03:57:17 pm »

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]

      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]

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

German - Deutsch / Re: HA Setup mit PFSync - Wie IF Namen anpassen?

« on: December 18, 2022, 03:51:04 pm »

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"?

Pages: [1] 2