Yeah that bothers me because e.g much cheaper fortigate 60E gets 1Gbs easily. I would really like to know what other people are saying about that

@netblues Yeah you were on the money. Bound the OpenVPN client service to the CARP WAN VIP and failover/failback operates perfectly - as does all everything else. Perfect, thank you :) (better check my settings more thoroughly next time ;) )

Sorry, I should have included that, WAN (TP-Link) is re0 and LAN is em0.

Actually, surprisingly it seems to all be working with just the phase 2 networks set correctly.

From 2.1.5 or the upgraded 2.4.4p1? I would try to make it boot 2.4.4p1 directly, that's the path to getting up and running and being able to re-install etc. Were you able to note where it it is looping? Steve

@modesty said in SNORT: Hi i run on latest pfsense with installed pagages: squid snort pfBlockerNG Lightsquid bandwidthd and updated snort from 3.2.9.6_1 to 3.2.9.8_4 I get errors, here is my log. hope sombody can give me a hand: Upgrading pfSense-pkg-snort... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense-pkg-snort: 3.2.9.6_1 -> 3.2.9.8_4 [pfSense] Number of packages to be upgraded: 1 [1/1] Upgrading pfSense-pkg-snort from 3.2.9.6_1 to 3.2.9.8_4... [1/1] Extracting pfSense-pkg-snort-3.2.9.8_4: .......... done Removing snort components... Menu items... done. Services... done. Loading package instructions... pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/APACHE20 pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/LICENSE pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/catalog.mk pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/www/snort/snort_download_rules.php pkg-static: Fail to rename /var/db/snort/sidmods/.disablesid-sample.conf.WevUUm19O5CM -> /var/db/snort/sidmods/disablesid-sample.conf:No such file or directory Failed Are you by chance using a RAM disk for /tmp? This kind of issue can happen when you run out of free space in the /tmp tree. Packages need a lot of free space to download dependencies and such and then unzip them for installation. If you are using a RAM disk, then try bumping up the volume size to at least 256 MB. Is this repeatable? Do you get the same error if you retry the package installation?

Thanks so much. Good to know. Excuse my ignorance but I cannot completely reconcile your description of the ssl ciphers supported with Microsoft’s descriptions of their supported ciphers at release 1809 of Windows 10 at this url: https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-cipher-suites-in-windows-10-v1809 Would you mind glancing at their list and confirm an overlap? Perhaps then I might force a group policy to allow me to use https on windows 10. Again thanks for your time or anyone’s time on this issue. I will continue to investigate locally.

@stewart said in Huge Suricata Stats Logs: @bmeeks That's what I would expect, but instead I get: I can't tail or head it. It just sits there. So I copied off the log file and nano'ed it. I just checked and it is better. Color me confused... I have a fixed file ready if you are willing to test it for me. If you are, send me a PM (chat message). You might also consider increasing the stats collection interval for your setup. That's on the INTERFACE SETTINGS tab where you enable stats log generation. The default interval is 10 seconds. You could try increasing that to 60 seconds (or even a little more) to see if that helps control the rapid growth of the stats.log file.

Read the docs if you need more info. I've already explained it more than once.

Try this : grep "maxmind.com" /var/db/pfblockerng/dnsbl/*.txt /var/db/pfblockerng/dnsblorig/*.orig /var/unbound/pfb_dnsbl.conf /usr/local/pkg/pfblockerng/dnsbl_tld it provides some more info about pfblockerNG db.

I let my system run for just over a week and I noticed this evening that I couldn't access the interwebs for some reason. I restarted my pfSense computer and everything seemed to go back to normal. I then noticed a few minutes ago the following on the console: kernel 492.136807 [1071] netmap_grab_packets bad pkt at 878 len 4939 kernel 490.136919 [1071] netmap_grab_packets bad pkt at 667 len 4939 kernel 489.136703 [1071] netmap_grab_packets bad pkt at 933 len 4939 kernel 488.636876 [1071] netmap_grab_packets bad pkt at 875 len 4939 kernel 488.435620 [1071] netmap_grab_packets bad pkt at 806 len 4939 kernel 488.235492 [1071] netmap_grab_packets bad pkt at 766 len 4939 Interesting. I guess I'm going to have to bump up my dev.netmap.buf_size from 4096 to a larger value. I have 64 Gig or RAM in my pfSense comptuer so maybe I'll bump it up to 8192 and see how that works. Has anyone had a related experience after tuning their system? Update - Since changing the buffer size to 8192, I've noticed webpages load a tad slower.

Okay, I think this is because I've been modifying the firewall so rule numbers are changing, but the states don't get modified to reflect that.

@stevetoza said in New pfsense router - setup openvpn which encryption for AES-NI: @KOM - thanks for the reply, what defaults would you choose? The default ones.

Because you installed it "offline" and not from the pfSense repository, it won't display in the GUI list. https://www.netgate.com/docs/pfsense/releases/2-4-4-new-features-and-changes.html#errata

Not currently. We don't build packages for python 3.x. You could maybe install them from FreeBSD but I wouldn't do that on a production firewall.

@johnpoz said in DNS Resolver host overrides don't work SOMETIMES: Your MTA should not expect to get back additional, and should do the query - but now it sounds like you were getting leakage of additional as your problem? Forget about MTA. MTA does not do DNS queries itself. It relies either on local system resolver or local caching DNS server. Here is problem in short. I expect to have mail.domain.tld to be 10.1.80.4 in my LAN. I create this override on pfSense. I have local (caching & authoritative) DNS server (and domain controller at same time) and I point it to pfSense as DNS forwarder. Let's call it DC1 All local PCs/servers have DC1 as DNS server. I have Zimbra, on Zimbra for DNS server I use DC1 (as on all other PCs/servers). Query: Zimbra -> DC1: give me MX for domain.tld? Query: DC1 -> pfSense: give me MX for domain.tld? Reply: pfSense -> DC1: MX for domain.tld is mail.domain.tld AND mail.domain.tld IP is 1.2.3.4 (external IP). Now DC1's cache is polluted with wrong IP for mail.domain.tld Reply: DC1 -> Zimbra: MX for domain.tld is mail.domain.tld AND mail.domain.tld IP is 1.2.3.4 Now Zimbra's cache is polluted with wrong IP for mail.domain.tld If I clean DNS cache on Zimbra, I still get wrong IP as a reply to simple A query because DC1's DNS cache is still polluted with it. And this breaks things!

@tac57 I don't use Plex anymore, so no comments, sorry

I take it the "3 emails a day" are being sent by your mail server software to alert you? If it is from random senders I would consider those phishing emails. Any mail server with ports open to the Internet is going to see a lot of attack attempts. If you have a lockout after 5 incorrect passwords they will likely give up and move on. Suricata or Snort can try to block those attempts, yes. They can be set up so if an alert is triggered the IP is blocked for the desired amount of time. Generally for in-office mail servers, we set our clients up with our spam filtering service, and in pfSense only allow connections on port 25 from the filtering service IPs. So the world cannot just connect to the mail server.

Aside from an older bug https://forum.netgate.com/topic/130980/suricata-not-limiting-log-sizes-by-default Suricata shouldn't use much disk space. I checked a client's SG-3100 and Disk Usage on the pfSense home page shows "24% of 7.0GiB."

@sensori said in Suddenly no internet connection for clients: I've also noticed on the dashboard that the WAN was set to only 100 mbit although the NIC supports 1000 mbit. You don't normally set that. Autonegotiation determines the appropriate rate automagically. Perhaps you should be asking why it's only 100 Mb. A bad cable is a good bet. In fact, by trying to set it, you may cause problems, if the other end is set to autonegotiate.

I would not expect that unless you're saturating the link which you clearly aren't using Plex. What is the WAN monitoring? Try choosing some other external IP if it's still set to use the gateway IP. Steve

Como ninguém pode me ajudar irei colocar como solucionei. Criei as duas redes (Fibras) e fiz as regras de ida/volta de cada fibra na rede local (Firewall/Rules/LAN). Obrigado, pode fechar o tópico.

Да, у меня возникла мысль, а вообще это реально реализовать?

Reinstalei o pfsense do zero coloquei a versão 2.4.4_1 mas o problema persiste agora na instalação não vi que veio sem Swap encheu o disco, você sabe se eu consigo deixar esse script apenas limpando o cache e não reiniciando o squid, aqui tenho o problema de reiniciar o Squid e as vezes ter que reiniciar o Squid Guard para a navegação voltar.

@yyz I think my original question was poorly asked. Please ignore

hocam öncelikle cevap için teşekkür ederim. oluşturduğum poolların tamamı 192.168.1.0 networkü içerisinde bir gruba 1.10-1.50 arasını verdim diğerlerinide bölüştürdüm mac ile kontrol yapıp ip dağıtıyor rules ilede her grubu alias olarak tanımlayıp her gruba bir gateway tanımladım. vlan oluşturmayı bende düşündüm fakat sw ler managment değiller o nedenle vazgeçtim. sizin söylediğinizi başlangıçta düşündüm networkleri ayırmayı 1.1 2.1 3.1 şeklinde fakat bu konfigrasyona göre dhcp yi yapılandıramadım sürekli aynı bloktan pool oluşturabileceğime dair uyarı verdi

What would fail with bogon still blocked is bogon's - but pretty sure pfsense pulls the rfc1918 space that is normally in bogon out... And lists in the different rfc1918 listing. rfc1918 is a bogon ;) Well if you want to get technical about its - better term is prob martian...

@fmertz This setup works fine. Your saying it should not?

@grimson said in Restore a new ZFS install from a config file made on a UFS install: Shouln't be a problem, though I haven't tried it myself: https://www.freebsd.org/doc/handbook/zfs-zpool.html the only thing that might be a bit risky is updating the bootcode with the correct one if you use UEFI boot. On the other hand, reinstalling pfSense with config recovery is likely to be equally as fast, if not faster Well shoot, i was thinking it would be easier than that. Oh well, guess I'll look into installing another harddrive and do this again:)

Very strange. At least you have a workaround.

Where was that packet capture taken? Was it filtered? It looks like pfSense is losing ARP for the upstream device from the logs but I don't see it ARPing for it in the pcap. At least not wherever that was taken. Check other interfaces. Maybe you have some conflict there. Steve

I somehow had something wrong with the Interfaces that caused it to crash, reconnecting WAN and PPPOE fixed it. I will try with the problematic onboard NIC later, the new NIC which is a em3@pci0:2:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet works perfectly fine aswell.

Is this related to https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#upgrading-from-versions-older-than-pfsense-2-4-4 : "Gateway handling changes in 2.4.4 may result in different default gateway behavior than previous releases. Nearly all cases should behave properly, but be aware that it may be necessary to re-select the default gateway after upgrade."