Use different NIC types. AltQ is not supported by whatever devices you have. You should avoid USB NICs in general.
See: https://docs.netgate.com/pfsense/en/latest/hardware/network-interface-drivers-with-altq-traffic-shaping-support.html
In addition to the list linked there we add VLAN interfaces so one option would be to add vlans and apply the shaping on that.
Steve
The NAT reflection mode will make no difference to clients connecting externally or to the server itself connecting out.
Do you see traffic blocked in the firewall log?
Do you see oncoming states opened to the server?
Steve
With two virtual drives you can still recover one from the other if the filesystem is somehow damaged beyond repair.
I don't think I've ever seen it done though. Generally if you're running on a hypervisor you probably have a UPS.
Steve
@nback said in ntp only connecting to some time servers:
Fixed it! Set a default gateway for ipv6.
You shouldn't have to. That should happen automagically, through router advertisements.
OK - have removed all the other interfaces from system/routing/gateways, and have left the 1 remaining interface (WAN) as the selected default. No problems connecting to any of the VPN server instances. And DNS resolution remains functional. I will continue to monitor, but it really does appear that this problem has now been solved. Thanks again to @johnpoz and @stephenw10 .
@stephenw10
Thank you for your concern in my case.
When the configuration from the second provider is directly done to the PBX Box while the first is through pfsense, I can use both Providers at the same time. My situation is, I do not want to hook providers into into the PBX hoping in the future I may have other Voice Connection from other providers as well. Connecting the PBX through the switch I think in my case is the optimal one just as I described in the diagram.
-Lusekelo
Yes, for most that is not required but if the keep alive packet spacing is too high you may need to set conservative mode. Or use custom timeouts as you did.
Steve
Setup Limiters to whatever bandwidth you need. Put default internet traffic in to those Limiters with firewall rules on LAN. Pass local traffic with rules above those that are unlimited.
https://docs.netgate.com/pfsense/en/latest/book/trafficshaper/limiters.html
Steve
Keep in mind that 1.1.1.1's primary goal is harvesting your DNS requests. Not replying on your ICMP requests, so if they (1.1.1.1) decide to stop doing that, for example for bandwidth reasons, your WAN could get marked as offline.
I'm not sure what's going on with this thing, creating or changing rules doesn't take effect unless it's rebooted. That's new behavior, it's always been immediate before this. I'm going to rebuild it tomorrow. Thanks everyone for the help.
But it is only the reply traffic that goes back out though pfSense yes?
As I said you will need an OUT rule on WAN since that will also be out of state TCP traffic.
Let's see a screenshot of the blocked traffic you're seeing,
Steve
Ok so:
Run through the OpenVPN remote access setup wizard
Create a test user in System > User Manager and make sure you add a client certificate to that user created against the same CA the wizard created.
Install the Client Export Package. You should now see the various client types available for your test user in VPN > OpenVPN > Client Export.
Pretty much what it says here:
https://docs.netgate.com/pfsense/en/latest/book/openvpn/using-the-openvpn-server-wizard-for-remote-access.html
Steve
I had that situation months ago. I called the ISP and asked for a public IP and I got it immediately with no discussion.
But that may depend on your internet contract.
Maybe IPv6 is an option for you.
Yes, there was a bug in 2.3.X that prevented IGMP proxy running on VLAN interfaces. You can read about it in that bug link I posted above.
That's just another reason you should upgrade, that is fixed in current.
Steve
Thank you everyone for assisting
I wrote another script on powershell which works for me, will post when it is fully functional with other additional features.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.