Messages

1

German - Deutsch / Re: Suricata zurücksetzen

« on: March 02, 2022, 05:42:22 pm »

du hast das ja gar nicht übr die policies gesteuert?

Hau mal alle raus (Reiter Download), Alles auswählen, Disable selected, Save, Download & Update.

In den Policies Regel rein, Prio 0 Action Disable, Alert, Drop, New Action Drop, bzw. wenn du zuerst mal alle deaktivieren willst, dann Disable.

2

German - Deutsch / Re: Suricata zurücksetzen

« on: March 02, 2022, 01:29:02 am »

Und ich gehe davon aus, dass du die 21.x hast, machma update auf 22.1

3

German - Deutsch / Re: Suricata zurücksetzen

« on: March 02, 2022, 01:23:41 am »

Poste mal deinen download screen,
Wenn du da alles aktiv hast sind die Regeln eben auch aktiv

4

German - Deutsch / Re: Failover geht nicht zurück auf Tier1 bei dauerhafter Verbindung

« on: March 01, 2022, 11:26:29 pm »

Florian,

Erster Verdächtiger wäre für mich DNS.

Was monitoren die 2 Gateways? Google?
und das ggf auch noch von intern als DNS eingetragen?

Ralf

5

German - Deutsch / Re: Suricata zurücksetzen

« on: March 01, 2022, 11:11:46 pm »

Aber das war doch dein Ziel „keine Regeln“. Es gibt keinen initialen Regelsatz.
Und dass suricata keinen verschlüsselten ICAR identifiziert liegt in der Natur der Sache.

Die Regeln sind anfangs immer leer. Ich verstehe nicht was du erreichen willst.

Ralf

6

German - Deutsch / Re: [HAProxy] URL umschreiben, weiterleiten...

« on: March 01, 2022, 11:05:43 pm »

Hallo,

Wenn aspx gehe ich davon aus, dass ein IIS dahinter werkelt.
Mach doch dort die rewrite rules.
Mit dem HAProxy geht das natürlich auch, zum Abfangen der Aufrufe, aber den rewrite, bestenfalls 301, macht dieser nicht.

Ralf

7

German - Deutsch / Re: OpenVPN auf ein bestimmtes Netz einschränken?

« on: March 01, 2022, 10:43:20 pm »

Ok,

Mach doch zwei OVPN Server auf 2 unterschiedlichen Ports mit unterschiedlichen Zielnetzen.
Als Serveradresse nimmst du einen FQDN my.firewall.de der mit 2 DNS Einträgen
my.firewall.de IN A 99.99.99.91
my.firewall.de IN A 99.99.99.92
einen round-robin load balancer erzeugt.

Das default gateway kannst du im OVPN Setup festlegen,

LG

Ralf

8

German - Deutsch / Re: Suricata zurücksetzen

« on: March 01, 2022, 10:20:11 pm »

So in‘s Blaue:

Im Download alles auswählen, dann disable selected. Sollte doch gehen.

LG Ralf

9

German - Deutsch / 1GBit PPPoE Durchsatz: altes Problem mit Hardware erschlagen?

« on: March 01, 2022, 10:16:20 pm »

Moin,

hab heute einen Kunden auf 1000/500 MBit FTTH umgestellt, Provider hat nun leider auch von static IP auf  Steinzeit PPPoE gewechselt. Nach zig Telefonaten weil die IPv4 als DS-Lite implementiert hatten, trotz anderer Order, und dort niemand nur die Spur einer Ahnung hatte, ging‘s dann irgendwann wie erwünscht.

Dann iperf und diverse Tests auf folgender Plattform

OPNSense 22.1.1_3, AMD GX-420MC (4 cores, 4 threads) 8GB RAM

Ich komm leider nur auf 400/400, egal ob mit oder ohne suricata. CPU load immer bei 100%. Eben das bekannte single Core Problem.

Bringt‘s denn etwas PPPoe auf eine Bridge auszulagern? Gibt es hier überhaupt potente Modems?

Oder gleich die Hardware tauschen? Empfehlung für ca. 80 Clients, 4 IPSec Site2Site und 10 OpenVPN Clients?

Eigentlich nix Wildes, aber PPPoE birgt hier immer Stresspotential (auf BSD).

Bin mal gespannt ich nun auch Shaping, wie bei anderen Kunden, mit FQCodel einsetzen muss um den Bufferbloat zu vermeiden.

Freue mich auf Antworten von Leidensgenossen.

LG,

Ralf

10

22.1 Legacy Series / Multi-WAN IPSec Road Warrior

« on: February 02, 2022, 11:38:11 am »

First of all, big thanks to everyone here!

I'm struggling with a Multi-WAN Setup

WAN1+2, two equal PPPoE Interfaces running in just one Gatewaygroup (WANGWGROUP) Tier 1 Load Balancing.

Outgoing Traffic is all fine, load balancing between those two WANs (Rule in LAN using WANGWGROUP) works as expected.

But when it comes to local services like IPSec, only the first WAN interface marked as active will respond.

Int this case, when WAN2 is marked as active (default route), if I try to connect to IPSec explicitly to WAN1, a packet capture shows incoming packets on WAN1 (in trace and ipsec.log) but they are answered from WAN2 with a source address of WAN1.

If I try to connect to WAN2 everything's fine and fast.

Inbound Rules on WANGWGroup for UDP 500,4500 and ESP are set (gateway "default").

What am I doing wrong?

Ralf

11

German - Deutsch / Re: Weiteres Netz ohne Routing, autonomous System

« on: December 03, 2021, 03:17:26 pm »

> Wenn du selbst kein BGP fährst, muss dir ein LIR das Netz normalerweise zurouten. Also potentiell der Provider, von dem du das /30er hast, muss dann - sofern er selbst LIR ist - dein Netz dir auf die .2 routen. Macht unser DC Provider für uns auch, da sich BGP nicht lohnt wenn eh nur ein Upstream Provider zur Verfügung steht.

Ja, dachte ich auch, macht der aber nicht, wirft nur alle Ziel IPs am Interface raus, daher der Umweg über das NAT.

> Warum tut er das? Wenn er dir doch das /30er stellt, kennt er doch deine Gegenstelle und weiß dass die auf der .2 ist. Warum sollte er DEIN Netz dann auf die .1 routen? Wenn dann ist das potentiell ein Fehler, dann würde ich beim Carrier/ISP nachfragen.

Ich wechsle eh grad, das tu ich mir nicht nochmal an, hoffe der neue  macht's richtig, hätte nur gerne VOR der Umstellung die bisherige Firewall durch die OPNSense ersetzt. Aber dann gibt's halt nen harten Umstieg.

Vielen Dank,

Ralf.

12

German - Deutsch / Weiteres Netz ohne Routing, autonomous System

« on: November 30, 2021, 07:51:30 pm »

Hallo zusammen,

ich habe hier zwei WAN IP Ranges:
Range A: 90.90.90.0/30, Gateway Provider 90.90.90.1, eigene 90.90.90.2

Range B: 99.99.99.0/24 (eigenes Class C vom RIPE=AS)

Da ich kein BGP fahren will (und auch nicht brauche, da nur ein Carrier) aber gerne ausschliesslich Adressen aus der Range B verwende weiss ich nicht, wie ich das an der OPNSense konfigurieren soll.

Der Carrier wirft alle Pakete für die Range B am Interface des Routers der Range A (90.90.90.1) ab. Die 90.90.90.2 steht der OPNSense zur Verfügung.

An der bisherigen Firewall habe ich das mit 1:1 NAT auf dem  Interface der Range A gelöst und alles auf ein zweites Interface der Range B geleitet. Gibt‘s hier ne bessere Lösung?

Da ich demnächst auch IPv6 (ebenso AS) entsprechend geroutet bekomme, hätte ich gerne eine elegantere Lösung. Zur Not muss ich doch BGP einsetzen.

Gruß Ralf. 

13

German - Deutsch / Re: Upgrade HA Nodes - kurze Downtime & low Risk?

« on: March 26, 2021, 01:40:15 pm »

An sich richtig. Nur das NAT darf eben nur für die lokalen Netze durchgeführt werden

Eben, die VIP steht nur als NAT Address drin, nicht als source.

LG, Ralf.

14

German - Deutsch / Re: Upgrade HA Nodes - kurze Downtime & low Risk?

« on: March 26, 2021, 01:28:08 pm »

Aber NAT hat doch damit gar nichts zu tun.

Wenn die Backup-OPNSense sich die Updates holen soll, dann tut sie dies ohne NAT über deren offizielle IP und das entsprechende Gateway. Ich würde hier eher mal die Rules ansehen.

Außer man nattet auch die Pakete der Firewall selbst, was imho aber keinen Sinn ergibt.

LG, Ralf.

15

German - Deutsch / Re: Traffic Shaping und IPSec

« on: March 26, 2021, 10:03:19 am »

Welches Interface hast du gewählt und welchen scheduler? WFQ, FQ_Codel und Q2Q beinhalten alle das "Q" für Queue, da wirds dann schwierig ohne Queues. Wäre eher was für FIFO.

steht im Bildchen, I/F WAN,Scheduler ist default, also WFQ. Du meinst bei WFQ muss ich auch Queues anlegen?

Ralf.

Nachtrag: hab das nun über nur 2 Pipes und FQ-Codel, 3 Queues und ein paar Regeln so hinbekommen, dass es wie beabsichtigt läuft. (Prinzipiell: DNS, VoIP und tcp-ack hohe Prio im Upload, Rest niedrige Prio)