thanks @stephenw10 thats work exactly as it might be.

i found this for you @dennypage said in New Avahi package: Yes, this is intentional. There are no local mDNS browse clients for pfSense, so there isn't much use for dbus support on the firewall itself. Further dbus was the cause of a couple of significant issues, one being the minimum 5 second startup delay, and the other being a sporadic failure of Avahi to start at boot for many users. If you want to see what is in the network, I would recommend doing this from a general workstation or laptop in the network. This will also give you a better view into the overall functionality of reflection. There are several tools that support this. If you are a Mac user, then there is a free application called "Discovery" that is pretty nice. For a Unix based system, you can use avahi-discover (GUI) or avahi-browse (command line). I haven't used Windows in many years, but I'm sure there are some decent tools there as well.

@claferriere One thing I learned many years ago, suspect cables and connectors first, as they often fail.

There is a list posted in the IDS/IPS forum here that was created by some of the forum members. It is a pretty decent one in terms of suppressing most of the popular false positives. Might be that the list you posted actually originated from here, I don't recall all the individual rules on the posted list. The best way to suppress false positives in your setup is to put Snort in alert mode only (turn off Block Offenders) and let it run for at least a week, and maybe more, while analyzing your typical network traffic. Make it a point to review the alerts at least daily and more than once a day if possible. Remember that any generated alert is a block, so look at each alert and then use Google to find out what the alert really means if you are not sure. Use that info to construct your false positive list. Add rules to a Suppress List by clicking the plus (+) icon next to the rule's GID:SID value. If you want to disable the rule, click the red X. That is a more secure approach to creating a suppression/disabled list than copying somebody elses list off the Internet -- and that includes the list posted here ... . I'm just not a big advocate of copy-and-paste when it comes to IDS administration. Resist the urge to install Snort and immediately turn on blocking. That is almost guaranteed to generate blocks from false positives and create a headache for the security admin. Let it run for quite some time in IDS mode (intrustion detection) only without blocking so that you have an opportunity to see what alerts happen with your network traffic. From that list you can determine what you will consider OK to let pass and what you may want to block in the future. With that said, I will say that most admins turn off several of the more troublesome HTTP_INSPECT rules. You can find those in the alerts by both their GID (Generator ID) code and the fact the message will ususally start with the string (H_xxxxx) where the xxxxx is the particular HTTP_INSPECT section. The HTTP_INSPECT preprocessor rules will have either GID 119 or GID 120, depending on whether the rules are designed for the server (120) end or client (119) end of the conversation. But the HTTP_INSPECT preprocessor rules are not all bad. Here is something I found while doing some research recently: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/detecting-brazilian-banking-trojans-with-snort-http_inspect/.

check the openvpn manual under tunnel options : –remote host [port] [proto] there is no fixing that with PIA. this is why i dropped them and never looked back. but if you follow the command i posted it will reconnect you if you set it up properly

thanks alot.

Ok so that happens because your WAN 'ipaddr' is set to dhcp I assume? Is that an OpenVPN client or server? You may be able to workaround it by running that on a different interface, one that is static. Then port forwarding to it in the server case. Steve

@jimp said in New ping-based attack: This isn't relevant to pfSense in any way, as far as I can tell. It only affects FreeBSD 12, so it would not affect the current release, 2.4.4-p3, which is based on FreeBSD 11.2 It only affects the RACK TCP stack which is not used on pfSense 2.5.0 snapshots. This is an optional, non-default, TCP stack. The module for it is not built nor included in images. To use that stack, someone has to go out of their way to load the tcp_rack kernel module (which isn't on pfSense) and set net.inet.tcp.functions_default=rack (which on pfSense 2.5.0 is set to the default, freebsd) Good to know. Thanks.

Hi Guys It was the RED NIC playing silly buggers. Weird. I have since then replaced the whole PC with another one, and things are looking quite well. Will take a shufty at SSL filtering since that is what I need to do with the pfSense installation. Regards Ook

I can ping that IP too, was just pointing out that not all IPs will respond - so unless your are SURE it will and should, its not always a valid test.. So your traceroute is sending traffic for that IP out to your isp and internet. Do a sniff on your wan and validate you send out the syn on 80 to get to their site, or ping etc.. If that is the case then its not pfsense issue at all and something on your isp, the internet between your isp and that site, or the site themselves blocking your IP.. How many other sites can you not get to- are they all in the same netblock?

Ok. The only way I could see that rule doing anything is if you were running the OpenVPN clinet on pfSense and had assigned it as an interface and had the rule on that interface. But as I understand it you are running the OpenVPN client on the client machine behind pfSense. In that situation pfSense never sees the FTP traffic inside the tunnel at all. And outbound OpenVPN traffic from the client will always be allowed no matter what the block rules are set to on WAN. Is it the FTP connection over the tunnel that fails or that the OpenVPN tunnel fails to connect? Steve

@stephenw10 I think it is related to the P and C state settings in the BIOS. It is possible that I changed one of them and just forgot. P-state is the exact one I changed I think. It has to be set to its default value (HW_ALL irc). These may help: https://www.supermicro.com/support/faqs/faq.cfm?faq=29482 https://www.thomas-krenn.com/en/wiki/Processor_P-states_and_C-states

The hard part with doing this is parsing the output of commands to show what goes where, and also which commands do what. The GUI itself could mostly carry over, but there is a significant amount of work involved in writing the backend code that makes the magic happen. Unfortunately, the ZFS tools don't appear to support libXO which would make this much easier, too.

Ok Thanks, Each of the Network has is own DHCP enable I am going to apply your advices. And will give you the feedback

@stephenw10 Thank you. I have moved in similar lines, but it seems I have to configure a Gateway. This may be in contrast to what pfsense said in the field text "On local area network interfaces the upstream gateway should be "none"", I assumed ,I don't need to create a Upstream gateway. So i've created this Also, after creating the gateway, I've changed the Fireall -> NAT -> Outbound to Automatic outbound NAT rule generation. These two changes made it work. Thanks again

Correct. It works on the other FW's just fine, but this one, because it's the main, can't just be taken down when wanted. Too many other services behind it that can break and all teams need to be on board when a reboot is required in case those services really bork.

More information needed! Is that a service running behind pfSense? Have to setup port forwards? How are you testing? Where are you testing from? Steve

That seems like a good plan of attack. If you see it again and still have any sort of access check the config file size and the back configs in /conf/backup. When we saw it previously you could clearly see the file size ramping up in the backups as the rules duplicated. Steve

Hmm. Curious. Can you force UDP in Windows? Not sure I've ever tried.... Steve

Do you have the crash report? But yeah 2.3.X is EoL and 2.3.3 is even older than that. Whatever you're hitting if it's a software problem it will not be fixed in 2.3.X. It may well have already been fixed in 2.4.X. Steve