Anything that was happening in 2019 is unlikely to apply to current pfSense. A lot has changed.

We may have strayed from the topic here.

@PhlMike And you're trying to fit a camel through the eye of a needle. Use a hurricane tunnel then. At least they'll have a /48 to use instead of a useless portion of a /112. IPv6 simply cannot be tested in any meaningful manner without at least a /56 routed to your customer.

@NollipfSense Yes, it is nice, but I push forward, towards things that I think are more helpful

Yes, it's a known issue. The fix for it is not as easy as it initially seems. In fact it's two issues. The Space used is incorrectly shown. The automatic BE snapshots created do not check the available space. Both are in the pipeline. Steve

You can edit the config directly and swap out the igb NICs for igc. Then import it; opt2 will still be ovpns1. Then add the additional igc interfaces. Steve

@stephenw10 Cool, added a feature request at https://redmine.pfsense.org/issues/14931

@stephenw10 Ahh ok. I’m ignorant when it comes to this stuff. I thought a certain software needed a certain version to be compliant.

@stephenw10 said in Unusual Booting Up Message: No I doubt it, that wouldn't affect routes added on vtnet1. That's what was revealed when I reboot...it's still complaining...I may reinstall again.

Yes, that is a bug. It's fixed in 23.09. Steve

@stephenw10 Yup! That was it. Changing to use the serial interface on the device seemed to work. Thank You!

@ChaosBlades Since the changes announcement of pfsense plus, you can try using this bypass on 2.7CE. https://github.com/MonkWho/pfatt. I had this running on 2.6CE, but at the time I went to Pfsense plus to use the built in AT&T bypass. I don't know if this will run in 2.7CE, I will need to downgrade from Plus to CE at some point, but since I am running the built in bypass I cannot do that easily. Maybe CE will get this feature in a future release.

Hmm, so something dynamic that survives a reboot but is not in the config.

Hmm, hard to say then. It sounds like the network stack stopped forwarding but the kernel was still running. I guess I'd try again and grab logs covering the event. If it happens again. Steve

@jrey In installed the RC without any patch applied, IP list on graph was again mostly empty applied the patch (my modified one) as described above. IP's are listing fine again.. I'll go back after a bit of lunch and try the original patch, see if that is any different or works. (because that is/was likely something else) as the actual real lines needed to make it go are the same.

@johnpoz said in No Internet Access from LAN (Solved with last good config backup): And unless you setup ssl through the proxy it like 99.9999 going to be utterly pointless John, you make a valid point and to be honest, I have had this like like for years and glad you pointed this out to make me rethink its implementation. I do have an SSL for the the webgui but that's it. As I had said, this was a set and forgot but that turns to nonsense. Your https statement also punches me in the gut with reality...really appreciate the feedback. I shall remove...

Send me your order number or old NDI in chat and I'll check.

If you have a spare port you can bridge that to the VLAN to get that device onto it. But otherwise you'd need a VLAN capable switch somewhere, yes.