IPsec traffic Webproxy

[mimugmail]

Also das ist ein route-based Tunnel 0.0.0.0 auf 0.0.0.0 und du hast auf Site-A  einen Portforward dass Site-B wenn es nach 0.0.0.0 per 443 oder 80 wollen auf localhost:proxy ports weitergeleitet werden? Hast du da n Screenshot?

[Lochkartenknipser]

Hallo mimugmail,
der route-based Tunnel ist 0.0.0.0 auf 0.0.0.0 damit der Internettraffic durch den Tunnel geht. auf der Seite mit der OPNsense wird der Traffic per NAT in den Webproxy geleitet. Die Regeln sind auf dem Screenshot aus, da sonst mein Internet im Homeoffice nicht funktioniert. Ich habe die NAT-Regeln zum Testen schon in alle Richtungen verbogen.

[mimugmail]

Also wenn die Regel aktivierst, mach doch mal ein Packet Capture auf 3129 und schau ob wenigstens ein syn am Proxy localhost ankommt

[Monviech (Cedrik)]

@mimugmail
Hast du selber schon den Webproxy über IPsec am laufen? Weil ich bin da echt kläglich dran gescheitert und hab einen halben Tag damit verbracht. Ich habe mich in der letzten Zeit auch sehr intensiv mit dem IPsec + NAT Thema in FreeBSD auseinandergesetzt.

Ich habe es allerdings nur mit Policy-Based IPsec versucht, nicht mit VTI. Ich wollte mein Handy über den Webproxy jagen, der war mein Testclient.

Falls du den Webproxy über IPsec irgendwo am laufen hast, ich würde gerne die Einstellungen sehen die es ermöglichen.

Zum Thema packet capture, mit tcpdump konnte ich nie Pakete auf lo0 mitschneiden die auf den Port des Proxyservers gingen, der RDR Traffic war für mich unsichtbar wenn er an den Webproxy gesendet wurde (auch wenn der Webproxy richtig funktionierte in anderen Netzen)
Ich wollte auch letztens NATD Socket Traffic mitschneiden der an lo0 gesendet wurde und das konnte ich auch nicht.

[mimugmail]

Ne, hatte ich so bisher nicht. Ich kenne nur Setups wo die OPN die eigentlich nat machen soll, per policy rule alles an eine OPN im LAN schickt (virtuell) und dort der Proxy läuft :)

[Monviech (Cedrik)]

Ja den Squid auszulagern ist eine Lösung, weil es wohl anders nicht funktioniert (mit IPsec und RDR auf localhost).

Noch eine Möglichkeit wäre wohl, keinen Transparenten Proxy einzusetzen, sondern den Proxy explizit im Client einzutragen. Dann wird der Traffic zum Squid Socket geroutet und das funktioniert mit IPsec ja hoffentlich ohne Probleme (z.B. auf den LAN Socket der in einer SA und den Traffic Selectoren drin ist).

Hier muss man halt auch aufpassen, dass IPv6 Traffic zum Proxy hingeroutet wird. Außerdem dürfte Webproxy durch das QUIC Protokol immer schwerer werden. Alles was irgendwie Google ist geht knallhart über UDP 443 wenn es kann.