Just me as a PF Admin. These guys wouldn't know the first thing about it so would like to keep them out of even accessing PFSense UI over VPN among other things.

Finally took the plunge and installed CE 2.8.1 on a spare appliance and updated to 1.88.3_2 Changelog pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3_2.pkg Freshports I applied the tailscale patch. No observed issues. [image: 1760810289185-screenshot-2025-10-18-at-1.57.21%C3%A2-pm-resized.png]

@Deputize2180 Unicast is most probably the only viable test, but I doubt it will fix things. Most probably the isp modem has issues with carp and will never work properly. I'm not aware of any other tunable options too. (and I do hope I'm wrong)

So, for anybody keeping score, I finally got this deployed to production last weekend. So far this couldn't have gone smoother. Aside from a few users messing up OTP with VPN logins everything seems to have worked fine on PFSense's new home. HA works, FW rules work, NAT all seems to work. PFBlocker is doing its thing, OpenVPN seems as good if not better than our old AnyConnect setup from Cisco. Very impressed with the solution I have here after a week. Servers are not even breathing hard and handling our traffic fine. Really happy to get this behind me and to see PFSense work so well for us. As for any crashes, so far there have been none. I'm worried this is something to do with the environment I was building this in. Everything is set to capture another crash if it happens but for now, I am just in wait and see mode. Thanks everyone for their input. Really appreciate all the guidance. Hopefully all this still yields something useful. Will let you know.

For anyone finding this later, it was the Accept DNS option in the Tailscale settings. After turning this off, ACB is working again.

@viragomann said in Can't get pfSense bridge to work with VF NIC: Yeah, if you pass through the hardware to a VM, the host cannot use it anymore. That is 100% not true. As I mentioned, I pass through VF, SR-IOV is designed just for this. Host device remains and is supposed to be able to talk to guests and to the outside. @viragomann said in Can't get pfSense bridge to work with VF NIC: You should rather create a bridge in Proxmox, connect the hardware NIC to it and assign and IP and connect the virtual interface of the VM, if you want to access both devices over the single NIC. That is exactly the description of the virtio interface I have, but it is slow, just ~1.3 Gbps in pfSense due to multiple reasons (issues opened for years and little if any progress is happening on them, so I wanted to pass through the physical hardware). On Linux virtio interfaces trivially push over 10 Gbps, but not in pfSense.

Was able to download a 2.7.2 iso, and fix everything, merely by reinstalling the system and using my existing config. please just offer normal installation iso on your main website fix this clear regression on 2.8/2.8.1 VTI tunnel routing is broken on this version, see my previous post. Reverted back (again) to 2.7.2.

@stephenw10 there is fallback to openvpn, but basically wireguard doesn't succeed after reboot and then i have to manually restart it and use filter reload. so i put the delay there to try and ensure wireguard gets to start properly

https://github.com/woffko/pfSense-pppoe-ha/blob/main/pfSense-pkg-pppoe-ha/stage/usr/local/sbin/pppoe_ha_event.php A bit improved code and logic.

@martinez said in DNS resolver failed to resolve some addresses: server that is authoritative for the org tld It is indeed one of the ORG authoritative servers: dig -x 199.19.57.1 ... ;; QUESTION SECTION: ;1.57.19.199.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.57.19.199.in-addr.arpa. 3274 IN PTR d0.org.afilias-nst.org. ... $ dig +trace wikipedia.org @1.1.1.1 ... ;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 5 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 86400 IN DS 26974 8 2 ... ;; Received 779 bytes from 2001:500:a8::e#53(e.root-servers.net) in 4 ms wikipedia.org. 3600 IN NS ns1.wikimedia.org. wikipedia.org. 3600 IN NS ns2.wikimedia.org. wikipedia.org. 3600 IN NS ns0.wikimedia.org. ... ;; Received 655 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 21 ms wikipedia.org. 180 IN A 185.15.58.224 ;; Received 58 bytes from 198.35.27.27#53(ns2.wikimedia.org) in 15 ms

ciao, non so se ti posso essere d'aiuto io attualmente uso PFSENSE su proxmox su nuc ho acquistato 2 schede di rete USB a 2,5 una collegata alla WAN ed una alla lan sembra che vada molto bene velocità in down 2100 in up 1000

Just tried on pfSense 2.8.1, seems to work fine. The VLAN is working fine, but the ixv driver itself seems to be flaky and sometimes not really working properly on boot, which in turn causes VLAN issues as well. But it is not happening nearly as often as it did in the past.

[image: 1760762744141-28314b2f-5d26-45d9-b6ae-381f978856b4-image.png] [image: 1760762785716-ee139398-adef-4d64-8ce4-bba8cce70782-image.png] config-pfSense.home.arpa-20251018044835.xml.zip u/p=admin/pfsense In case you are installing in the VM just import the machine into the Virtualbox, and install 2.8.1, then apply configuration. pfsense28_small_export.7z Should be resulted in: [image: 1760763171045-f75dffbe-bbb2-4f11-87bb-4739d1928c76-image.png] vtnet0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: wan2 options=900b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,LINKSTATE> ether 08:00:27:9d:bc:aa inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255 inet6 fe80::a00:27ff:fe9d:bcaa%vtnet0 prefixlen 64 scopeid 0x1 inet6 fd17:625c:f037:2:a00:27ff:fe9d:bcaa prefixlen 64 autoconf pltime 14400 vltime 86400 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> vtnet1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE,TXCSUM_IPV6> ether 08:00:27:f9:2b:76 inet6 fe80::a00:27ff:fe9d:bcaa%vtnet1 prefixlen 64 scopeid 0x2 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vtnet2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: SYNC options=800b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 08:00:27:77:b8:2c inet 10.0.222.1 netmask 0xffffff00 broadcast 10.0.222.255 inet6 fe80::a00:27ff:fe77:b82c%vtnet2 prefixlen 64 scopeid 0x3 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vtnet3: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE,TXCSUM_IPV6> ether 08:00:27:42:e3:96 inet6 fe80::a00:27ff:fe9d:bcaa%vtnet3 prefixlen 64 scopeid 0x4 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vtnet4: flags=1008802<BROADCAST,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,TXCSUM_IPV6> ether 08:00:27:67:ea:41 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> enc0: flags=0 metric 0 mtu 1536 options=0 groups: enc nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet 127.0.0.1 netmask 0x0 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> pflog0: flags=100<PROMISC> metric 0 mtu 33152 options=0 groups: pflog pfsync0: flags=1000041<UP,RUNNING,LOWER_UP> metric 0 mtu 1500 options=0 syncdev: vtnet2 syncpeer: 10.0.222.1 maxupd: 128 defer: off version: 1400 syncok: 1 groups: pfsync lagg0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: LAN options=4800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE,TXCSUM_IPV6> ether 08:00:27:42:e3:96 hwaddr 00:00:00:00:00:00 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::a00:27ff:fe42:e396%lagg0 prefixlen 64 scopeid 0xa inet6 fe80::1:1%lagg0 prefixlen 64 scopeid 0xa laggproto failover lagghash l2,l3,l4 laggport: vtnet3 flags=5<MASTER,ACTIVE> groups: lagg media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lagg1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE,TXCSUM_IPV6> ether 08:00:27:f9:2b:76 hwaddr 00:00:00:00:00:00 inet6 fe80::a00:27ff:fef9:2b76%lagg1 prefixlen 64 scopeid 0xb laggproto failover lagghash l2,l3,l4 laggport: vtnet1 flags=5<MASTER,ACTIVE> groups: lagg media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vtnet0.87: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: wifiap options=80000<LINKSTATE> ether 08:00:27:9d:bc:aa inet 10.0.87.2 netmask 0xffffff00 broadcast 10.0.87.255 inet 10.0.87.5 netmask 0xffffff00 broadcast 10.0.87.255 vhid 3 inet6 fe80::a00:27ff:fe9d:bcaa%vtnet0.87 prefixlen 64 scopeid 0xc inet6 fe80::1:1%vtnet0.87 prefixlen 64 scopeid 0xc groups: vlan carp: MASTER vhid 3 advbase 1 advskew 254 peer 224.0.0.18 peer6 ff02::12 vlan: 87 vlanproto: 802.1q vlanpcp: 0 parent interface: vtnet0 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492 description: WAN options=0 inet6 fe80::a00:27ff:fe9d:bcaa%pppoe0 prefixlen 64 tentative scopeid 0xd groups: pppoec nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

@cmcdonald FWIW as of pfsense 2.8.1 this still seems to be happening. I had everything running fine for years with ISC and today opted to get rid of the KEA nag and it all just fell apart. Most of my Ring devices just get this: Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: Failed to allocate an IPv4 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: failed to allocate an IPv4 address after 41 attempt(s) Oct 17 22:58:17 kea-dhcp4 20227 WARN [kea-dhcp4.alloc-engine.0x3ec6f4a16600] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 90:48:6c:2d:4d:44], cid=[no info], tid=0x25b805e: failed to allocate an IPv4 lease in the subnet 10.3.2.0/24, subnet-id 1, shared network (none) Going to switch back to ISC for a bit and see if anything changes. Config looks legit to me and I can't imagine a subset of Ring cameras (all the same make/model) would have a bug - it's a pretty common vendor really.

Yup that. The 7100 has some specific config complications because of the internal switch. But TAC can convert if for you so it will import into the 4200 directly.

@kesawi mDNS isn't like firewall rules, where you are controlling pathways between discrete interfaces. The way to think about this is that mDNS represents a common pool of services (I.E. DNS entries). The filter rules allow you to control what service names from each segment are added to the pool (inbound filters), and what service names from the pool are advertised to each segment (outbound filters). Do keep in mind that the ability to see that the service exists in mDNS does not mean that you can connect to it. Standard firewall rules for TCP/UCP still govern the ability to connect to a service. One other note: as indicated in the documentation, it is not necessary (or useful) to include _tcp or local labels in filters as these are redundant.

@Enso_ In the simple case, no. Yes you can edit the config file. Just be sure not to do a search and replace in case the NIC strings are used in an encoded string. If you're not using complicated VLANs you should be able to just restore in the web GUI and it will ask you to assign the interfaces. Save, then apply to reboot. (note if it doesn't work it will stop on boot to ask at the console to reassign interfaces)