I don't really have anything else to add other than that you can upload images here directly without having to link to some hosting site like Imgur. Just use the Upload Image button in the Edit bar when you're making a comment.

Hmm, then I would be testing against an external iperf server next if you can. Steve

to be honest any sort of nat "reflection" is just an abomination if you ask me.. Why not just have your local stuff resolve the local IP vs any sort of reflection off your public IP.. Simple host override is all it takes. Only reason I can think of doing a reflection would be to work around the horrible coding of some app that uses a IP vs a fqdn as destination.

Most of the ET Policy ones are related to my IOT network, I should really tighten up $home_net now I'm running Snort on the parent interface. The SIP stuff is related to a VOIP phone sat on my network. The rest was just normal day to day traffic.

Thx for the quick exact info!!

Thanks a lot i now understand it probably thru the console I also discovered in the link https://community.adamnet.works/hc/en-us/articles/115002725594-Running-on-a-Transparent-pfSense-Bridge It uses the mac address of both the WAN and LAN interface rather than ip address when assigning the LAN and WAN interface to the BRidge This has to be tested before knowing if it works

What is your hardware? Just how bad is you upload speed? How are you testing it? How fast is it without pfSense in line? Steve

Nope - not forced, you making the call that easier and better to nat then change one side to use something different.. Not like rfc1918 is freaking limited in what address space you can use ;)

That sort of thing is often achieved by using a very low TTL value to prevent routing. People occasionally ask about doing the opposite of this to bypass such restrictions. However I'm not sure there is any way to do that in pfSense. Not in the GUI at least. Steve

Are you using a static IP on WAN? Is it correct? If it's DHCP is it pulling the correct gateway? The gateway may not respsond to ping in which case it will always show as off-line. You would have to set a different monitor IP if that was the case. ... only in the host where the pfsense running Does that mean it's a VM? Are you sure the interfaces are configured correctly? Steve

If it got to the point where it can't load the kernel, I wouldn't settle for anything less than a wipe+reload. I'd also be suspicious of the disk itself.

The difference is that --comp-lzo is for all OpenVPN versions. --compress is for version 2.4 and higher. Also see the manual: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

@Pippin I don't know if that is the proper fix. My thought would be to find out what's causing this. What packets are being fragmented? If that setting only affects fragmented packets that have DF set, then I suppose it wouldn't be a problem. Still, I'd want to know why it's needed. As I mentioned, DF is used these days, for everything on Linux and TCP on Windows.

So apparently their is a -L flag that can be used when executing the command to start the NTP daemon which will tell it not to listen on VIPs. However for this to work as such the alias for the VIP must have a colon in the name (which if you ask me is a very weird condition). Not to mention that they came its been depreciated and thus more preferable to use the -I flag to directly and more explicitly specify the exact interface(s)/IP(s) you want it to listen on. Just out of curiosity though if we can directly specify these things as part of the command to run NTP versus building a config file, putting these values into it, telling NTP to get that info from the config file, etc would it not just be easier/more efficient to build it all into a single command and have it run as such from the get go?

So I came across a file named gwlb.inc and added a sleep() command at the start of the start_dpinger function which did apparently solve my issue of a log entry not being created claiming that a few pings of the gateway failed following a reboot. However it seemed to have a possible secondary issue where for those few seconds that the boot process is thrown off by the NTP process momentarily errors claiming the clocks are not sync'ed. Guessing that there is some check that occurs while this "pause" is happening and since it doesn't see the NTP daemon running it alerts that time is not being accurately maintained; which is technically correct. Granted I know this a very minor issue, more of a personal preference then anything else, but if anyone has a better suggestion on how to handle this let me know. As all I am looking to do is have the dpinger service startup a few seconds later than it currently does.

Router doesn't know to not send rfc1918 out its default.. It just knows hey not locally connected to that network, have no routes to that - so send it to the default gateway.. He will know how to get there ;) Yeah 192.168.100.1 is default modem IP for a lot of devices.. So yeah when the modem looses sync it will hand IP on that network so you can access its status/config pages.. So if your modem rebooted or lost its sync, then sure pfsense could get 192.168.100 address on its wan.

It is a kernel panic. Do you have a crash report after it reboots? You could try interrupting it before it resets and enter bt there. That should show something useful. But, yeah, you should backup you config file, install 2.4.4p3 fresh and restore the config into it. Steve

@johnpoz said in driving me mental, remote login to pfsense CLI to shutdown: ssh-keygen -o -t ed25519 Thanks John & Derelict! all working now :)