IPsec traffic Webproxy

[Lochkartenknipser]

Hallo zusammen,
ich muß mich jetzt doch mal an die Profis wenden.
Ich teste seit einigen Wochen die OPNsense um später eine UTM abzulösen. Ich komme Routertechnisch aus der Lancomecke.
Ich habe eine OPNsense bei Hetzner in der Cloud installiert mit einer Öffentlichen v4 Adresse und dahinter eine Windowsmaschine zum testen. Auf der OPNsense läuft erfolgreich Croudsec, GeoIP blocking, ntopng, transparenter Proxy http und https, ClamAV im Webproxy sowie Sperrlisten und MIMEtypes. Windowsupdates werden nicht über den Webproxy geroutet wegen den Zertifikaten, Unbound DNS mit Sperrlisten und Zenarmor. Bis dahin funktioniert alles wie es soll auf der Windowsmaschine hinter der OPNsense im lokalen Netzwerk in der Hetzner Cloud.

Jetzt habe ich IPsec eingerichtet auf der OPNsense damit ich mein Netzwerk zu Hause mit der Hetzner Cloud verbinden kann. Bei mir zu Hause steht eine Lancom als Tunnelendpunkt. Ich kann auch durch den IPSec-Tunnel auf die OPNsense und die Windowsmaschine in der Cloud zugreifen. Funktioniert auch alles wie es soll.
Der nächste Schritt ist jetzt den Internettraffic von zu Hause durch den IPSec-Tunnel zu routen und als Ausgangspunkt die OPNsense in der Hetznercloud zu nutzen. Das funktioniert auch tatellos. Als DNS zu Hause nutze ich jetzt aktuell auch den UnboundDNS der OPNsense mit den Sperrlisten.
Dann habe ich versucht den Internettraffic ebenfalls durch Zenarmor zu leiten. Das funktioniert nicht wegen dem netmap-modul das Zenarmor benutzt. Dann habe ich versucht den Internettraffik durch den transparenten Webproxy zu leiten, damit der traffic auf Vieren geprüft wird und die MIMEtyps greifen. Aber jetzt genau fängt mein Problem an. Ich habe das NAT eingerichtet von dem Netzwerk zu Hause auf der OPNsense, aber ich kann in dem Webproxy als ProxyInterfaces nur LAN und Loopback auswählen. Dann habe ich einen Virtuellen adapter im IPSec angelegt, der wird aber auch nicht als mögliches ProxyInterface angezeigt.
Im Log von dem Webproxy sehe ich auch keinen Traffic von meinem Heimnetzwerk.
Wie kann ich es anstellen, daß der IPSec-Traffic ebenfalls durch den transparenten Proxy läuft?

Für eure Hilfe wäre ich sehr dankbar, damit es mit meinem testproject weitergehen kann.

Viele Grüße.

[Lochkartenknipser]

Hallo, ich nochmal.

Hat niemand eine Lösung für mich?????

[Lochkartenknipser]

Hallo,
ich bin bei dem Thema fast am verzweifeln. Gibt es denn wirklich keine Möglichkeit?

viele Grüße
Markus

[Monviech (Cedrik)]

Das Setup ist sehr spezifisch und wenn es nicht jemand genau so betreibt kann da nicht so einfach geholfen werden. Ist der Webproxy denn wirklich nötig? Auf Viren wird der Verkehr eh nur richtig überprüft wenn die SSL Verbindungen entschlüsselt und erneut verschlüsselt werden. Alleine die HTTP und HTTPS Verbindungen "transparent" zu überprüfen lohnt sich kaum heutzutage. Wäre eine Endpoint Protection auf deinen Geräten vielleicht der bessere Weg?
Wenn es nur um unverschlüsselte Verbindungen geht benutze doch Suricata als Inline IPS.

[Lochkartenknipser]

Hallo Monviech,
erst mal vielen Dank für Deine Antwort.
Ja, der Webproxy wäre nötig. Denn ich betreibe im lokalen Netz bei Hetzner (da steht auch die OPNsense virtuell) 2 Testserver. Da funktioniert der Webproxy super. HTTP und HTTPS mit entschlüsseln und wieder verschlüsseln. Virenscanner und MIME-Types geht gut. Ich scanne auf Viren und ziehe doc, docx usw. damit aus dem Verkehr.
Jetzt geht es darum, mein Homeoffice über IPSec mit der Hetzner Cloud zu verbinden und dann die PCs ebenfalls über die OPNsense ins Internet zu schicken. Natürlich auch durch den Webproxy.
Die IPSec verbindung steht stabil. Ich sehe auch, daß Traffic vom Homeoffice auf dem Webproxy (der transparent konfiguriert ist) ankommt. Das war es aber dann auch schon. Es kommt etwas auf dem Webproxy an, es geht aber nichts mehr zurück. Die IPSec-Verbindung läuft im Kernel. Also keine Interfaces.

Grüße
Markus

P.S. über jeden Tip bin ich sehr dankbar.

[Monviech (Cedrik)]

Probiere doch mal das GRE interface aus. Vielleicht kannst du das im Webproxy auswählen? Dann könntest du GRE über IPsec Transport Mode machen. Ein Lancom unterstützt das sicherlich.

Hier hatte ich das gerade erst getestet:
https://forum.opnsense.org/index.php?topic=36319.0

EDIT:

Habe gerade nachgeschaut und ich kann GRE (Generic Routing Encapsulation), und WG (Wireguard) interfaces in Services: Web Proxy: Administration: Forward Proxy auswählen

Das IPsec VTI (ipsecXX) interface taucht nicht auf, genausowenig das (encXX) interface.

[Monviech (Cedrik)]

https://docs.opnsense.org/manual/how-tos/proxytransparent.html

Ich hab mir das ganze mal Näher angeschaut, auch im Code.

Die "Proxy interfaces" in "Forward Proxy" geben kein echtes Interface an die squid.conf Datei weiter. Sie lesen nur die IP Adressen auf einem Interface ein, und setzen diese IP Adressen dann in die squid.conf.

Wenn man z.B. LAN auswählt, und das LAN die 192.168.1.254/24 auf dem Interface konfiguriert hat, sieht das so aus.

Code Select Expand


squid.conf
# Setup regular listeners configuration
http_port 192.168.1.254:3128 intercept


Da das enc0 interface keine echte IP Adresse hat, gibt es hier diese einfache Möglichkeit:

Es steht aber noch folgende Regel in der squid.conf Datei:

Code Select Expand


# Setup transparent mode listeners on loopback interfaces
http_port 127.0.0.1:3128 intercept
http_port [::1]:3128 intercept


Ich denke, man kann das ankommende Netz wenn es auf dem IPsec (enc0) interface ankommt durch eine Port Forward Regel einfach auf 127.0.0.1:3128 weiterleiten.

EDIT: Ich baue das gerade mal als Testsetup nach. Die Port Forward Regel matched zwar (sieht man im Firewall log), aber keine Anfrage wird ins "/var/log/squid/access.log" geschrieben. Bis jetzt hab ich es noch nicht hinbekommen.

[mimugmail]

Du machst Portforward auf localhost und den Port und wählst zusätzlich zum LAN noch das IPsec Interface aus, das sollte reichen.

[Monviech (Cedrik)]

Ich hab das sehr viel getestet und bin auf einen alten Bug gestoßen. Es geht anscheinend technisch nicht. (rdr in pf auf localhost im ipsec oder enc interface)

https://forum.opnsense.org/index.php?topic=36024.msg177959#msg177959

[mimugmail]

Haben wir dafür nicht die reply-to Option in Advanced bei den rules? Ich glaub das kam für Wireguard, sollte für IPsec aber auch gelten

[Monviech (Cedrik)]

Bei einem Policy-Based IPsec Tunnel gibt es kein Gateway auf das man reply-to setzen könnte. Im Narkive Thread den ich verlinkt habe, wird davon geredet, dass bei Antwortpaketen keine ESP Transformierung stattfindet.

https://narkive.com/RiJhgUnH.6

[mimugmail]

Also in einem policy based IPsec geht nat auf jeden Fall in alle Richtungen. Bei VTI ist es eine known limitation, aber da kann der Port forward auch auf dem LAN passieren, wichtig ist nur dass IPsec als interface ausgewählt ist.

[Lochkartenknipser]

Erst mal vielen Dank für die Antworten.
Was Monviech getestet hatte mit einem forward von enc0 auf 127.0.0.1:3128 /3129 hatte ich auch viel Hoffung gesetzt und hatte das auch lange getestet. Aber ebenfalls ohne Erfolg.
Wenn ich das jetzt richtig verstanden habe, ist dies aktuell nicht möglich den IPSec Traffic transparent durch den Proxy zu schieben?

Grüße
Markus

[dmark]

Schuss ins Blaue: Hast Du die Tunnelnetze und/oder dein Heimnetz im Webproxy unter "Erlaubte Subnetze" eingetragen?

[Lochkartenknipser]

Hi dmark,
ja, das war das erste was ich gemacht hatte, als ich die Konfiguration begonnen hatte.