@JonathanLee tls 1.3 has been used for quite some time.. Any time I bother to look at the connection to pretty much anything its tls 1.3.. This connection to the forums is using tls 1.3

ensi is dead but long live ech, that could be problematic I would bet..

But again I don't do any sort of mitm, its not good practice - I want my ssl/tls to be end to end.. As the internet gods intended it to be ;)

I have no need or desire to run a proxy.. If I want to block someting I would filter on IP or DNS.. Yes I block the bane of filtering doh and dot.

I run a reverse proxy, but not as a filtering method or as a way to do mitm.. But as a way to offload the ssl connection because the actual services have no ssl support at all, or are a pain to setup. These connections are tls 1.3.. And I don't even allow 1.2, if your not using 1.3 then your not accessing it. And use strict sni - so if you don't send the valid sni your not being proxied in either. This keeps rando port scanners from being able to actually get to the sites interface.

And I block most of the known scanners from talking to any of my forwards anyway, and only allow access into my forwards if your coming from US IP, etc.

Did anyone manage to get these ports working on pf+ 24.03?

I just came across the deprecation warnings.. Good thing I'm still on 23.09...

Also, can we somehow verify what we're installing?

I don't really feel confident adding an unknown repo to my firewall, which contains all pfsense packages, just to install the Squid one.

@lg1980, and all others reading the thread, I hope you can understand why I'm questioning all this work.

Squid is a very specific package used mainly for monitoring outbound traffic. From the perspective of a malicious threat actor, it's obvious how hiding a backdoor in such a package can prove to be highly beneficial, especially now since Netgate is deprecating their port of package, making all Squid users scramble for solutions so their appliance doesn't fall behind on updates.

What I'm trying to say, having full build instructions, and being able to reproduce those locally, would greatly boost my confidence in using packages from a fellow "internet forum user".

In our current state of affairs of having no "official Squid package port", the only true way of securely upgrading Squid, as far as I can see, would be by being able to inspect the source changes, while also being able to build the package locally from source, and installing it manually.

Hence I assume that the entire pfsense Squid community would be extremely grateful if @lg1980 could share instructions on how to do so!

@JonathanLee sorry if I wasn't clear. No, one URL should be enough

@terdexx89 said in pfsense : forward all LAN traffic to a proxy:

android phone connected to a proxy and make a vpn connection

Ok I'm a bit confused - are you saying your phone can not connect to this vpn connection unless it bounces off this proxy?

If pfsense can make a vpn connection to where your phone is connecting or any other vpn service on the internet, then you could route all clients behind pfsense through this vpn.. This is just a client vpn connection on pfsense and people do this all the time..

Pfsense does have the ability to use an upstream proxy, but I am not sure if it would then route its vpn connection through this proxy?

https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#proxy-support

I take it your goal is to use pfsense to route your device behind pfsense through the vpn connection? Which users do all the time. What I am confused about is the added proxy? My understanding of the upstream proxy feature of pfsense is so pfsense can access updates and packages. I am not clear on if you set this upstream proxy, and then setup a client vpn connection in pfsense if it would make that connection through the proxy.

But once pfsense has this vpn connection, it is quite simple to route devices behind pfsense through this vpn connection.

edit:
If you want your vpn client on pfsense to bounce off a proxy, those settings are in the vpn client setup

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-client.html#proxy-settings

@atxcoder you need a Web Application Firewall (WAF) to do that, pfsense FW rules block at the ip layer. x-real-ip is application layer. The traffic is allowed because it came from 10.0.10.4.

@ma0f97 Has no one an idea?

@rtw915 said in WAN optimization/acceleration:

Now the SQL team needs me to find a way to improve SQL linked server transfer rates to synchronize transactions.

This will bring you back to the initial wan accelerator solution.
The only other possible solution is to redesing the db subsystem, utilizing some way of sql replication, taking into consideration propagation delays

So you just need to redirect traffic to them in pfSense? You can just use port forwards for that. That's what Squid does if you set it to transparent mode.

Steve

@lucasll había puesto el IP y puerto del kerio en Advanced - Miscellaneus del pfsense pero ya encontré la solución. Mi DNS superior no resolvía las direcciones fuera de la VPN. Utilicé un repositorio alternativo que el DNS era capaz de resolver.

@norcarde A transparent proxy would solve your application problems, but they are a hassle to setup and can introduce their own problems.

@santi buen día. Ya revisé el log. Dónde obtuve la ip a la cual de está conectado, la agregue a la lista blanca, además, del puerto. Pero sigue sin funcionar .

@PiBa Good news, I got it to work! I did as you suggested and got a self signed certificate on the server using this guide. After that HAProxy is able to route traffic to the host. It even works with the Let's Encrypt wildcard cert I have through the ACME package, so there's no cert errors getting to the site. Thank you for the help again.

@jimp could you point me in the right direction how to setup so HAProxy on pfSense handels the certs ( not just getting them )

@juanmaximoti Como conseguiu liberar?

You can still do some filtering on HTTPS without the MITM. On E2 Guardian, I have multiple groups setup, some which have MITM enabled and some such as in your case that are for Guest Wi-Fi where I can't properly sneak in the CA. On Squid I believe this is referred to as Bump and Splice all.

For my guest Wi-Fi setups, I just use the non-MITM method. This is where the proxy is able to see the domain name without the resource path at the end in order to decide if a website should be let through or not. MITM would obviously allow the proxy to look at the entire URL with the resource path and make a informed decision as to whether or not to allow a website through. I prefer it way more than DNS level filtering as it's more flexible. You can set it up for specific users while others can browse those sites just fine.

If you've got sometime, I recommend you give E2 Guardian a shot. It worked out a lot better than Squid in my use case and it has the added benefit of actual phrase filtering.