A CD that would offer this : @k.p.k.gupta@gmail.com: ….always up-to-date list of packages …. ;D

What do you need to do?

It depends what you're using Snort for. If you use it to collect data on traffic and aggregate that somewhere centrally you might not need to block that. Most people would have it in blocking mode though. Once you have the ruleset tuned you should not see many false positives. I usually recommend you run it in non-blocking mode for a week or so and review the logs. Whitelist or disable the rule on anything that shouldn't be alerting. Then go to blocking mode. You can also set the block time to something low enough that it will restore in a reasonable time. Steve

The updates are delivered via pkg, so they have to show as being available that way. pfSense-upgrade does some extra things that make sure it all goes smoothly. You could, in theory, update most if not all things via pkg, but it's not ideal to do it that way since the kernel package will be locked (which pkg tells you if you run it directly), and you could potentially have some weirdness with having a mismatched kernel and base. For a minor update like 2.3.4 to 2.3.4-p1 it wouldn't cause you much if any harm to do it via pkg, but we still recommend using pfSense-upgrade. And yes, pkg is the standard for FreeBSD but, though the pfSense distribution is based on FreeBSD, it is not FreeBSD, so expectations must be adjusted accordingly.

You want this one: https://nyifiles.pfsense.org/mirror/downloads/pfSense-CE-memstick-ADI-2.3.4-RELEASE-amd64.img.gz 4GB is not that large but it will do fine with a default install as long as you don't go nuts with packages, caching, and logs (including package logs). If the 4860 is still serving your needs it takes an mSATA. You might consider investing $60 in one and having 120GB SATA storage instead…. https://www.amazon.com/dp/B00CG8GTPO/

When DNS fails like that it's usually because the clients are using one of the DNS servers on pfSense and that is not configured to use both WANs. By default pfSense runs Unbound in resolving mode. In that configuration Unbound itself always uses the default route so if that was the Comcast link in this case it would have failed and no clients using it could resolve IPs. To avoid that either use forwarding mode in Unbound or switch to the DNS forwarder and make sure you have upstream DNS servers defined against both WANs in System > General. Or alternatively enable default gateway switching in System > Advanced > Misc. Using DNS forwarding is usually preferable to avoid traffic on the wrong WAN after a failover. Steve

Sounds similar to what I was seeing after 2.3.4_1 when browsing the Suricata menus everything is working I submitted my crash reports

@johnpoz: yes every network has a broadcast IP 192.168.0/24 would be 192.168.0.255, but what MAC address do you think that goes too?? See attached is a broadcast to the network broadcast address .255 - look at the MAC.. That is a directed broadcast, but dhcp would be a full broadcast to 0.0.0.0 same all F's mac.. How exactly are you going to run 2 dhcps on the same wire on pfsense??  So even if you deny all on one, and reversed the deny on the other so your devices could only get their reservations.  Pfsense will not let you run them in such a borked configuration.. If you want to do the borked config vs doing it correctly, then you would have to setup static IPs for everything.. Or run the second dhcp on something else other than pfsense and then limit what the dhcp servers will hand out IPs for.. If your going to go to all of that trouble - prob just be easier to setup static IPs on the devices themselves, etc. Good luck! Yes exactly that's what I wrote more or less as well. :) So not really worth doing right now but will have to do some thinking on what I should do. Thanks for your help.

Are you able to post screenshots of the issue you were having? The easiest thing there is just to reboot the install though. 2.4 now uses the FreeBSD installer so things are different there. You may want to try that to see if whatever issue you hit is still present. Steve

ive logged a bug on this issue:  https://redmine.pfsense.org/issues/7730

The only section of the config that should ever be restored individually in the versions are different is system. That's the only section that contains the version information required to run to appropriate update scripts. Can we see the console log showing the exact point it stops booting? The most common reason for that is some console setting in the restored config changing the output such as serial speed or serial/video console. Steve

I'm running pfsense 2.3.4 on ESXi 6.5. I'm using VM version 13, Open-VM-Tools package 10.1.0,1 and VMXNET 3 NICs. All that is working well for me.

The Netgate Device Id isn't present anywhere in the sticker or packaging. I've PMd you with S/N and MAC if that helps. Thank you.

Frankly, the minimum hardware requirements for 2.3.x have outgrown that box, and it isn't capable of running 2.4 at all. If you start from a freshly imaged CF and restore your configuration it may run, but you'll need to watch what features you have enabled carefully, and probably not have any packages.

From your description it sounds like you have current support on that in which case use: https://portal.pfsense.org/firmware/memstick/pfSense-netgate-memstick-ADI-2.3.4-RELEASE-p1-amd64.img.gz Steve

I have used  TP-Link  TG-3468  cards in three  Pfs  setups and they were always recognised.    In all cases the motherboards were / are  Gigabyte.    So, I can confirm that the card should be recognised,  perhaps it's damaged or there is a motherboard fault. J

Updated client side. Nothing works anymore. … Strange thing is, VPN is up and running. Everything seems normal. Is it working or not? ERROR: FreeBSD route add command failed: external program exited with error status: 1 That generally means there is an existing route in the system that conflicts with a route that OpenVPN is trying to add so OpenVPN cannot add it. It is generally a soft failure unless it happens to be a conflict with the actual tunnel network which can prevent OpenVPN from starting. That very likely has more to do with the reboot after the update putting the route there than the upgrade to 2.3.4_1. Stop the OpenVPN client process and look at the routing table. Start the OpenVPN client and examine the logs. If you set the logging verbosity to 4 it will show you which route it is trying to add. These are the entries with an intentional conflict created (Static route in the system for 10.100.100.0/24 and also listing it as a remote network in an OpenVPN client): Jul 23 19:09:36 openvpn 71076 /sbin/route add -net 172.25.232.0 10.10.10.1 255.255.255.0 Jul 23 19:09:36 openvpn 71076 /sbin/route add -net 10.100.100.0 10.10.10.1 255.255.255.0 Jul 23 19:09:36 openvpn 71076 ERROR: FreeBSD route add command failed: external program exited with error status: 1