Messages

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!

Danke für deine Antwort. Ich scheine einen Kandidaten gefunden zu haben. Die FW betrachtet ihren Traffic vom Squid (logischerweise) als vom Auto-Rule "let out anything from firewall host itself " gedeckt zu betrachten.

Ich teste das später mal

Servus,
ich betreibe einen Squid Forward-Proxy auf der OPNsense und möchte diesen ausgehend mit Firewall-Regeln (Firehol) reglementieren. Leider ist mir nicht klar, an welchem Interface ich die Regeln anwenden muss.

Ich habe das LAN und WAN mit Direction in und out und jeweils entsprechend die Liste als Source und Destination versucht und die Regeln ziehen nicht. Also quasi alle Möglichkeiten.

Danke und Grüße

Nein Proxy und IPS sind nicht aktiv.
Services die laufen sind ClamAV, DHCPv4 und Adguard über Unbound. Adguard scheint die Anfrage aber durchzulassen.

Was bekommst du als Antwort von nslookup auf einem Client, wenn du die Adresse aufrufst?

Das wäre das komplette Schema, ich glaube, ich vermisse nichts.

Ok, das ist die Konfiguration auf einer Seite. Wir brauchen nun die Konfiguration der anderen Seite.

Wir brauchen weiter Informationen über eine traceroute wie in meinem Beispiel (192.168.111.100 -> 192.168.114.8 Einmal traceroute über WAN 1 und einmal traceroute WAN 2.

tracert 192.168.114.8

Routenverfolgung zu [192.168.114.8]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  192.168.111.254 (LAN Gateway Site A)
  2    27 ms    27 ms    27 ms  10.10.12.0 (VPN Gateway Site B)
  3    28 ms    28 ms    27 ms  192.168.114.8 (LAN Site B)

Über VPN verbunden kann ich erfolgreich auf den OPNSense-Webmanager zugreifen. Ich habe versucht, eine Verbindung von WAN1 und WAN2 mit dem gleichen Problem herzustellen.

Verbunden über VPN (10.70.250.250) LAN IP 192.168.254.230 antwortet NICHT auf PING.

Aus LAN: 192.168.254.230 Reagiert NICHT auf Ping 10.70.250.250

Mach bitte eine Netzwerkübersicht wie hier mit deinen richtigen Adressen:

Netz Seite A             VPN Gateway A    WAN 1 / WAN2    VPN Gateway B         Netz Seite B
192.168.0.0/24 <->    10.0.0.0/31  <->       Internet  <->    10.0.0.1/31     <-> 192.168.1.0./24

Mir ist sonst nicht klar, wie du routest.

Danach das Ergebnis einer traceroute: Netz Seite A nach Netz Seite B. Einmal traceroute mit WAN 1 und einmal mit WAN 2

Sevus,
sofern den jeweiligen Stellen die Moden-Zugriffsadressen bekannt sind, das Routing also stimmt, verweigert das Modem vermutlich Zugriff von IPs außerhalb des jeweiligen Modem-Subnetzes.

Das lässt sich mit einer Outbound-NAT-Regel auf das Modem-Interface regeln. Zugriff vom VPN-Netz auf Interface-Adresse des Modems NATten.

Grüße

[- Ziel-WAN1-Adresse]

Hallo,

Glückwunsch zur Fußball-Weltmeisterschaft nach Argentinien! ;-)

- WAN2-Schnittstelle
- UDP-Protokoll
- Ziel-WAN1-Adresse

Hast du dich hier verschrieben? Ziel muss sein: WAN2-IP.

Wenn der VPN-Tunnel steht, kannst Du die VPN-Endpoints pingen?
Beispiel:

192.168.0.0/24 <-> 10.0.0.0/31 <-> Internet <-> 10.0.0.1/31 <-> 192.168.1.0./24

Also kann 10.0.0.1 nach 10.0.0.2 pingen und umgekehrt?


Grüße