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

Thanks Rico ! / br. Pete

That's what I was thinking. I wasn't sure if there was any kind of exotic configs that might work just as well. I now need a POE+ switch so I might be upgrading the 3750 at some point. I think Cisco changed their licensing model on the 3850s and the cat9k making it harder to deal with as a home user. I like Cisco but it is expensive for home use. I really do like L3 multicast though, so that helps justify it.

For the scenario of connecting directly to pfsense router instead of the switch, I think I will be able to figure this out based on this video: https://www.youtube.com/watch?time_continue=249&v=XdzfgapJYqw Will do testing and report if any issues arise!

@jimp said in User Manager Access: b9ed452dbba4689e6280efa7f503e30809a3d8e4 Updated mine to fix this issue, really appreciate that you posted this!!

Oh.. My bad, apologies. Thank you for such a quick reply!