One of the motivations is blocking intrusive or unsafe scripts and datamining. Much of that can be blocked with conventional adblockers; where it gets difficult is when third-party scripts from advertising companies are used (e.g. jquery), which the website needs to work properly or at all. That's an interesting point about https connections, but it's not usually an issue in the above cases, mostly because a lot of sites still don't use https, but also because when connecting to a medium-sized website with say 20 different server connections, some might be encrypted, but not all, and especially not the scripts with known content. Anyway, back to the technical requirements: can squid handle the redirection and serve up pre-installed scripts, or would I need unbound/bind for the DNS or possibly a webserver like nginx as well?

My guess is that under VPN/ OpenVPN / Clients the option "Don't Pull Routes" (and "Don't add/remove routes") are unchecked. I've observed that in that case the VPN will take over as default when you start it. There are more than one ways of solving your problem which will result in slightly different configurations. If you leave the above mentioned options unchecked, you have to modify your LAN firewall rules and specifically select the WAN gateway for the "Default allow LAN rule to any rule". In this scenario, if you go to a DNS leak website on a device that goes through the WAN interface, you'll see the IP given by your ISP (as you should) and when you do a DNS test you'll see your VPN's DNS servers (correct me if I'm wrong). If that's OK with you, you're done because you definitely won't have DNS leaks on your VPN's side. If that's a problem, I found the following to be working: Check the option "Don't Pull Routes". This will result in the following: you won't have to specify the WAN gateway for the "Default allow LAN rule to any rule" since the VPN won't take over as default when enabled. The results on the DNS leak page will show your ISP - also for the devices going through your VPN. In order the fix the leak, you can give devices that you want to go through VPN a static IP and then manually specify your VPN's DNS servers under Services / DHCP Server at the bottom "DHCP Static Mappings for this Interface". Finally, as a precaution you can set up a firewall rule as outlined under "9 - firewall rules" in this post: https://forum.pfsense.org/index.php?topic=106305.0 (this how-to is generally pretty helpful with the issue). Keep in mind that I'm fairly new to networking and pfSense (started this project just a month ago), so someone more experienced might have even better or more accurate info. At any rate, hope the above will help.

Hello. We werent logging the system log (we are now - but the issue hasnt occurred again as the load hasnt been high enough yet), but on looking at the graphs it never exceeds 75% of max. I have increased some defaults as they seem like common sense (the blackhole change is to allow the Java/SQL to fail quicker): Firewall Maximum States 1,000,000 (was 398,000) net.inet.tcp.blackhole Drop packets to closed TCP ports without returning a RST 1 (was 2) kern.ipc.nmbclusters 262,144 (was 131,072) kern.maxfiles 1,000,000 (was 127,587) kern.maxfilesperproc 500,000 (was 114,822) kern.ipc.soacceptqueue 1,024  (was 128) Any other ideas please? Thanks

Services -> DNS Resolver -> General Settings add a host overide if your using pfsense for DNS.

Hey John! With a little bit of research and determination most problems seem to be solvable  ;) Anyways, just wanted to keep you updated since in the meantime I managed to better understand what the the issue was (besides my lack of communicating it properly) and to solve it. I tried to understand the DNS forwarder/resolver a little better and while I'm not fully there yet, I have a bit of an idea (which helped me refine my research) Now, I saw that I'm not the first one that asked this question and in fact you already tried to help another user with the issue (https://forum.pfsense.org/index.php?topic=105194.msg591337#msg591337) Should this question be asked in the future, another kind user created a tutorial to solve it (for reference: https://forum.pfsense.org/index.php?topic=106305.0) As for as checking a DNS leak website is concerned to see whether everything is configured properly, the following happened to me before finding the above linked solution: Enable VPN: clients set up to use the VPN: no leaks, the results on the site are the VPN providers DNS servers clients NOT using the VPN: their IP (from the ISP) doesn't match the results on the leak site, since the site also shows the VPN providers DNS servers as the result If I'm not mistaken this is normal if the "Don't pull routes" option is NOT selected (selecting this would only result in DNS leaks for clients using the VPN). If I understand correctly, the solution provided in the above link simply prevents the VPN to access the DNS resolver? While the solution works as far as the results on the DNS leak page are concerned, it now takes quite a bit longer (2-3 seconds) to resolve addresses when using the VPN. I guess that might be normal behavior as well? (Edit: just needed to restart networkmanager - everything working as it should) I'll try to optimize the setup further and I hope with the links mentioned above we can prevent future headaches should others run into the same issue.

not that i can tell. I think this is some kind of malfunction with my WAN's DHCP client system.  the last log I have is from a number of days ago. [2.3.2-RELEASE][root@pfSense]/etc: tail -f /var/log/dhcpd.log Dec 19 09:46:11 pfSense dhcpleases: Sending HUP signal to dns daemon(72984) Dec 19 09:46:11 pfSense dhcpd: DHCPREQUEST for 192.168.69.162 from 58:82:a8:a1:27:5d (XboxOne) via re1 Dec 19 09:46:11 pfSense dhcpd: DHCPACK on 192.168.69.162 to 58:82:a8:a1:27:5d (XboxOne) via re1 Dec 19 09:46:11 pfSense dhcpleases: Sending HUP signal to dns daemon(72984) Dec 19 09:50:57 pfSense dhcpd: DHCPREQUEST for 192.168.69.100 from cc:4e:ec:13:91:46 via re1 Dec 19 09:50:57 pfSense dhcpd: DHCPACK on 192.168.69.100 to cc:4e:ec:13:91:46 via re1 Dec 19 09:50:57 pfSense dhcpleases: Sending HUP signal to dns daemon(72984) Dec 19 09:54:53 pfSense dhcpd: Wrote 0 deleted host decls to leases file. Dec 19 09:54:53 pfSense dhcpd: Wrote 0 new dynamic host decls to leases file. Dec 19 09:54:53 pfSense dhcpd: Wrote 24 leases to leases file. and on bootup, syslogd reports: syslogd: /var/log/dhcpd.log: operation not supported by device im not sure what device it refers to, possibly my pfsense is just not renewing my lease?  I dont believe im out of space: [2.3.2-RELEASE][root@pfSense]/etc: df -h Filesystem                    Size    Used  Avail Capacity  Mounted on /dev/ufsid/581cf7092c4a4990    186G    1.4G    169G    1%    / devfs                          1.0K    1.0K      0B  100%    /dev /dev/md0                      3.4M    112K    3.0M    3%    /var/run devfs                          1.0K    1.0K      0B  100%    /var/dhcpd/dev [2.3.2-RELEASE][root@pfSense]/etc: well, the /var/db/ has dhclient.leases.re0 and its got todays date on it and it appears to have a good lease in it hmm… ???

Never mind. I fixed the issue by removing the spoofed MAC address form the psSense settings and then cycling power on my cable modem. Why didn't I think of trying that before posting?

The server is a HP Proliant ML310e Gen8, was purchased less than 1 year, I had already switched the hard drive last month, the last time the problem had happened. Since the problem has happened again, it must be something else. I think the way is to upgrade to the newer version of pfsense.

[PC] ------------------- [ Switch ] ------ [APU] 192.168.1.18                                    192.168.1.254 It should be more like this, through the APU and not in another way. WAN throughput: PC (iPerf server) –-------- Switch ---------- WAN Port--[APU]–LAN Port--PC (iPerf client) LAN throughput: APU –-------- PC1 (iPerf client) und PC2 (iPerf server) direct on APU

You don't, why'd you do such thing in the first place? The only thing it's used for is Squid proxy and that has a GUI configuration for ClamAV.

that's sad though

https://forum.pfsense.org/index.php?topic=105184.0 https://forum.pfsense.org/index.php?topic=7668.0

please try out 115200 8/1/N this must be set up in putty on your pc or laptop and it is the default in pfSense.

Here is the tutorial to use windows certificate on pfSense: https://forum.pfsense.org/index.php?topic=112938.msg628407#msg628407