Messages

Servus,
habe den Rebind-Schutz zentral deaktiviert. Dennoch kommen keine Antworten vom DNS (außerhalb der OPNsense), welche eine Antwort aus den im Unbound hinterlegten privaten Netzen enthält.

Ich muss entweder die Domains im Unbound explizit als erlaubt hinterlegen, und / oder das Query-Forwarding für jede Domain aktivieren.

Sehr nervig...

Was mach ich falsch?

Danke und Grüße

I know that Zenarmor only use one core. That's the cause of my question. On their roadmap, multi-core operation would be implemented in the next 1-6 months(or so).

So badly I need experience from working devices... My personal experience: 1 GBit without TLS-inspection is nearly possible in my lab. 1 Core @100% Iperf3 with 10 parallel streams + OpenSpeedtest. But that's lab. Not repesentive for an company's Internet-Traffic-Mix.

Hi,
does anybody have experience in running Zenarmor at Intel Atom C3758R? What internet troughput can this CPU handle? The CPU-list at Zenarmor's website give me not an clear answere.

Thank's!

Es geht ja nicht so sehr ums Wie. Es geht darum: gibts was, was nicht failover-fähig ist? ;-)

[3]

Ja, B wusste nicht, dass das Netz da sitzt. Daher kam ich ja auf asynchrones Routing. Ich hab's in den CSO geschrieben gehabt und dachte eigentlich, das genügt. Dabei muss es im CSO UND(!) in der Serverkonfig stehen.

Das war das ganze Problem... Ich muss noch mehrere Außenstellen per VPN anbinden. Bin mal gespannt, was der Server macht, wenn die alle verbinden. Denn der baut seine Routingtabelle nämlich so, dass weitere Netze, die in einem anderen CSO eingetragen sind, trotzdem auf den Endpunkt der Seite geschickt werden, die das Netz gar nicht hat.
You cannot view this attachment.

Jedenfalls habe ich das gerade so versucht. Siehe Bild. Dabei sollte sie wie folgt aussehen:

192.168.200.32/27 192.168.200.2
192.168.99.0/24 192.168.200.3

Denn:
192.168.200.32/27 steht im CSO für Site A
192.168.99.0/24 steht im CSO für Site E (eine weitere VPN-Außentelle wie Site A)

Servus,
ich habe seltsame Routingprobleme und wahrscheinlich asynchrones Routing. Vorweg: Firewall rules auf den Interfaces testweise any any any any.

Beschreibung:

Tunnel von Site A(Client) auf Site B(Server).
Clientnetz Site A = 10.1.0.0/24
Transfernetz zw. A und B 192.168.0.1/29

Site B hat ein Transfernetz 10.2.0.0/24 an Site C (nicht meine Infratstruktur). Da ist ein GW, der auf Site C Subnetze 10.0.0.0/8 hat.
Opnsense Site B hat eine statische Route 10.0.0.0/8 nach GW 10.2.0.1 (Route 10.0.0.0/8 muss so sein, weil dahinter noch mehr ist)


Was funktioniert:

Gehe ich direkt auf die opnsense Seite A, kann ich eine Adresse Hinter GW Site C erreichen. Tunnel steht also, Routing grundsätzlich richtig. Dabei kommt mein Ping auf 10.4.0.22 von 192.168.0.2 (also der Transfernetz-OpenVPN-IP der Site A)

Was nicht funktioniert:
Komme ich von 10.1.0.10, also dem LAN von Site A mit Ping auf 10.4.0.22 an Site C, werden die Pakete zwar zu 10.4.0.0/24 weitergeleitet (sehe ich im Capture) und kommen an. Die Rückantwort von 10.4.0.0/24 wird von opnsense Site B dann aber nicht über den Tunnel zurück an A geschickt, sondern über deren WAN-Interface. Damit wäre das asynchron.


Ich hab das mit pfSense schon zigfach gebaut. Daher ist das mit der Route an sich alles richtig. Nur mit opnsense gehts nicht und ich finde den Fehler einfach nicht.


Die VPN-Server und Clients haben analog dazu in ihre local und remote networks die entsprechenden Netze eingetragen.

Hat irgendwer eine Idee?

Vielen Dank!



 

Servus,
funktioniert das CARP-Failover auf opnsense inkl. aller Pakete wie Zenarmor / Squid / VPN etc oder gibt's da irgenwelche Einschränkungen? Sprich: Ist das Failover-Cluster tatsächlich ein vollständiger Ersatz oder nur partiell?

Danke und Grüße

Ja, das war schon klar. Wie gesagt: mit der alten Securepoint funzt es sofort. Die Einstellungen wurden nicht geändert und alle anderen Geräte im Netz funktionieren einwandfrei. Soweit über, als auch unter der problematischen IP.

Auch das leider nicht. Subnetz stimmt.

Ganze 5 Mal. Die Switche dazwischen auch... Wie gesagt: ich sehe an der Sense auch Anfragen der IP. Nur funktioniert sie nicht. Und sie antwortet auch nicht auf Ping. Der ARP-Cache kann es damit eigentlich nicht sein. Sonst würde gar nix ankommen und ich auch keine DNS-Requests sehen.

Servus,

mit der alten Securepoint gehts. Darum meine Frage: eine einzige IP kommuniziert nicht mit der Opnsense. Ich sehe im Paket Capture ab und an Verkehr vom Gerät, auch will sie zu einem Google DNS und eine IPSec aufbauen. Darf sie auch. Any Regel sitzt. Möchte ich das Gerät von der opnsense aus pingen, geht es aber nicht. Keine Antwort. Alle anderen Geräte gehen. Also sowohl von der opnsense an die anderen Geräte, wie auch andere Geräte die "gestörte" IP.

Also den Uplink am Switch kontrolliert: schließe ich meinen Laptop an besagtem opnsense-Port an und setze das VLAN, kann ich pingen und bekomme Antwort. Der Switch selbst scheint ok, die anderen dazwischen auch.

Die Opnsense will ums Verrecken nicht mit dem Gerät. Hat sowas jemand schon mal gehabt? ALLE anderen IPs im Netzwerk sind pingbar. Selbst die, die an demselben Switch hängen und ich betone nochmal: mit der alten Securepoint gehts sofort. Natürlich passt das Subnet bei der opnsense.

Danke und Grüße

Danke, ich hab's befürchtet. Warum man sich sowas systemseitig antut - ich weiß es nicht. Nach 20(!) Jahren pfSense schüttle ich bei einigen Dingen den Kopf...

Moin,
keiner einen Tipp für mich, wie ich das Auto-Rule überschreiben kann, außer es in der /usr/local/etc/inc/filter.lib.inc zu editieren?

Ich danke im Voraus.

Squid kann keine Listen wie Firehol oder Spamhaus konsumieren. Mir ist schon klar, dass eine SNI-Filterung auf dem Proxy die bessere Lösung ist, welche es auch gibt.

Es geht hier aber explizit darum, besagte Listen auf der FW zu blocken.

Wie oben erwähnt, habe ich das Floating-Rule bereits gemacht. Trotzdem gewinnt das Auto-Rule. Daher suche nach nach dem korrekten Weg für die Rules

Ich fasse zusammen: Das Auto-Rule hat last match. Das Floating first match. Das müsste also gewinnen.

Ok, es ist so: das Auto-Rule ist das Problem. Wie kann ich das überschreiben? Das Auto-Rule steht auf last match. Ich habe ein Floating auf beide WAN-Interfaces mit der Option quick und als Destination testweise IPs von Github eingetragen. Leider trifft das Auto-Rule trotzdem.

Wäre für einen Tipp sehr danbkar!