It does and in fact actually I see the error from repoc in your initial output. Send me your NDI in chat and I'll check it. Steve

@leres said in Cannot boot 23.05.1 (sg-2100 w/zfs): expect partition size was not an issue. Glad you got it working. The EFI size wasn't an issue if it had ZFS already and/or was newer than early 2022, IIRC. I just mentioned it because we had started planning to reinstall all those 2100s. :-/ We had similar experiences with two clients' 2100s where installing from the same USB stick was not stable (second boot/restart fails, boots up and installs packages then drops offline, etc.) and simply using a different USB stick to do the install has worked fine since then (this past spring). Very strange but seems to be the stick...which we tossed. ref: https://forum.netgate.com/topic/180755/23-05-firmware-upgrade-crashed-a-3100-and-an-1100/ https://forum.netgate.com/topic/180432/certificate-verification-failed/ 23.05.1 was supposed to have fixes already though for those threads.

@stephenw10 thanks, will try

@stephenw10 Looking forward to some clarity. Thank you!

Add pass rules for for each specific IP that needs to access that port. Add a block rule for that port below it for everything else. I would use an alias for the source IPs that need it myself but you could just add separate rules for each device. Why don;t you want to use aliases? Steve

@tom__w How exactly are you scanning.. here is theory.. So your pfsense network is say 192.168.100/24 and your client say 192.168.100.42 for example you say hey scan for 192.168.68.0/24 this traffic since not on the 192.168.100 network would be sent to pfsense say looking for 192.168.68.100 as one of the IPs.. Pfsense says well shoot, I don't have a 192.168.68 network attached to me, send it out my default gateway - your ISP.. Your isp may very well have devices on its network in this rfc1918 space 192.168.68, which could in turn answer say a ping.. So no they are not your devices - they are some devices out on your isp network. edit: example of this... Somewhere in my ISP network 10.0.0.1 answers C:\>ping 10.0.0.1 Pinging 10.0.0.1 with 32 bytes of data: Reply from 10.0.0.1: bytes=32 time=39ms TTL=249 Reply from 10.0.0.1: bytes=32 time=36ms TTL=249 If I traceroute to it C:\>tracert -d 10.0.0.1 Tracing route to 10.0.0.1 over a maximum of 30 hops 1 1 ms <1 ms <1 ms 192.168.9.253 2 11 ms 11 ms 10 ms 209.122.32.1 3 18 ms 12 ms 11 ms 216.80.79.9 4 37 ms 36 ms 38 ms 207.172.18.134 5 36 ms 36 ms 38 ms 207.172.19.124 6 36 ms 37 ms 53 ms 207.172.19.91 7 38 ms 36 ms 41 ms 10.0.0.1 it is somewhere on my isp network, or my ISP network is routing rfc1918 outside their network when they shouldn't But looks to be connected in their network somewhere, if I resolve the IPs in my trace 1 <1 ms 1 ms 1 ms sg4860.local.lan [192.168.9.253] 2 12 ms 13 ms 19 ms c3-0.rol-e6k1.nape.il.cable.rcn.net [209.122.32.1] 3 11 ms 11 ms 11 ms static.rcn.com [216.80.79.9] 4 40 ms 36 ms 38 ms hge0-0-0-7.core2.chgo.il.rcn.net [207.172.18.134] 5 36 ms 35 ms 35 ms hge0-0-0-4.core1.lnh.md.rcn.net [207.172.19.124] 6 56 ms 36 ms 38 ms hge0-0-0-0.core1.phdl.pa.rcn.net [207.172.19.91] 7 59 ms 35 ms 38 ms 10.0.0.1 Looks like the device is some core router in the Philadelphia PA location. or attached to it, could very well be say a loopback address on this device? It is not uncommon to see rfc1918 in a trace through your ISP network, when some devices is setup to answer from loopback. Or even actual interface IP in their network - nothing saying an ISP can't use rfc1918 space as transit networks in their network. I normally run this rule as outbound floating rule to prevent such things. Just being a good netizen - there is little reason to send rfc1918 out to my isp. [image: 1701178214588-outboundrfc1918.jpg] I had to disable it to find something out on my isp that was rfc1918 and answered. edit2: hints that is not on your network, if the response time is higher than just a few ms, its prob not on your network ;) Also see the ttl of that ping above its 249, that isn't a local or even 1 hop sort of ttl. If you ping something local the ttl should reflect that there was no hops to get there. Reply from 192.168.9.10: bytes=32 time=1ms TTL=64 Notice when I ping something on another network attached to pfsense Reply from 192.168.3.32: bytes=32 time=2ms TTL=63 See how the ttl has been reduced by 1, this tells me there was 1 hop to get to that device..

Yes, or import it from FreeBSD as they attempted. In either case it has to match exactly the php version.

I wouldn't expect Kea to make any difference there. It is indeed odd that it would only now start to report that. I did wonder if either the max value changed or the logging level but I couldn't see anything obvious indicating either.

@stephenw10 2.7.0 I now see 2.7.1 is out, so I'll upgrade shortly

Yes, that seems like more than one thing. The notices error has been seen by users in various configs so I doubt it's directly related. It could be some common cause though if you're seeing php stop responding for example. Hmm.

@tman222 I did. Actually went to copper SFP's and still had the same issues. I thought of Wireguard because there was a known problem with Wireguard and Chelsio but I thought that was fixed with either 2.6 or 2.7, can't remember which. But when I did the upgrade to 2.7.1 I also lost 2 of my 3 Wireguard tunnels. Haven't had a chance to go any further into this and probably won't for a while. I have four gig ports that I am using now instead of the Chelsio.

If it's completely different hardware the NDI will have changed. Sent me your NDI in chat and I'll check it. Steve

That worked! For any others with this issue the 1st command in the above link under troubleshooting had me go Diagnostics/Command Prompt and I typed "certctl rehash" in the "Execute Shell Command"...waited a bit so be patient and then it rebooted. Thank you! @stephenw10 & @SteveITS

You can bypass that bug by setting up the PPPoE config first in Interfaces > Assignments > PPPs. Then select that as the WAN.

You should not see firewall logs for it on WAN unless it's being blocked. Do you have some odd pass rules on LAN? As I said it's possible to create rules that pass the traffic without creating a state but you have to create that specifically and they're almost never the right option.

Nope the putty log should capture it.

Thanks @stephenw10 , that's very helpful. If the images or at least the checksums were gpg signed, that would be another way to give more confidence in the downloads, but that's another topic. Thanks again!

Yes they should be able to set that public IP on the Meraki WAN dircetly. And yes they could setup a VLAN or just a separate port to isolate a connection from pfSense and NAT it.

@johnpoz said in OpenSSH v9 new default conf directive "PubkeyAcceptedKeytypes": Only thing I am still using rsa on is like my old sg300 switch doesn't support anything else. Unfortunately even the current CBS switches only allow RSA 2048 and SHA1 as well. I believe this is scheduled to be fixed in the next release though.

@floydque said in Remote Access with Mediator: that would add another point of maintenance for me Yup that's true. But it would also be way more flexible....