@johndo Verständnisfrage: du willst dass der Port 3 separat (als eigener Single-Port) agiert und der die VLANs x (17,18,...) getagged sprechen soll? Das ist das was ich aus der Konfig gerade lese? Denn das Default VLAN 1 hast du ihm weggezogen, das steht da nicht mehr in der Liste. Nur das "Mgmt" (Group 2) - aber wenn das dein gewünschtes Untagged ist, stimmt das. Wichtig wäre noch im "Ports" Bereich zu schauen, dass das richtig eingestellt ist. Sobald man vom Default abweicht, muss da der entsprechende VLAN mode aktiv werden und die Ports korrekt anzeigen. Aber wenn es sich ansonsten korrekt verhält wie du möchtest, sieht das nicht verkehrt aus. Cheers :)

@stephenw10 Yes, same box, same hypervisor. sip, ssh, rdp, web, everything works fine over dco for those on the same hypervisor (and the same subnet) Whatever lies outside the box and the same subnet only icmp works (to either the behind the dco vpn or anything on the internet behind pppoe. Same lan stations policy routed to another dhcp wan connection work FINE. And again. reverting to previous version and uploading the SAME config file resolves ALL issues.

@ivica.glavocic said in OpenVPN proposal: User can't authenticate from OpenVPN Connect when using a saved user/pass (PIN) plus OTP prompt (static-challenge "Enter OTP" 1), because the client sends PIN + OTP and freeradius server expects OTP + PIN. I use OpenVPN GUI on Windows. It sends OTP + PW to the server in this order. The password can be saved, so you have only to enter the OTP. If you use the Network Manager on Linux, which has no OTP option, I have to state the OTP + password in the PW field.

@detox run a search on this forum for 'kea2unbound php' and you'll find some results that may help. In general: What pfSense+ version are you using and are you using pfBlockerNG (then the solutions in the mentioned search will help you)?

@Antibiotic Does Unbound support RPZ ?and the official nllabs = unbound author manual and documentation. I tend to say : yes.

@LaUs3r ,Hi yes, I followed the Surfshark WireGuard guide and now it’s working. Earlier, the guide steps were too superficial so I kept missing things, but in the end the Surfshark WireGuard guide worked. However, the default gateway issues still remain WireGuard is not working as the default gateway only when WANDHCP is default gateway the handshake is formed Anyway i switch to openvpn, the setup i was working on it is to make nested multi hop vpn the built now looks like this: pfSense#1 → [Veepn OpenVPN1 UDP → (lan segment of pfsense #1 connted to pfSense#2) → pfSense#2 OpenVPN2 UDP] → (lan segment of pfsense #2 connected to windwos vmware) → vmware windwos Internet • pfSense#1 has my Local ISP WAN Connected • There is no WAN connected to pfSense#2 only lan segment of pfsense #1 connected I’m using OpenVPN UDP on both pfSense firewalls, each with a different VPN provider the first one is VeePN and the second one is Surfshark. For the whole setup, I followed Lawrence Systems’ guide.

IIRC that happens when selecting specific logs to send instead of sending all logs.

Never mind... looks like something similar was answered a few weeks ago... and the led on my device turned off last night.

The blue-square LED turning purple indicates an upgrade is available. There was a backend glitch last week that showed the public RC available to some users. You probably saw that. https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4200/io-ports.html#status-leds

@edstiles When it comes to throughput estimates, there's no such thing as "VPN". Different VPN systems work differently and want different things from a processor. Specifically, OpenVPN runs single-threaded and relies on AES encryption, so the throughput is determined by processor speed and availability of AES-NI support on the processor. With an N100, I would surmise you can get Gigabit OpenVPN. Note, however, that OpenVPN is transitioning to multi-threaded operation, and when that happens, old limitations will no longer stand in the way. Wireguard runs multi-threaded and can live without AES-NI support (it uses ChaCha20 by default). So the throughput is determined solely by available processor bandwidth, with an adjustment for possible cooling issues. My personal quick-and-dirty (I repeat, quick-and-dirty) guesstimation (I repeat, guesstimation) rule is, 6 GHz of processor bandwidth per Gbps of throughput, to be adjusted upward if there are cooling issues. IPsec, as a first approximation, has computational requirements similar to Wireguard.

@jarmo I'm not quite sure how the lan clients get different prefixes although they will be different than your wan prefix. As far as I know, the ISPs only assign one prefix for lan usage so unless you are configuring your lan to subnet the prefix into multiple smaller networks, they should all have the same prefix. If your lan is using SLAAC for IPv6 addresses, your clients will have multiple IPv6 addresses: an Ipv6 address, a "temporary" ipv6 address, and a link local ipv6 address. The routable lan IPv6 address should have the same prefix and different suffixes. In my case, I found using "Diagnostics->Packet Capture" that my router was sending IPv6 renew requests to the ISP and never getting a response (as shown in my previous response). Once the ISP fixed the issue, I started seeing the rc.newwanipv6 entries in the system log. My only suggestion is to try and use either Packet Capture or Wireshark to capture RA packets or the prefix delegation packets and see if they match what your clients are reporting.

@pst said in Some observations testing 25.11.r.20251118.1708 on Netgate 2100: DNS lookup of DHCPv6 leases As has been reported elsewhere, I noticed DNS lookup is not working for IPv6 addresses. Currently : nslookup host gives me the ipv4 address, and nslookup host.t gives the ipv6 address. Marcos was able to successfully address it yesterday.

@wzkds See: Routing Public IP Addresses

So I disconnected the backup device and my network is back to normal (even though I haven't removed the CARP and HA settings yet). Just for the sake of testing, I configured two identical Steelheads CX770s with Opnsense and got the same results as with pfSense. I get the same results with two sets of completely different hardware! How can this be possible?! I thought it was the connection to the switch (since both firewalls connect to the same stack) but as soon as I remove the backup unit from the HA setup, all network connectivity is restored. Has anyone here encountered this problem before? Martin M. Mune US Army Combat Veteran Operation Iraqi Freedom Volunteer Soldier International Legion for the Defense of Ukraine Слава Україні! Героям Слава!

Thanks for the report. This will be fixed in the release.

@Wolf666 Thank you, I will try it. Unfortunately, since I had already replaced the contents of /usr/local/etc/rc.d/tailscaled and it had been working so far, I will not be able to tell which of the two solved the problem. And of course, I can't find a copy of the old .../rc.d/tailscaled. Therefore, if none of this works, it will require yet another delete and reinstall of everything Tailscale in my system.

@conbonbur Here's an option/idea from the docs using OpenVPN instead of IPsec: OpenVPN Site-to-Site Configuration Example with SSL/TLS 'Hub and spoke' is the topology you're after—where Site A would be your so-called 'hub', and Sites B and C the so-called 'spokes'. Pretty sure a hub-and-spoke topology could be accomplished with IPsec by implementing a particular NAT configuration and/or static routing. But either way the short answer is: yes, it's possible.

@EDaleH Thanks for your input on this matter. This issue is not related to the DHCP server, especially KEA DHCP. We are still on pfSense 2.6 as mentioned, so ISC DHCP is in use, and there are no lease problems. Lease times are already configured correctly. The core reason that @Gertjan pointed out is correct and seems to be the right direction to get this resolved. It doesn’t affect everyone, but systems under heavy load during peak hours are the ones that usually run into it. The issue is a race condition under load. If the pruning process takes a long time to enumerate and remove old entries, and a new session or disconnection occurs, or if the process is interrupted or times out, the lock file may remain or the process might not finish its database write cleanly. This can leave the system in a partial state where the voucher record is removed but the session is still present. I also believe this issue also exists in pfSense+ since the captive portal code is same in the areas related to this behavior.

@Jaritura I wonder if that really works. On WAN direction 'in' means connections from the public to the WAN. Your first rule keeps the state for all these connections. Have you implemented this and it works?

@Lartax73 said in Latest pfSense release (25.11) uses FreeBSD 16 - official release is December 2027: Thanks for your explanation. So in practice, does Netgate have many issues using FreeBSD-CURRENT for pfSense 25.11 (crash, NIC driver, ZFS…)? And do they have a roadmap to migrate to FreeBSD 16-RELEASE when it comes out? I don't think there were more issue then when they followed the RELEASE channel. And no, they will stay on CURRENT (you may want to read the blog post), no going back to RELEASE.