To 2.5.1 or not ? that is the question :)
-
I hope like this
https://www.freebsd.org/cgi/man.cgi?zfs
https://danielisz.wordpress.com/2018/04/14/zfs-snapshot-on-freebsd/
https://danielisz.wordpress.com/2018/04/20/zfs-snapshot-on-freebsd-part-2/https://www.maketecheasier.com/use-zfs-snapshots-clones/
/Bingo
-
@bingo600 said in To 2.5.1 or not ? that is the question :):
I hope like this
https://www.freebsd.org/cgi/man.cgi?zfs
https://danielisz.wordpress.com/2018/04/14/zfs-snapshot-on-freebsd/
https://danielisz.wordpress.com/2018/04/20/zfs-snapshot-on-freebsd-part-2/https://www.maketecheasier.com/use-zfs-snapshots-clones/
/Bingo
Thanks for the info !
Side note: you know every time I need to do anything with zfs I read very long complex explanations. Given that I am clueless about zfs, of cause... But should it be an easy, something like: run "blah-blah back-up" and then "blah-blah restore" ?! ( mumbling aloud :) )
-
I upgraded my SG-2440 without any issues (I disabled pfBlockerNG before).
I initiated the upgrade from GUI and then went to the store, came back, and it was done. Smooth. -
Well I tried the new 2.5.1 update and had to roll back again to 2.4.5-p1 as Open VPN clients to my VPN service would not connect and also my multi-WAN setup would not allow for the port forwards to work. I have read there are issues with both OpenVPN and with Multi-WAN setups since the release of 2.5
Trying to get onto 2.5 since its release but have to keep rolling back, my next move it to try a clean install at a later date but for now, I will have to stay on the older version
-
@chudak
The only thing that gave me an issue w. ZFS on 2.4.5 , was that it "barfed" during install. That no disk was selcted.
Easy solved , just select the disk in the menu , before clikking proceed./Bingo
-
I had to add one of my interfaces back to my LAGG used for my WAN.
I had to go to each openVPN server config page and simply hit "save" to get my VPN's back up. I did not have to do this to any of the remote sites on the other end of the VPN's
Otherwise up and working.
-
@chudak It's rather easy, first you create the snapshots. In the beginning snapshot are 0MB. They will grow with every change. Then upgrade to let's say 2.5.0 and after the upgrade they will have "kinda" the size of a complete pfSense installation, as everything has changed due to the upgrade and the snapshot "saves" all the changes. When you rollback (that's how a restore is called) all is back as to the moment the snapshots were created.
-
@qinn said in To 2.5.1 or not ? that is the question :):
@chudak It's rather easy, first you create the snapshots. In the beginning snapshot are 0MB. They will grow with every change. Then upgrade to let's say 2.5.0 and after the upgrade they will have "kinda" the size of a complete pfSense installation, as everything has changed due to the upgrade and the snapshot "saves" all the changes. When you rollback (that's how a restore is called) all is back as to the moment the snapshots were created.
Sounds good !
I've started a small VM to test and installed 2.5.1 on zfs
Do you know command lines how to test it ?
-
I just want to warn people about downgrade to previous pfsense versions with current configuration settings, After you downgrade and restored using current backup configuration, make sure you check every settings. Some security Encryption settings could be changed to lowest security e.g. 512 bits to 256 or 128 bits.
I feel really sorry for users that experienced problems.
-
@akegec said in To 2.5.1 or not ? that is the question :):
I just want to warn people about downgrade to previous pfsense versions with current configuration settings, After you downgrade and restored using current backup configuration, make sure you check every settings. Some security Encryption settings could be changed to lowest security e.g. 512 bits to 256 or 128 bits.
I feel really sorry for users that experienced problems.
Nice "warning"
To me it seems like you are referring to OpenVPN encryptopn settings or ???
And i suppose you are talking about restoring a config made on a 2.5.x system , onto a "clean" 2.4.5 ??
That post needs further explanation , please elaborate a bit.
/Bingo
-
@chudak Good idea use a VM and take a look at
https://forum.netgate.com/topic/95148/pc-engines-apu2-experiences/577
-
@qinn said in To 2.5.1 or not ? that is the question :):
@chudak Good idea use a VM and take a look at
https://forum.netgate.com/topic/95148/pc-engines-apu2-experiences/577
Very useful, thx !
I tried a dry-run, commands worked, but it was not real as my VM is not fully setup as a router. But in general it seem like a worthwhile exercise to consider switch to zfs.
-
On my side, as soon you try to do an install with a different ip or a different sub. it result into a 404 Not found -nginx error page. if leave and touch nothing and just put the psw.. look ok, but even after try to change the ip and it fail. Doing the exact same process as 2.4.5 or 2.5. So .. no 2.5 is the last working version.
-
@yanik Did you get your port forwarding working in 2.5.1?
I'm having the same issues on port forwarding to my Synology box and Plex Server (FreeNAS box). :-(
To roll back from pfSense 2.5.1 to 2.5.0 can I just restore my 2.5.0 backup config file, or would I have to do a clean install of pfSense 2.5.0 first and then restore the 2.5.0 backup?
-
@tac57
A roolback would always include a reinstall (format) , unless you are using ZFS w. snapshot. -
@docop2 de Winter is almost over, let's hope dev fix the bugs.
-
@tac57 said in To 2.5.1 or not ? that is the question :):
@yanik Did you get your port forwarding working in 2.5.1?
I'm having the same issues on port forwarding to my Synology box and Plex Server (FreeNAS box). :-(
To roll back from pfSense 2.5.1 to 2.5.0 can I just restore my 2.5.0 backup config file, or would I have to do a clean install of pfSense 2.5.0 first and then restore the 2.5.0 backup?
No, 2.5.1 port forwarding doesnt work.
I reinstalled pfsense v2.4.5_1 with zfs instead of ufs to able to have snapshots before upgrades. -
Upgrade from 2.5.0 to 2.5.1 went quickly and mostly fine on my netgate RCC-VE 2440. I have a pretty basic setup with a few vlans and pfblocker. The only issue I noticed was that DNS was not working. A subsequent reboot solved that.
-
My starting point was a working v2.5.0 install with no issues. Here is the sequence of events after upgrading to v2.5.1 this morning:
- PFsense unable to route traffic after boot up.
- Unable to ping google.com or 8.8.8.8 from PC
- Bounced the DNS forwarder service, no change
- Rebooted PFsense, no change
- Still unable to ping google.com or 8.8.8.8 from PC
- Verified PFsense itself can ping 8.8.8.8
- Verified correct default gateway was selected
- Rebooted PFsense a 2nd time, no change
- Verified I am able to ping my L3 switch and PFsense, but unable to ping my WAN_DHCP gateway IP (i.e. cable modem)
- Power cycled cable modem
- We have Internet!
I've never had to bounce my cable modem with any other upgrades (including 2.4.5-p1 to 2.5.0), so it's unclear why a power cycle was needed after this latest upgrade from 2.5.0 to 2.5.1.
I would be cautious about any remote upgrades to this version. This would've been a disaster if I performed the upgrade remotely and wasn't on-site to troubleshoot the outage.
-
@marvosa
Let me redo you list :1 PFsense unable to route traffic after boot up.
1a) does it have a WAN IP ? Is it a valid IP ? Does it have a gateway ? Are these addresses known / seen before.I'll be looking at the DHCP client log. Checking if there was a dialog that looks 'normal' between the pfSense DHCP client, and the upstream DHCP server, where ever that may be.
Step 2 to 11 : sending a ping to some remote network, knowing there is no 'route' only proves there is no route.
Restarting DNS doesn't has anything to do with routes. When using IP addresses as 8.8.8.8, DNS functionality isn't used anyway. Also, if there is no 'route', DNS wouldn't work anyway.Very true : Modem devices have most often nothing to set up, and should be transparent.
The reality is different : the most strange things are shown on this forum : modem that flap their NIX state several times during reboot or connection re negotiation. Or assign a RFC1918 while the connection isn't build yet.After pfSEnse has been undergoing a major update, a planned reboot is part of the 'validation process'. Just to be sure that, if it reboots in your absence, things land on their feeds.
It's hard to say what happened in your case, but it could be something like this :
Updating pfsense to 2.5.0 needs a kernel update. To do this, it needs to reboot to load the new kernel. The reboot will take you pfSense WAN NIC down for a moment. The mdoem sees this, and act upon that event, like : a upstream re negotiation.
pfSense boots fast, the modem is (to) slow to open a new connection to the ISP. The pfSense WAN DHCP client repeats over an over a DHCP DISCOVER. This request never reaches the upstream DHCP server : the question is why this dead lock situation exists - why it is created ?
Many modems (ISPs) have their own explanation. This forum has many examples about modems not being very cooperative.
To work out something that works for every situation, the pfSense DHCP client has some 'advanced' options could be very useful.
