All sorted. SUE..... Turns out ethernet doesn't work that well over a 300m long cable..... Interesting though, the RJ45 Cable Tester did work so that was a bit confusing. Anyhow, good to know for the future and all sorted now.

At that point it might prove helpful to configure a serial console output and hook up the serial port to another pc running some terminal software with a big scroll back buffer. It might give more insight than fans spinning at boot. p.s. Strange as it is, I do suspect power issues, its a good way to crash a system without leaving ANY traces apart from the new boot logs.

@jwright Which device do you have/are running pfSense? If it’s a netgate device, connect to the console with a serialport terminal like “putty”. If it’s a homebuilt pfSense CE, connect a monitor and keyboard. Then you will know if it boots as expected or something catastrophic has happened.

@guardian said in Anyone using pfSense with telMAX ISP (Canada)?: I don't trust my ability to secure it. Not much different than IPv4. You start out with everything blocked and only allow what you want. In fact, you can configure many rules to apply to both IPv4 & IPv6. Here's an example: [image: 1755915116010-9101928c-dd2d-4e58-abe2-d4a68923083d-image.png] The first rule blocks pings and the second allows other ICMP.

Anybody is using Protectli Vault V1410-4 Port ?

Yeah, just to prove it out I ran a simple test. Since I don't have anything I can easily use that advertises mDNS I just turned on Publishing in Avahi itself on 4 firewalls: steve@steve-NUC9i9QNX:~$ mdns-scan + 4860 [00:08:a2:xx.xx.xx]._workstation._tcp.local + 4860._ssh._tcp.local + 4860._sftp-ssh._tcp.local + fw1 [00:08:a2:xx.xx.xx]._workstation._tcp.local + fw1._ssh._tcp.local + fw1._sftp-ssh._tcp.local + pfsense [00:01:21:xx.xx.xx]._workstation._tcp.local + pfsense._sftp-ssh._tcp.local + pfsense._ssh._tcp.local + 1100-3 [f0:ad:4e:xx.xx.xx]._workstation._tcp.local + 1100-3._sftp-ssh._tcp.local + 1100-3._ssh._tcp.local In that result 4860 is in the same subnet as the client I'm testing from. fw1 is the router on that subnet. pfsense and 1100-3 are other firewalls in different subnets connected to fw1. You can see the scan tool is able to see all of them no problem.

@stephenw10 Thanks

2.8.0 has the patched code: https://github.com/pfsense/FreeBSD-src/commit/2abea9df01655633aabbb9bf3204c90722001202

Got it working. I needed to add a virtual MAC in OVH [image: 1755849994302-7f78b61e-b920-4844-9aec-a984ec259bd5-image.png]

@stephenw10 Ended up doing a reinstall. Netgate installer is pretty sweet. First time using it and absolutely no issues at all. Impressive. Also restoring from ACB was a bit nerve racking as I couldn’t find my key but it all worked out in the end. Seamless to get back online to be honest I really don’t know why people have hang up’s over the installer..it just works

Usually those are seen when there is some temporary interruption in the connection. Like the WAN is down at boot for example.

Yup, that. Combine it with static DHCP leases to get a fixed list of IPs to limit.

@stephenw10 said in Poor performance over IPsec but not Internet: In the Phase 1 advanced options settings set 'NAT Traversal' to Force to test ESP specific throttling. Only one end needs to set that. I know I'm necroing a 3+ year old thread, but holy crap this was exactly what I needed here. My main office is on a 500/500 fiber connection, and we have a remote office on coaxial cable running 500/10, and over the VPN I could barely get 20 Mbps, but over the internet I could get the full 500 Mbps. I tried setting the 'NAT Traversal' to 'Force' on our main office, and forced an IPSEC reconnection and now I'm getting about 480ish Mbps over the VPN (internet is around 511 Mbps). THANK YOU THANK YOU THANK YOU Again, sorry about the thread necroing :(

Ok let's continue there then. It's definitely not working as intended.

@Antibiotic Hi apparently the issue I mention here supposed to be only a cosmetic bug due to a change in the code for performing AES-GCM (and other AHEAD cipher) speed tests, that rely on OpenSSL routines. The change change came in, in between OpenSSL 3.0.15 and 3.0.16. So there are most-likely other reasons for your speed regression. I suggest reading the URLs I linked to further up and digging a bit further into those.

Is that consistent across a full power cycle? The LEDs should only ever normally show flashing green during an upgrade. So with pfSense booted. Do that still show the normal power up sequence? Initially no LEDs should be lit. Then after a few seconds the green-circle LED flashes blue.

@stephenw10 Yeah, that was kind of my thinking too. I'll stick with it for now despite the (seemingly) high error rate (0.1% if it could be believed). Do let me know if anyone has any ideas for trying to hone in on the cause of these 'errors'.

@stephenw10 That's a handy command, good to know