@SteveITS Thanks, as I think you clarified a simple mistake I made. After you said "add/configure" the interfaces I realized I made a miscalculation of how simple it is to refresh these. The NAT/FW/DHCP tables only utilize WAN and LAN assignments and those assignments are programmed to the physical hardware. WAN currently being re0 would be igb0, LAN from re1 to igb1. So this would only take about 5 minutes. Silly of me. Thank you sir, the obvious eluded me.

OP, if you follow this you cannot go wrong, plain and simple: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

Mmm, that could be a gui bug only since the IPs are the same. Edit: Yup I see that here too. Digging...

Yup you would only see states while they're still active. So if you are not seeing attacks that often you'd have to get lucky to catch it. But you should see those by filtering for: 22 [image: 1753575304735-screenshot-from-2025-07-27-01-11-58.png] What rules do you have on the VPN interface(s)? It would be unusual to see connections being forwarded to you there though.

@Gertjan ok, thanks for the nudge, I've worked it out. I set the FritzBox to do the PPPoE and act as a router (not that I'm using the routing bit). I Fritzbox has a 192.167.178.x subnet. Give my pfSense a static IP address on that subnet. Make sure WAN interface allows "local" IP addresses. Set the "Exposed Host" setting on Fritzbox to forward all internet traffic to the pfSense box. With just the netgate doing evertyhing I was getting 560 down 900 up. With this config I'm getting 685 down, 850 up. Which feels better. Thanks for the help.

From the ntp doc: 8. Authentication Four commands require authentication to the server: config-from-file, config, ifstats, and reslist. An authkey file must be in place and a control key declared in ntp.conf for these commands to work. If you are running as root or otherwise have read access to the authkey and ntp.conf file, ntpq will mine the required credentials for you. Otherwise, you will be prompted to enter a key ID and password. Credentials once entered, are retained and used for the duration of your ntpq session.

Yes as long as it matches the traffic against a rule that's above the policy routing rule that will work.

@hansolo77 Checking what pfSense does every hours sharp - or some other regular moment, is a good start. But don't stop there ! Check also : all devices connected to your pfSense LANs ! as these can all do something at that very moment. ISP love to sell you numbers. Like 'a 1 Gbit/sec connection just for you'. If the country where you live has some enforced consumer rights movements, these ISPs add now at the bottom of the contract "... or whatever we have avaible for you". After all, ISP tend to hookup up entire roads, cities, etc to one main equipment with, guess what, a limited, up front determined throughput. For example : you all share the same 100 Gbits very expensive router/switch. If more then 100 clients are hookup up to this expense router, then ... you get it : what happens when every all these clients, all their devices, do 'something' at xx sharp ? So you have to check all of them (which you probably can't do) - or disconnect them all while you are testing. You can even go one level higher, and check all the POP of your ISP .... Inspecting the cron list is one thing. You still have to use the console or better, the SSH access, and use menu option 8, and type 'top'. Make sure the list is sorted at 'CPU usage'. Use also this command : ps aux and look for the process that mention minicron, these are also timed processes. On my pfSense : [25.07-RC][root@pfSense.bhf.tld]/root: ps aux | grep 'minicron' root 89370 0.0 0.1 13980 2484 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh root 89826 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 300 /var/run/ipsec_keepalive.pid /usr/local/bin/ipsec_keepalive.php root 90216 0.0 0.1 13980 2500 - I 18Jul25 0:00.17 minicron: helper /usr/local/bin/ipsec_keepalive.php (minicron) root 90313 0.0 0.1 13980 2476 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts root 90699 0.0 0.1 13980 2500 - I 18Jul25 0:00.01 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts (minicron) root 90868 0.0 0.1 13980 2504 - I 18Jul25 0:00.20 minicron: helper /usr/local/bin/ping_hosts.sh (minicron) root 91166 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data root 91830 0.0 0.1 13980 2504 - I 18Jul25 0:00.00 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data (minicron) root 84792 0.0 0.1 14076 2688 0 S+ 08:49 0:00.00 grep minicron The "/etc/rc.expireaccounts" is an hourly process, and afaik it doesn't communicate, and takes a split second to execute. Normally, with a vanilla pfSense (no addons, no pfSense packages) there is no 'download every hours xx Mbytes' process. pfSense will update some small files ones a month, will check up with the Netgate update servers to see if there are pfSense or package updates avaible, but this will not create big loads of traffic, and last probably for a second or two.

Do you see anything blocked in the firewall logs? Connectivity from that host is otherwise good? Is it using the same DNS server(s) when configured statically? Ultimately I would run a packet capture when you run the failing task and see what's actually failing there.

Yes, it's in the RC.

Do you have the NDI from the device? If you send that to me in chat I can check for an ACB key.

@stephenw10 Alright might have been dropped after i initially logged in and then appeared when i went to the update tab. thanks again really appreciate your reply and time as always.

@jhg said in Installing 2.8 behind archaic PPPoE/VLAN from CenturyLink: Is this available yet? It's in testing now. No issues so far so should be available soon,

What gets logged when you run that in 2.8?

@wc2l said in Teams Issues: teams.microsoft.com works just fine. Host "msg.teams.microsoft.com" could not be resolved. Same for me. edit : while waiting, read also C:\Program Files (x86)\Microsoft Teams Network Assessment Tool\Usage.docx - this is a Microsoft tool with a manual / notice .... ( )

@luckman212 Click on the image : [image: 1753189717239-1c8c8a2b-ed5f-4dd1-8694-8be0e58350e8-image.png] I didn't test other search engines ... edit : the link @kpa posted is, imho, the best answer ( and totally not-FreeBSD related ^^ ).

Yes that's correct. The 1100 has only one NIC (mvneta0) and an internal switch with VLANs to separate the ports. But, as I said, you shouldn't need to make any changes there it's detected and set automatically for any Netgate device.

@Gertjan shame on me! Didn't see that ... thanks a lot!

Because 10.60.0.252 is the server end of the VPN tunnel at pfSense. The local DNS resolver (Unbound) listens and responds on that IP and that is where the override is set. Where as 8.8.8.8 is Google's DNS service that knows nothing about any local overrides you might have set. When clients use that DNS server is bypasses any local DNS overrides.

@SteveITS Thank you for the clarification. You're right — better to be safe. I’ll update FW2 when I'm on site, and then FW1, which is my usual one.