Mostly likely it lost power and hence whatever was in the RAM disks at that time. Yes the data is written to permanent storage when it is shutdown gracefully.

Steve

It's not the broadcast address because the broadcast address on the interface is .63

There is NO WAY for an interface to know .255 is a broadcast address if it is on subnet .0/26

If there are devices on a network that were designed by morons that insist on using /24, then you either remove the devices from the network or you use /24. Period. You don't block the traffic or try to work around it in other silly ways.

If you want to keep using the resolver, Unbound, you can switch that to forwarding mode instead. That allows you to use DNDBL for example.
Or in 2.4.4+ you can set a failover gateway group as the default gateway (cannot be a load-balancing group) and keep using Unbound in resolving mode.

Steve

Hmm, that sure looks like something hardware offload related. Was that with both switches still in between?

If it was it could be failing negotiate between those switches correctly. I'd have to guess that 100Mb switch is doing something odd. Can you test without it?

Steve

Hi.

Sorry to revive this old thread but this is exactly what I would like to do too but fear I have less skills to understand so quickly what the solution was.

I've got as far as creating a new feed with the json address in pfblockerng but how do I now use that as an alias? When attempting to create a new alias I'm not sure how to use that feed information or refer to it, the only option I have is the usual host,network,ip, url etc.

I am not a gun on this stuff so please be patient with me :)

Cheers

Just gone through the logs and can't see anything around the time where I received the swap errors

No only IPv4.

I think someone prob gotten better help in their native language section..

OK, I committed that /var/crash fix. I opened an issue to track it at https://redmine.pfsense.org/issues/9409

That UUID issue would be a topic for a fresh thread.

If you want to use nat reflection, just set that up on your nat rule on your wan that redirects 9000 to 3389.

If your going to allow rdp from public.. Agree horrible IDEA... and you don't want to remember to use :9000 or not... You could change your rdp to actually listen on 9000 then just port 9000 to 9000

And setup a host override for name.tld that your using to access your public IP outside, to point to the rfc1918 address of the rdp box when your internal.

You should really use VPN to access your rdp resources while your outside your network

Thanks a lot for your Input.
Somehow I didn't even think about this solution, changed it in the DNS on our DCs and now it's working without a problem.

Thanks

I really like the persistence of the shellcmd solution, so I'll stick with that. Thank you very much for your help!

@gouster4 said in 10.0.1.1 to 10.255.255.254 dhcp server pool:

Any suggestions?

Yeah understand how dchp actually works before you try out nonsense..

You configured it to load external credentials and it worked but then failed to auth at boot?

Steve

You could try the FauxAPI pfSense package together with the pfsense-fauxapi Python package that provides both a Python library interface and a command-line interface.

FauxAPI package install

set fauxapi_base_package_url='https://raw.githubusercontent.com/ndejong/pfsense_fauxapi_packages/master' set set fauxapi_latest=`fetch -qo - ${fauxapi_base_package_url}/LATEST` fetch ${fauxapi_base_package_url}/${fauxapi_latest} pkg-static install ${fauxapi_latest} https://github.com/ndejong/pfsense_fauxapi

pfsense-fauxapi client side install

pip3 install pfsense-fauxapi https://github.com/ndejong/pfsense_fauxapi_client_python

You might be able to prevent it loading by running at the loader prompt:
set hint.i915kms.0.disabled=1
boot

Assuming you're talking about the graphics driver.

Steve

I assume you have no native IPv6? If you left is configured you ISP may have enabled something that is still broken for example and it's trying to use that in preference.

It seems more likely that the remote end point was disabled. I know if nothing that could have changed like that in pfSense base. If you have anything that auto-updates like Snort or pfBlocker that might have started blocking traffic.

Steve

There is no way to do that as far as I know.

You might suggest it via a feature request on https://redmine.pfsense.org

Steve

thanks,