@mcury Thanks for the suggestion, but it's not feasible to do this on a large network with 1,600 computers. I saw a configuration that uses a firewall rule, but the example uses Active Directory servers 192.168.1.250 and 192.168.1.251... but I don't know how it would apply to my Pfsense + Nxfilter. https://youtu.be/aEKCA67kv5I?list=PL3Sj98RICiBGwqBgTGDTCMlwwwF6fiD2a

@stephenw10 bingo...its a 10 for you sir

Hello! I know this post is a while old, but others may experience the same issue. I have an XG125 appliance and had the same problem. How did I solve it? The appliance has 8 ports, and pfSense detects them all, but the ports are reversed in relation to the silkscreen numbers. Here is a list of ports: ibg0 = port 5 ibg1 = port 6 ibg2 = port 7 ibg3 = port 8 ibg4 = port 1 ibg5 = port 2 ibg6 = port 3 ibg7 = port 4

Hello! I know this post is a while old, but others may experience the same issue. I have an XG125 appliance and had the same problem. How did I solve it? The appliance has 8 ports, and pfSense detects them all, but the ports are reversed in relation to the silkscreen numbers. Here is a list of ports: ibg0 = port 5 ibg1 = port 6 ibg2 = port 7 ibg3 = port 8 ibg4 = port 1 ibg5 = port 2 ibg6 = port 3 ibg7 = port 4

@stephenw10 The 2nd ports on each machine did not. I changed the PCI passthrough to allow only one passthrough on each machine with all functions checked, which now provides two Ethernet devices in PfSense. Now, one works, not the other. One machine works (10.1.0.50), the other shows that the 2nd port (on 10.1.1.50) is down on the interface status screen.

Well I wouldn't agree that they can't get hot enough. They definitely can! But they don't have a sensor that FreeBSD can usefully read.

The document not new enough message is not an error. It just means it's already up to date. The only actual error there is: * ipv4 connect timeout after 19808ms, move on! * Failed to connect to pkg00-atx.netgate.com port 443 after 30009 ms: Timeout was reached * Closing connection That's a problem, it should be able to connect there. But it does successfully connect to the other pkg server. And then later is able to connect to pkg00. So there could be an intermittent connection issue.

You show a VLAN configured on the LAN physical interface. VLANs and netmap (the underlying FreeBSD kernel device used to support inline IPS mode operation) are not great friends . While it can work, a VLAN interface requires the use of an emulated netmap adapter which is a software construct that is much less efficient than the hardware adapter netmap interfaces. Another issue that can severely affect throughput is the number of enabled rules. More rules means more CPU work and less throughput. Lastly, you may need to fine-tune settings for the NIC adapter using sysctl variables. You would need to perform your own research for that. I have no experience with that and thus no tips to offer. Legacy Mode uses the PCAP library to simply grab copies of packets traversing an interface. Suricata is then fed those copied packets to digest while the original packets continue on to the host. That means Legacy Mode will leak the initial packets and let the connection be made. Then, after Suricata has time to compare the packet or packets to the signatures and there is a match, a pfctl firewall API call is made to place the offending IP address into a pf table for subsequent blocking. Another API call is then made to flush any active states that are associated with the blocked IP. Also noticed that you posted this same issue on the upstream Suricata forum. That will not help. The Suricata package on pfSense is highly customized and the developers upstream are not privy to the inner workings of the Suricata setup used in pfSense (nor in OPNsense, for that matter). Both *Sense products use a GUI front-end for managing Suricata. Suricata itself (the binary used on Linux and Windows) has no GUI. It is managed completely at the command line level. But that is not true on pfSense as the GUI code manages the underlying binary and controls the creation of the suricata.yaml file.

Yes I reproduced here and asked our devs about it who confirmed the likely cause. Work is in progress.

CLOSED:SYN_SENT- means nothing is replying.

Hello, The issue is resolved! Without me having to change anything / touch a thing , I tried adding an ASN this morning and it worked; the dropdown list appeared. Thank you very much to everyone who took the time to reply. Have a good day, everyone.

Sorry for the delay, I got stuck on some other testing. I'll try to get this setup today.

Failed to reproduce it here so far. So, yes, I think trying ctl+t there would be the next step.

@veddy254 Replaced by _1 already pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3_1.pkg

It worked! I needed to add the NxFilter IP in Captive Portal > Allowed IP Addresses... however, for blocked sites, for example in the Porn category, the NxFilter blocking page is not displayed, it just keeps rotating the browser without accessing the site. I will continue looking for a solution for this. [image: 1760523860187-1dbf1da9-2786-446f-8ac2-30b77b06b1a3-image.png]

@BBcan177 Will find a solution for this sooner. Thanks in advance. :)

@perrin said in new if_pppoe Backend - getting HA/CARP to work like in MPD: In my case I am running two Proxmox hosts each running a virtual pfSense, one being master one being slave. I am running the same configuration. Looks like I have found something related to this VIP reconfiguration issue. I will do some tests and report back if I find anything else.

@stephenw10 nothing in the logs for the DHCP client. I will enable the debug logging and check the logs upon the next reconnect

@SteveITS Hi Steve, the log is showing below. It seems that it is using that by default. Oct 14 19:40:17 kea-dhcp4 25524 WARN [kea-dhcp4.dhcp4.0x2fcfd0e12000] DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64 I can modify it, per the below sed -i '/"Dhcp4": {/a\ "multi-threading": { "enable-multi-threading": true, "thread-pool-size": 2, "packet-queue-size": 64 },' /usr/local/etc/kea/kea-dhcp4.conf But I want to do it in a way that is persistent through upgrades