Messages

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

Servus,
keiner mit Ideen / Erfahrung dabei?

Grüße

Normalerweise schaltet der DSLAM bei häufigen Reconnects die Übertragungsrate runter, bis die Leitung stabil läuft. Bei so großen Zeitspannen, sieht er dazu vermutlich keine Notwendigkeit.

TAE hast du schon gemacht. Im Zweifel TAE entfernen und Modem direkt an die Doppelader anschließen. Gerne auch mal am APL im Keller Kontakte putzen. Insbesondere bei älteren Häusern gerne mal genommen.

Bin gespannt, was es letztlich bei dir ist.

Mein Zyxel bezeichnet als WAN Link die synchrone Verbindung zum DSLAM. Unabhängig von der aufgebauten PPPoE-Verbindung.

Ich interpretiere Deine Information ebenso: Dein Modem verliert den Sync, nicht die OPNsense trennt die PPPoE. Aber wie gesagt, das muss Dir das Log der OPNsense mitteilen.

Es ist auch einfach rauszufinden: trenne die PPPoE-Verbindung auf der OPNsense manuell und verbinde wieder. Wenn der Zähler im Modem weiterläuft, ist es wie von mir interpretiert.

Servus,
folgt der Reconncet denn auf einen Verlust der Synchronisation des Modems? Die Verbindungsdauer sollte sich im Modem auslesen lassen.

Das Log nennt normalerweise auch den Grund für einen Reconnect. Timeouts o.ä.

Grüße