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 :)

I would make sure you can authenticate from Diag > Auth before attempting to use it for OpenVPN.

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/authenticating-openvpn-users-with-radius-via-active-directory.html

You might also check this hangout: https://youtu.be/n2Z3rr4W2xw

Steve

There doesn't appear to be anything wrong shown in those logs. If the daemon should not have been restarted at that point I would check the system logs for that point to see what was happening that may have restarted it.

Steve

To do a wol from pfsense, just click the little button in the dhcp leases ;) Which will add that mac to your wol table..

wolbutton.png

Not sure why anyone would want to have their nas in standby in the first place ;) Mine is doing all kinds of stuff in the background during "off" hours.. Creating plex video previews, maint on plex, etc.

Never know when someone going to watch a movie at 3 am as well, etc.

There is also normal other maint that synology goes through off hours, backups, reports, etc.

If you want to pass the routes via a protocol - go for it.. But sounded like you wanted route the L2 at pfsense as well with multiple wans.. Ie 3 different wan networks on pfsense?

Without natting, or host routing that leads to asymmetrical traffic..

If you have a downstream router, you connect the upstream and the downstream via a transit network.. You don't just connect the downstream router to all the upstream networks via different wan interfaces.. That would be just a freaking mess.

If you want to use a routing protocol to exchange the routes - sure, but its complication for no reason. Not like the downstream router is going to be adding routes out of the blue and you will want to know they are down there via a route being added via the protocol.

And you sure don't seem to have multiple paths to gte to the downstream networks, and you don't seem to have need for a failover via loss of a path, etc. etc.

You could get as simple as using some large cidr on your top networks.. Say using a /20 which would give you lots of room for growth of more networks their, and then a /20 for your downstream networks, etc. But sure if you want to run bgp or something to play with - have at it.. Your still going to connect them via a transit network(s)..

Really you would need to be logging the console output when it reboots to see what is happening there.

You might be able to enable a serial console, set that as the primary console and log that output. It would no doubt involve some fun and games in HyperV though....

Steve

@5555

Maybe this here VDSL2 - Parameter für 1&1 can help a little bit?

Well at least you have diagnosis and a fix. Not much else you can do there but swap out the card.

Steve

@kiokoman Thanks. I didn't think so but they were showing intermingled like that so I wasn't sure.