Crashed again.
Any idea what else I might do to aid debug?

I split your posts off to a new topic since, although it was a crash, it was nowhere near the same crash.

Yours is crashing in the NIC driver while processing an interrupt from a vr(4) NIC. Those Via Rhine NICs are very, very old (They're only 10/100!) and were never all that reliable. I would strongly suggest replacing that NIC with a quality Intel NIC gigabit NIC. And replace those Realtek NICs while you are at it.

There are existing examples in the code for doing this as well. Start here:

https://github.com/pfsense/pfsense/blob/master/src/usr/local/bin/easyrule
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/easyrule.inc

Yeah if your running your esxi in your own lab with your own vms - I wouldn't use any of the mitigation anything for this family of exploits.. If there is any possible performance hit.. Which most all of these mitigations are.. Some can be a pretty stiff hit..

Do you recall when meltdown first came out.. Lots of hoopla about that.. Even though most use cases of pfsense would have zero need for concern with such an attack vector..

Lots of traffic about it here and elsewhere, etc.. negate put out this blog back Jan of 2018
https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html

The important take away
Most of our users should not be concerned as long as they follow our basic guidelines for limiting access to the WebGUI, shell as well as physical access to the pfSense appliance.

Same goes for all of these sorts of exploits..

@kiokoman said in Here we go again.:

uhm i knew it was coming neverthless it was somehow funny 😂

Exactly what she said yesterday....

You have to declare each level of the hash/array as you go. Like this:

$config['vlans'] = array(); $config['vlans']['vlan'] = array(); $config['vlans']['vlan'][] = $newvlan;

There is a convenience function that can help:

init_config_arr(array('vlans', 'vlan')); $config['vlans']['vlan'][] = $newvlan;

That function only initializes the arrays if they are unset/don't exist/are not arrays so it's safe to run unconditionally.

@Gertjan Updated OpenvpnClientExport package and checkbox works fine now. Dumb me.

On a cert, it's the refid of the CA that signed the cert. So it's copied from the CA refid.

I'm runing pfsense at a Intel(R) Core(TM) i5-5250U CPU. CPU load is low, RAM usage 23% out of 8GB. Google DNS is blocked. I use igb1. As I told, no problems without WG and full speed. WG natively runing on a Linux Mint 19.3 PC throttles the speed. Imho there is nothing wrong with Mode "Inline IPS"
Edit
Your requested results are in Snort.zip

@jimp said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:

It's reporting the size as it was when the page was loaded, apparently, and not what the calculated default for the system would be. That may be a bug, though it should probably report both.

Well, it technically does report both in that it appropriately shows the value that was set when the page was loaded in the field where you can change the value. The bug would be that the display for the "default value" stated under the field is actually showing the currently set value.

@virgiliomi ok thank you ill check it out.... I appreciate it...
due to no work.. I cant afford anything,... and people hoarding food and the damn toilet paper...

I appreciate it and ill check it out (:

There aren't any plans to migrate from one to the other since they operate in much different ways.

@johnpoz said in Cert Manager Export Password:

See the popup I showed where it says to look in profiles - did you miss that?

It is a very valid point. It is easy to miss. But I haven't. Going back to the two things I have tried.

If using the unencrypted p12 (which I know it is not meant to work): when I click on it, I see the pop up at the bottom saying that I have to go to my profiles to add it. If I go to general-->profiles I can see it there, I can click to install it, enter the pin code, and then I get stuck waiting for the password. But the p12 does get sent to profiles and an install can be attempted. when using the encrypted version, nothing happens when I click on the p12 file. When I say "nothing", I mean as if I had not touched the screen at all. No error, no "open with" menu, nothing.

UPDATE: I have noticed that you used the Windows version of openssl. So just for the sake of it, I decided to install it and give it a shot. Surprisingly, it worked this time. Thinking that there can't be a difference between the two openssl, my head pointed towards the transfer between my raspbian and my Windows computer. Per default winscp transfers text file, and apparently doing this messed up the base64 and made it unusable for the encrypted version. After repeating the process with a binary transfer mode, I could import that encrypted p12 as well.

So in the end, I could solve the problem and I hope this can help someone else. Thanks a lot @johnpoz for pointing me in the right direction. Without your screenshot I wouldn't have thought about looking into that and find the root-cause.

Of course ☺

You already did. When you visit the console, you activated that script.
( maybe without knowing it )

@ragnar00 Thank you. I found it.

I split this off into its own thread so it doesn't take over the other one.

i replied in my other thread about the alias is fixed by reinstalling the firewall on my SG 3100 back to stable and not restoring ANYthing previously. entirely rebuilt from scratch

i am now running sg 3100 on 2.4.4-RELEASE-p3 (arm) but have the same issue as i originally posted in this thread.

on the stable release, i have spent hours on trying to figure this out. in reading on redmine https://redmine.pfsense.org/issues/6028 if i am reading this correctly this affects ALL versions of Pfense? i have been using Pfsense for the past 3-4 years and never experienced this.

leads me to two things. is the image file for the sg 3100 contain issues my SG 4220 and SG 2220 did not have?

because i have been using these same rules, and yesterday they were built from scratch not restored from a previous firewall..

if this is the bug i just need to know that so i understand its being worked on

thank you Sir

So a good example would be something like this:

pfctrl -sr currently prints out the rule set and userrules anchor (anchor "userrules/*" all) is empty. I have confirmed with a pfctrl -a userrules -sr which returns nothing. I then added the following:

echo "pass in quick on em0 inet proto tcp from 192.168.1.7 to any port = 32400 flags S/SA keep state" | pfctl -a userrules -f -

when I run pfctrl -a userrules -sr after this I get:
pass in quick on em0 inet proto tcp from 192.168.1.7 to any port = 32400 flags S/SA keep state

The rule doesn't work though and it doesn't display with a pfctrl -sr either. I can't see what I am specifying wrong, I have tried calling the anchor with and with out the /* in quotes a few times and it places the new rule under the userrules anchor as displayed with pfctl -a userrules -sr each time. I can clear it with pfctl -a userrules -Fr as well. Given this example can you see where I have gone astray? Thank you for your help.

Thank you, I'll keep that in mind for future. I understand why I had confusion and the replies have helped clear it up for me.

Again thank you Jim and everyone that helped.

@jimp Thank you!

Today I updated pfsense to the version "2.4.5-RC (amd64) built on Thu Feb 27 00:05:35 EST 2020" and the problem with Dynamic DNS is gone.

Thanks!

@jimp i try to to customize the code for my Owen purpose still it don't run after i gate the code

It has a well view, what did you use to improve your traffic graph? I still have some problems with and even more when I try to upgrade my Ip man is such horrible haha. I like you css style, well done bro!

I didn't get an error message, but bumping from 0221.1500 to 0225.2100 took me a solid 30 minutes. Not quite sure what the hold up was.

They are on a timer now and not triggered by any specific change as before. Keep an eye on Github and Redmine and see if anything interesting changed between what you have and the current one.

If it makes it into OpenSSH sshd in the base system FreeBSD, perhaps. But doubtful.

No. It's in 2.5.0, but won't be copied back to 2.4.5. It's too late and the changes required for that are too large. (And IIRC it may also require PHP 7.3 and OpenSSL 1.1.1 for some parts, but I might be misremembering that).

We're working on migrating the builds over to a new coordinated system that is not only faster but will have consistent timestamps for everything across all builds that start at the same time. It will trigger at set times, multiple times per day, rather than on demand as commits happen, but can still be set off manually if we want.

Other than the timestamps being more "even" in most cases, it should be transparent to users.

The timestamp on the individual images will be when the entire build run starts and not necessarily when that kernel build timestamp happens.

I think we found/fixed most of those unquoted strings some time ago, but there is always a possibility that more are lurking.

The <shaper> section wouldn't show what the wizard had in it that led to the original error, but if you look in <ezshaper> that holds the wizard data.

I'm not trying to be disrespectful friend, just you didn't mention whether it was running or functional afterward, nor an actual complete error line so hard to start troubleshooting. :)

Finding out if it starts properly from the webconfigurator after full up compared to at startup can potentially be a valid troubleshooting step that would lead to the cause.

edit:
Just built fresh 2.4.4_release-p3 vm and installed full squid package. As far as I can tell, every single edit to the squid configs generates a similar line in the logs. Restarting the machine also puts one in the log every single time. Tested the blocking function with the clam functions and with another vm successfully blocked the eicar test file...

While I cannot confirm or deny that the line is or is not an error, I think I can confirm that it existed before the 2.4.5 development freeze and that it has zero impact on functionality and probably not a blocker.

edit#2:
To clarify OP and my ???? in response the actual log line from normal config edits:

php-fpm 766 /pkg_edit.php: [squid] - squid_resync function call pr: bp: rpc:no

and

php-fpm 767 /pkg_edit.php: [squid] - squid_resync function call pr: bp: rpc:no

Actual log line from normal bootup:

php-fpm 339 /rc.start_packages: [squid] - squid_resync function call pr: bp: rpc:no

@yon-0 said in pf2.4.5 setup DHCP Static Mappings then lan down.:

so I tried various parameter settings

What? You don't just randomly change shit that has zero to do with anything hoping it fixes something

dhcp has NOTHING to do with a device talking to another device... Its just a method to hand out info.. Doesn't matter if its reserved so client X gets specific IP or other info, or from a pool where client gets a random IP or static..

Again if you are not actually going to provide info, and just say shit is not working nobody can help you! Lets see this device that has an IP and mask in your network trying to ping the pfsense IP 185.x.191.1 - Can it ping that or not? If not what are the firewall rules on the interface of pfsense...

Etc... This got to be one of the most frustrating threads I have ever.. Again - there must be a language issue and I highly suggest you seek help in your native language.