The pfSense Quagga package was deprecated in 21.02/2.5. The last version that shipped in 2.4.5 was 1.2.4_7.

Why are you asking this here?

Steve

@SteveITS I was going to suggest something similar but as I have not tried to reverse engineer the configuration file I was unsure how hard that is.

To do it I would compare a reset to default configuration file with the existing configuration file.

Thanks everyone putty and Windows 11 fixed it with the correct usb driver

Screenshot 2023-11-29 143357.png

Got access to the boot environments now.

I can't get some packages to with with ARM for 23.09 I keep getting completely locked out and having to go back. That fixed it.

@stephenw10
I really don't know myself..
But i tried it by upgrading from 2.6 which works fine..
and clean install..
both fail.

I set it this way.. CMIIW..
2 WAN, each WAN's interface i set the default gateway to ISP1 & ISP2.
LAN interface, i set it to none, or L3 switch doing intervlan routing inside ( no queue mgmt at all at L3 switch )
Turned off NAT.
In Settings - Routing - I set the default gateway either ISP1 or ISP2, or automatic.
It just works everytime with 2.6.. i even reinstall the 2.6 as well for testing purpose.

Ok, so you only see issues with the RDP traffic?

When WAN1 is down you still have general connectivity via WAN2 from clients behind pfSense?

Do you see the RDP traffic arrive at the remote firewall?

Do you see states created for it in pfSense?

@Vollans

You're right. Some (most ?) registrars will handle Dyndns if you have a domain name with them.
Nothing wrong with Floudflare 😊

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.

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.