After Update to 2.4.1 Internal Server (IP) is blocked

On what you were updating the pfSense firewall? (x86 32Bit hardware or software release or perhaps both?)
From what entire version you were updating it to the version 2.4.1? From 2.2.6, or from 2.3.2 or from 2.4.0?
What a kind of installation is it right now? USB pen drive install (NanoBSD) or a 32 Bit installation?
Are VLANs are in usage there in front of the eMail server or the WAN port?

I am pretty sure this should be coded as a packet for pfSense and not naively installed on a pfSense firewall it self.
Perhaps this is something to install on a smaller device that is collecting the information's from the pfSense firewall
like PRTG with 100 free on a small Windows server or perhaps a RaspBerry PI 3.0 with Linux CACTI and MRTG would
be nice matching to watch the entire pfSense stats and logs well. Have a look under the packet wishlist and post it
there too, perhaps someone will code a packet for pfSense if many users will be considering. A better chance like
here I think.

There has been a correction to the wiki page.

The correct config file version number for 2.4.1-RELEASE is 17.3.

2.4.0-RELEASE is 17.0.

You need to (All under System > Routing):

1. Create a gateway on the LAN interface (em1) for 10.50.0.190.

2. Create static routes for 192.168.0.0 /16, 172.16.0.0 /12, and 10.0.0.0 /8 with that gateway as the destination.

3. If those routed subnets need to make connections into the em1 interface, the firewall rules there must allow those sources.

No other way of creating static routes is correct or supported and if you are playing around manually adding routes in the shell it is not really any surprise you had trouble when you upgraded.

Nothing here changed between 2.3.4 and 2.4.X. Gateways and static routes all upgrade just fine.

@kpa:

On pfSense the file you want to edit is /boot/loader.conf.local and you probably need to create it yourself because it doesn't exist by default on pfSense. The /boot/loader.conf file is a reserved file and gets overwritten every time a new base system update is performed.

Note that this is different compared to a stock FreeBSD where /boot/loader.conf is free for all to edit.

Thanks for that clarification, I'll make sure to edit that on mine instead.  Saved me some headaches later there :)

No, two threads are not enough. Let's find a third one to hijack! Pardon my sarcasm.

I was going to respond with a link to the same thread - I have not had a chance to re-install and setup.  Pretty frustrating that a minor release brought down the whole thing.

I just switched to PFSense a few months ago - Release notes or not, I would not have expected, in 30 years in the IT business, that a point release would be able to bring down my network because of an internal device naming convention, but then again, I did see SMS 1.2 and OS/2 do some pretty nasty things on upgrade.  So, note to self - 'stable' in the pfsense world means it has passed some testing, but ALWAYS read the forums first, point release or not.

yes.  works fine.

Hi,

Update from 2.4 to 2.4.1 and I have same issue as user who started this topic.


Thank you for the useful info.

I believe I have now a device ready for a hot swap.

What I've done was:

downloaded pfSense-CE-2.3.4-RELEASE-4g-i386-nanobsd.img from https://atxfiles.pfsense.org/mirror/downloads/old/ written it to 4GB CF card using  http://sourceforge.net/projects/win32diskimager/ exported config from the old remote 2.0.1 device via web GUI renamed the file to config.xml and copied via USB stick to /cf/conf/ on the new 2.3.4 device restarted 2.3.4 and it appears to successfully embed the new config (viewed from serial console).

That's probably as much as I can do before making a trip to the DC and swapping devices.

Could somebody take a quick look at the boot log and point out any potential problems (if any)?

I have replaced real DNS names and IP/MAC addresses with dummy ones but it shouldn't alter the original concept.

Thanks
Adam

config-import-log.txt

The whole cpu doesn't need to max out to make things slow.  On my pfsense thru VPN for example, I can hit a wall by maxing out a single core out of 4.  It may only say 30% load, but it will be effectively maxed out.

Fixed in Development

https://forum.pfsense.org/index.php?topic=138876.msg760659#msg760659

sure looks like all there to me

https://atxfiles.pfsense.org/mirror/downloads/old/

Goes all the way back to 1.0.1 version.

it turns out that a clue I hadn't posted above lead to the solution. Along with my log data, I was getting a (at the end):

clog: ERROR: could not write output (Bad address)

I searched for that error and found another post

'clog' is used to view circular log files, but not all pfSense logs are circular.

I looked for another way of outputting a log to the command line and found "head"

head /var/log/suricata/suricata_bceXXXXXX/alerts.log worked.

Thanks,

I figured this out last night.  it's simply a matter of predictive device naming.

/joe

I'm not too familiar with NanoBSD but I just happened to be aware of how the partitioning works there. You'll have to hope that someone who knows more shares their knowledge here.

I have a similar need. I've recently reinstall to move my pfSense build on to ZFS. I have a single 128Gb M.2 drive so have plenty space and IOPS to spare. I don't want to add a second disk even though that would give the best level of redundancy as I don't have space inside the unit.

I would like to enable copies=2 which is easy to do but I would like to apply this to my full installation rather than just newly create blocks.

I was thinking of doing the following but I'm not sure if this is sensible.

Boot with FreeBSD ISO version that matches my current pfSense install "FreeBSD 11.1-RELEASE-p2". The do the following

1. Drop to shell
2. import ZFS pool and mount
3. create new datasets with same name as existing with "-new" at the end and set copies=2
4. cp -ax <source-path><destination-path>5. zfs rename original datasets so that "-old" is appended
6. zfs rename new datasets so that "-new" is removed from name
7. check zpool bootfs is correctly point and new boot path change if needed.
8. unmount and export ZFS pool

Would the above work?</destination-path></source-path>

@Gertjan

Fantastic! Changing DIOCADDALTQ to DIOCXCOMMIT works!

Cheers
Thomas

Please don't spam everywhere and open bug reports for things that are not bugs.

There appear to be missing images there. That is not a bug.

It is the middle of the night here in the USA where these things are done.

Thank you for the report.