@syorke what part are you not getting that if your rule says only 192.168.1/24 can use this interface with the lan2port subnets, how would 192.168.0.x be able to use it?

You need to allow both 192.168.1 and 192.168.0 - you can do that with a 2nd rule, you could do that with using a cidr of 192.168.0/23 you could create an alias that has both networks in it.. Or you could just make it an any with the "*" like your antilock out rule.

No you shouldn't use a modem vip I created for use on my network.. I posted up a screen shot of my outbound nats - I highlighted the part you should be looking for that downstream network to be in.

@cheleby Were you able to start dpinger via the command line to check the error as @stephenw10 suggested?

@louis2 said in Confused since the introduction of pfSense Plus:

Could I go back

You can install CE and restore your config file if the "config rev" is the same or earlier:
https://docs.netgate.com/pfsense/en/latest/releases/versions.html
https://docs.netgate.com/pfsense/en/latest/backup/restore-different-version.html

@louis2 said in Confused since the introduction of pfSense Plus:

what would happen when updating the FW-hardware

If the generated NDI changes (based on hardware changes) the license is invalidated.

You should be thinking about replacing it. There have been a lot of bugs fixed since 22.05.

We have nothing planned that would sell at <$100 as far as I know. Really you would be looking at something used to fit that price range IMO.

If you're asking can you run pfSense as a VM in proxmox then the answer is yes. But there are some caveats! It's a more complex setup to be sure the traffic is all passing through the VM. If you have to reboot proxmox you lose your router/firewall. There are lots of users doing exactly that though.

The above got put into action this evening. Apparently it's been 2 weeks already since the last disconnect. Entire outage lasted about 6 s while dhcp renewed and other services refreshed.

Im quite confident this is not a pfsense issue but rather att. I will post a thread on reddit, perhaps someone knows something I don't.

The other option is to reconnect the att provided ONT back into the loop instead of the third party sfp stick. Wait 2 weeks to see if it disconnects too.

@stephenw10 said in netgate licencing and hardware changes:

Nope it would not. The ordering of NICs is not important.

Thank you 😊

@cheapie408 where in your "modem" which doesn't have a public IP.. You mean your gateway, a modem/router combo that you put into bridge mode.. Modems don't get put into bridge mode.

And yeah its possible for them to passthru a different public IP to the client than what it has.. Many of those devices can do passthru, ie bridge mode and also still do nat for devices connected to its other ports, etc.

Have seen this a lot in business deployments of comcast/xfinity.

Rebooting switches wouldn't have anything to do with it - other then the interfaces would cycle if you rebooted the switch, do you have a switch between your isp device and pfsense wan?

Probably a temporary connection failure. Try making a manual backup and make sure it appears in the backup list.

For whatever reason the system alias TAILSCALE__NETWORK is not being populated so the firewall rules cannot be loaded.

So if you replace those in your firewall rules with the actual subnet it will then be valid and load.

Did Protectli ever get back to you? Is it resolved? Im curious because I have a similar issue with my hardware. I have it sitting at the BIOS screen to see if it may be hardware rather than software based.

Thanks!

2.7.2 does include that functionality yes. It's the ability to check the current or any available repo for updates:

[2.7.2-RELEASE][admin@t70.stevew.lan]/root: pfSense-upgrade -h Usage: pfSense-upgrade [-46bdfhnRUy] [-l logfile] [-p socket] [-c|-u|[-i|-d] pkg_name] -4 - Force IPv4 -6 - Force IPv6 -b - Platform is booting -d - Turn on debug -f - Force package installation -h - Show this usage help -l logfile - Logfile path (defaults to /cf/conf/upgrade_log.txt) -n - Dry run -p socket - Write pkg progress to socket -R - Do not reboot (this can be dangerous) -U - Do not update repository information -y - Assume yes as the answer to any possible interaction The following parameters are mutually exclusive: -c - Check if update is available in the current repo -C - Check if upgrade is available in any of the available repos -i pkg_name - Install package PKG_NAME -r pkg_name - Remove package PKG_NAME -u - Update repository information

But 2.7.2 is latest version anyway so safe to upgrade rsync there.

@MacUsers
By default pfSense blocks all private address ranges on WAN. To disable this, go into the WAN interface setting and remove the check at "block private networks".

Also you need to add a rule to the WAN to allow access to the web GUI.

Yup so that's only the grep command you're running. Kea is not running.

If states have already been opened they will continue to pass traffic even if new rules would prevent those states.

Hmm, I not aware of any blacklisting there. Could be co-incidental I guess.

@stephenw10 Done! Thanks for reviewing; let me know if you need anything else from me.

SG

Well you test there seems to show it's possible with the right NICs. There have been a few other similar posts. Most systems will not though.

I haven't tried it personally, I can only dream of 1G where I am! 🙄

If you have a paid Plus subscription then open a ticket with TAC to discuss. Usually it can be migrated if you had to replace failed hardware for example.