Hi! The only requirement would be to reassign the interfaces. What do you do when they are not an exact match? My pfSense box is behaving very erratically (my guess is bad caps on the motherboard) and I tried to, temporarily, setup a new box… Unfortunately even though both machines were more or less from the same era (Atom 330) they had different slots (PCIe vs PCI) and my real pfSense box had a mini-PCIe wireless NIC (Atheros based). They also had different onboard NICs... My real box has a PCIe Intel I340-T4 quad NIC and in the temporary replacement box I decided to reuse the old PCI Intel 21143 quad NIC I used in my previous non-pfSense based firewall. The onboard NIC was not used in my real pfSense box so I assigned it to the onboard NIC of the new machine. My WAN, LAN and DMZ which were provided by my I340-T4 were easy to match to to equivalent ports on the Intel 21143 based NIC... The last port on the I340-T4 I was no longer using. I used to use it to connect a wireless access point. The onboard mini-PCIe wifi card I could not match to anything... I am not sure if I was immediately able to delete it so it is possible I temporarily assigned to another port, I am not sure... Once everything was done I deleted the unused onboard NIC (which I had created anyway) and the port assigned to the wifi... What I ended up with was able to connect to the Internet since I was able to ping outside IPs but none of my Internal DNSes were working anymore... I also had this error message (or variants on it): There were error(s) loading the rules: /tmp/rules.debug:85: syntax error - The line in question reads [85]:  altq on  priq queue {  qLink,  qACK,  qVoIP  } I believe this is traffic shapping stuff… Obviously it was quite unhappy about something I had done.... Was it the cause of my internal DNSes not working? I don't know and could not investigate further when I tried this... I had to go back to the unstable box until I have time to try this again... Thank you and have a nice day! Season's Greetings! Nick

@singerie: Any update on netmap-fwd ? https://forum.pfsense.org/index.php?topic=119285.0

Hey BlueKobold, thank you for your suggestions. We also just recieved an answer from the pfSense-Support. But i will answer your Questions as good i can :) @BlueKobold: We use iperf to test the throughput between the firewall and a virtual machine. Are they both in a VM? I mean pfSense and the virtual server? We tried both of them. The virtual firewalls most limited by there amount of cpus and often by the featuresets. After activating TSO and LRO we also reach 5GBit/s with the virtual pfsense. @BlueKobold: If the firewall is the "Server" and the virtual machine is the "client" we only get a throuput about 3GBit/s. In normal you will be getting something between 2 GBit/s and 3 GBit/s as throughput in real life, from a 10 GBit/s link. Yes, of course we are talking about a theoretical throughput, but i would expect a similar throughput in both sides of communication, right? @BlueKobold: If we send from the firewall to the virtual machine we reach a throughput about 8/9 GBit/s. Perhaps the virtual machine is able to write the data faster then the pfSense, because there are a RAID in or more RAM that is acting as buffer for the packets, might this be? We never send a real amount of data over the cable :) with iperf you send an amount of packets with embedded timestamps and sequence numbers. With this content iperf calculates his statistics. @BlueKobold: It does not matter if it is a virtual or a hardware pfSense. It does for sure! How many cpu cores are given to the pfSense machine? See my answer above. Of course it matters, because of the amount of cpu - i had to be more specific i think ;) I mean, it does not matter with the strange behavior of different throughput. But as i said before, when the firewall sends his packets, it expect an ACK after everyone, the vm does not. So we activate TSO and now the firewall dont expect that anymore - just TSO @BlueKobold: We just activate TSO and LRO on the pfsense. Tunings can be often helping much more then we all would expect from! high up the mbuf size shorten down the NIC queues to 4 till 6 and other options or tunings might be helping also, please give them a try out, single or together! Anyone an idea or some experience with that features on a pfsense? Tuning and Troubleshooting Network Cards I checked that article, everything was okay. Tuning the machine is the first i thought about. Troubleshooting the second ;) BlueKobold, thank you very much for your help.

I'd strongly suggest flashing the thing with DD-WRT/LEDE/OpenWRT if at all possible. The factory firmwares are utter crap.

It's probably a filesystem panic. The site hosting that video is complete shit, serving malvertising trying to get people to install fake antivirus programs. Wipe and reload pfSense, restore the backup.

@viragomann: Check if pfSense has changed the outbound NAT rule to fit to the new subnet if you use automatic rule generation. If you have set it to manually rule gen the rules has to changed by yourself in any case. Thanks for the reply.  I will check it this week and let you know.

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.