I wasn't clear that you were connecting pfsense to the ISP modem and getting a prefix from it. Does the modem allow a port to be bridged so you can get dedicated prefix for pfsense? That's what many people here are doing. I have two pfsenses connected this way, each with a separate prefix. The ISP SHOULD NOT be changing the prefix unless the DUID of the router changes or the router releases it. If they are routinely changing the prefix even if the DUID is unchanged and the router is not releasing it, they are not competent.

As for changing prefix being a benefit for privacy, that's what a firewall is for. If you think changing prefix is a feature, you are probably one of the only pfsense users who thinks so. I agree with the other comment that "privacy" addresses are for privacy.

pfsense does not deal with prefix changes very well. It could and should do a better job, but for some reason, it's not a priority. The feature "do not release prefix" was intended to prevent a prefix from changing due to pfsense releasing it.

You should try connecting pfsense to a bridged port and see if the behaviour is different and you should ask the ISP why they are changing the prefix. If you are stuck with a frequently changing prefix, then you are going be dealing with firewall issues. I think you would be better off using a tunnel from hurricane electric than what your ISP is providing.

@bullet92:

My firewall failed to update drom 2.4.1 to 2.4.2.
My setup is a physical machine with SSD and intel sata controller. It hangs at boot, says it can't start the kernel. Installation came from an upgrade 2.3.4 –> 2.4.1 Trying to boot the 2.4.0 memstick (i need 2.4.0 or 2.4.2 for PPP VLAN support) and i riceive the same (almost) error. I have an old HP server board (SE316M1) with 2 E5620 and 24G RAM. Now i'm testing my RAM machine,

That's a different problem than I had. I since successfully updated to 2.4.2. Not sure how much success you will have going directly from 2.3.4 to 2.4.1. If your RAM checks out, you might want to try installing freebsd 11.1 (not pfsense) to see if it's a compatibility issue.

Sorry but i can not download development version because i have 2.4.1 and don't works with PPOE over VLAN, i need download the 2.4.2 version and manually update 2.4.1 to 2.4.2, where can i download 2.4.2  ¿??

Fixed in the next snapshot.

Looks like a fix for that has just been committed  :)
https://github.com/pfsense/pfsense/commit/c3938c16e3ba66e6911590653a775423371b4a3a

Yes dhcp6c and the dhclient both seem to be getting pushed back for some reason

Guess there is a lot going on right now

Fixed by setting fixed MAC on Hyper-v NIC setting.

GCM is not on every piece of client hardware out there.

Yes, that line can be removed

I recently moved over to a new pfsense appliance and running the 2.4.0 final release - started off with a completely fresh install and reconfigured everything again.

This seems to have fixed my problem as now changing the priority of my connections works perfectly again.

It may have been an issue with my old configuration but I'm really not sure but glad it's working again.

No one can tell you if that's normal without knowing bandwidth, CPU, and ruleset.

You've got 1 of 3, let us know the other 2 pieces and we can help more.

It also depends on what kind of traffic traverses the network.

If you're running 2mbps of traffic through a long list of complex rules then you could significantly tax even a powerful CPU.

Conversely, if you're using an old atom even a very light ruleset would bring it to its knees.

Why in the world team have decided to bump all of us to 2.4.0 major release?

Nobody from Netgate has shown up at my office and forced me to upgrade.  I deliberately wait at least a couple of weeks after a major release.  If it's critical, I will test it out in my lab first.  I might suggest you try this approach next time.

@jimp:

@johnpoz:

@Derelict:

It would also mean that changing an alias would have to bounce your VPN - including hostname resolution that happens every 5 minutes (by default) if any of the aliases require resolution.

Whey is that exactly?  Why would a alias that consisted of networks ever need to be resolved?  And why would the resolution of fqdn in the aliases have anything to do with the vpn being up or down?  Not understanding what the 2 have to do with each other..

Yes stuff in alias table gets resolved every 5 minutes.  What would the resolution of aliases have to do with IPs and networks in alias used for vpn remote networks?  I could see changing the alias sure.. Since that would be the same as changing the remote networks in the currently.

If you edit the alias and save it, the VPN would have to be reset, which is counterintuitive if you don't remember that the alias is used on that VPN, for example.
Also you can use hostnames in network aliases they just get a /32 mask, so they would still have to be hooked into the same process.
And if a hostname resolved to a new address, that means the contents of the alias changed, which means that the VPN needs to be restarted to pick up the contents of the alias to use for routes.

It isn't like pf where the changes can be picked up automatically on-the-fly, since OpenVPN has to manage its own routes internally.

For such cases I would just simply put a small waring in the alias edit page: "Warning: this alias is being used in the 'name-of-the-OpenVPN-instance' OpenVPN configuration. After changing values here it is recommended to to restart 'name-of-the-OpenVPN-instance'".

So I wouldn't restart any VPN automatically, just notify the user that the alias affects OpenVPN also - and let the user decide if he/she wants to restart it (to prevent interruptions for cases when pfSense itself is being managed via the OpenVPN connection).
The warning bar at the top could also be used for this after changing the alias, reminding the user that OpenVPNs restarting is due, even if he/she moves away from the aliases config page.

@nivek1612:

At 2.4.0 and earlier a vlan of 832 for example defined on interface igb0
Resulted in an interface name of igb0_vlan832

Now it a 2.4.1 and later pfSense creates igb0.832

Caused me an additional bit of head scratching

Reading the changelog: https://doc.pfsense.org/index.php/2.4.1_New_Features_and_Changes helps in such cases.

Changed the VLAN interface names to use the 'dotted' format of FreeBSD, which is shorter and helps to keep the interface name smaller than the limit (16) This fixes the 4 digit VLAN issues when the NIC name is 6 bytes long.

Hi,

that would be nice. Please send me a link where i could download it.

Thank you in advance.

@luckman212 @jimp

I'm seeing similar issues with 2.4.0-RELEASE. Description of the issue here:

https://forum.pfsense.org/index.php?topic=138457.0