OPNsense Forum
International Forums => German - Deutsch => Topic started by: opnsense_user12123 on March 15, 2018, 07:36:04 pm
-
Bin ein wenig verwirrt ::)
Ich habe heute mal die zwei NAT Rules für 127.0.0.1 (http,https) deaktiviert.
Zu meinem erstaunen wurde aber trotzdem das ssl Zertifikat des transparenten proxy´s akzeptiert und das surfen funktionierte weiterhin ganz normal.
Wie kann das Zertifikat im Browser weiterhin akzeptiert werden wenn der redirect nicht mehr auf 127.0.0.1, also den Proxy läuft?
-
hast du den proxy im System oder Browser hinterlegt (Proxyeinstellungen)?
Nehme mal an, dass du den WPAD/PAC patch nicht eingespielt hast, mit dem man das auch so machen kann.
Eine Alternative Erklärung ist, dass du deine Firewallregeln noch nicht neu geladen hast.
-
Ein Neustart hat auf alle Fälle nichts gebracht. Es ist ein Transparenter Proxy. Ich habe nichts im Browser (Firefox) eingetragen.
Mit welchem Befehl kann den die Regeln neu laden?
Gehts auch über die GUI auch?
Nein, WPad habe ich nicht installiert. Was sind die Vorteile von Wpad und wie kann ich es installieren?
Unter Plugins finde ich nichts.
Danke
-
Das ist eine Technik, mit der der Client mitbekommt, dass es im Netzwerk einen Proxy gibt, über den er sich ins Internet verbinden kann.
WPAD beschreibt, wie der Client an ein PAC file ran kommt und PAC ist eine JavaScript-Datei, die abhängig von Host, URL und anderen Eigenschaften einen Proxy auswählt, den die Anwendung dann verwendet.
Die Patches dafür sind derzeit auf GitHub (als PR) aber noch nicht offiziell in OPNsense stable oder devel.
Es sollte ein PF-Service geben, das du neu starten kannst.
-
Service: Packet Filter -> reloaded!
Ich werde es mal morgen ausprobieren, ob das Phänomen auch nach einem reload noch vorhanden ist.
Ich dachte immer das sich die Regeln nach einem "Apply" im Hintergrund wieder aktualisieren!
Danke für die Info!
-
hast du den proxy im System oder Browser hinterlegt (Proxyeinstellungen)?
Nehme mal an, dass du den WPAD/PAC patch nicht eingespielt hast, mit dem man das auch so machen kann.
Eine Alternative Erklärung ist, dass du deine Firewallregeln noch nicht neu geladen hast.
Also, ich habe, wie von dir empfohlen das heute nochmals ausprobiert.
NAT redirect von "LAN1 NET" auf "127.0.0.1:3128(http)" und die gleiche Regel darunter für auf "3129(https)" deaktiviert. PF Filter reloaded (Dienst restartet)-> Danach die States in der Firewall Diagnostik gelöscht und den Webbrowser (Firefox) geschlossen.
-> Trotzdem funktioniert alles wie gehabt
Konnte weiterhin über den Browser mit meinem akzeptierten Zertifikat surfen!
Bin im transparenten Modus mit SSL Zertifikat und im Browser steht, dass das Zertifikat von meiner Firewall aktiv und akzeptiert wird!
Das sollte doch nicht sein, wenn ich den redirect deaktiviert habe, oder ? Wie kann das sein ?
-
hast du den proxy im System oder Browser hinterlegt (Proxyeinstellungen)?
Nehme mal an, dass du den WPAD/PAC patch nicht eingespielt hast, mit dem man das auch so machen kann.
Eine Alternative Erklärung ist, dass du deine Firewallregeln noch nicht neu geladen hast.
Nun habe ich folgendes festgestellt. Ich habe 3 Interfaces auf meiner Firewall. Der Pc mit dem ich dies hier ausprobiere liegt im LAN1.
Die zweite NAT Regel hat einen NO-RDR mit einem Alias. Wenn ich diese NO-RDRule aktiviert habe funktioniert der Proxy auch wenn ich die eigentliche NAT Redirect Regel des LAN1 deaktiviert habe. im Alias des LAN2 hängen aber wirklich nur Rechner des LAN2. Also sollte auf das LAN1 überhaupt keinen Einfluß haben. Ich denke hier stimmt etwas nicht -> Besteht noch immer das Alias Problem? oder hat der Proxy allgemein ein Problem?
Nur wenn ich die LAN2 NAT RDR Rule deativiert habe funktioniert auch der Proxy am LAN1.net nicht mehr. Wie kann das sein?
siehe screenshot
-
Kann ich dir so nicht sagen - was dir da helfen kann ist, dass man unter /tmp/rules.debug die generierten Regeln findet.
-
Kann ich dir so nicht sagen - was dir da helfen kann ist, dass man unter /tmp/rules.debug die generierten Regeln findet.
pro nat regel sind es drei rules in der rules.debug...Passt das zusammen ? (siehe screenshot)
rdr on igb1 inet proto tcp from {(igb1:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb2 inet proto tcp from {(igb1:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb3 inet proto tcp from {(igb1:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb1 inet proto tcp from {(igb1:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb2 inet proto tcp from {(igb1:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb3 inet proto tcp from {(igb1:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb2 inet proto tcp from !$noproxy to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb1 inet proto tcp from !$noproxy to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb3 inet proto tcp from !$noproxy to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb2 inet proto tcp from !$noproxy to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb1 inet proto tcp from !$noproxy to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb3 inet proto tcp from !$noproxy to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb3 inet proto tcp from {(igb3:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb1 inet proto tcp from {(igb3:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb2 inet proto tcp from {(igb3:network)} to {any} port {443} -> 127.0.0.1 port 3129 # redirect traffic to proxy
rdr on igb3 inet proto tcp from {(igb3:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb1 inet proto tcp from {(igb3:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
rdr on igb2 inet proto tcp from {(igb3:network)} to {any} port {80} -> 127.0.0.1 port 3128 # redirect traffic to proxy
-
warum auch immer, aber das "source invert" des "Alias" in der NAT Regel war Schuld. Warum auch immer!
Von der Logik her hätte es gepasst!
Ich wollte alle Clients im LAN2.net auf 127.0.0.1 weiter-naten außer die "!noproxy" clients.
Das hat aber nicht geklappt. Völlig unlogisch!
Hab jetzt eine eigene NAT Regel explizit für die "Ausnahmen(alias)" gemacht und nun wird beim deaktivieren der LAN1 Nat Regel auch wirklich nichts mehr weitergeleitet bzw auf 127.0.0.1 umgeleitet.
Warum das LAN2 NAT sich auf das LAN1.net-NAT ausgewirkt hat, verstehe ich bis jetzt aber überhaupt nicht. (siehe screenshot mit funktionierender neuer Regel)
-
Da man nicht weiß, was sich hinter deinem "noproxy" versteckt ist das auch nicht so einfach zu sagen?
-
Da man nicht weiß, was sich hinter deinem "noproxy" versteckt ist das auch nicht so einfach zu sagen?
Hinter noproxy verstecken sich nur Rechner im lan2