Also verify the server is actually resolving against pfSense and doesn't have some hard coded DNS built in.

Yup that also works:

[2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x12 PADI retries: 0 PADR retries: 0 time: 00:00:21 sppp: phase network authproto auto authname "Test" peerproto auto [2.8.0-RELEASE][admin@m370.stevew.lan]/root: /usr/local/sbin/pfSctl -c 'interface reload opt2' OK [2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x7 PADI retries: 0 PADR retries: 0 time: 00:00:01 sppp: phase network authproto auto authname "Test" peerproto auto

We use lots of different 10G SFP+ at work. They do certainly vary, but rarely have over heating issues as long as they are in a high end switch/router such as Juniper, Cisco, etc.

We did have quite bad over-heating issues in a TP-Link SX3008 switch. The problem was the SFP cages, so we modified the switch adding cheap self-adhesive heatsinks. Attached pictures show the main board before & after. Approx 20degC SFP temperature reduction.

2022-08-12 13.59.18 TP-Link.jpg 2022-08-13 17.32.41 TP-Link.jpg

@bigbig

You shouldn't need to 'cron' dhclient.
See for yourself : Get the driver name of the dhclient interface used (not WAN but the NIC driver name), for example 'igc0'.
You'll find a file called /var/db/dhclient.leases.igc0 - have a look at it.
dhclient knows when to renew, normally half way the lease duration.
So if the total lease time is 300 seconds, dhclient will renew after 150 seconds.
Totally insane of course, but maybe normal knowing what transport medium is used 😊

The dhclient process stays active during the wait, check :

ps aux | grep 'dhclient'

and it 'sleeps' until the delay is over, and it renews.
Normally, dhclient doesn't fail or abort, something that can only happen, I guess, when the interface itself is 'gone'.

Check the Status >System Logs > DHCP for 'dhclient' messages (issues).

@stephenw10 not sure. Anyway, just wanted to report it in case it is something that needs to be fixed for the later releases.

@stephenw10
Yeah, no NTP servers are that good. Even the 10 gigabit ones with reflectors..

Up

Hi @patient0 ,
Yes. You're right.
I uninstaled Squid and perform "mv /usr/lib/libc++.so.1 /root"
Then install Squid again and now all is fine.

Thanks,
Mucip:)

@frodo
Thank you Netgate! Working now :-)

Hi @Gertjan, thanks for your input.

To answer your questions:
• Approx. 150 leases, of which 78 are static mappings (classic MAC → IP).
• DHCP lease time is default at 7200, not shortened.
• Based on log parsing, I see about 3–5 DHCPACKs per hour, so roughly 80–100 per day.
• One active DHCP server on the LAN.
• About 20 WiFi clients, managed via a UniFi Controller, connected to pfSense.
• Typical clients: mostly Linux systems (servers, VMs, containers), some macOS devices, smartphones etc. No captive portal or guest networks.

Let me know if I can provide any more detail.

Hmm, nothing logged before or after that?

It should have tried to reconnect.

If you see it again you can run pppcfg pppoe0 to see what it's doing. It will show you the connection phase and state.

Great. Thanks for testing! 👍

Nevermind, my mistake, i tried to delete this thread but it told me i dont have permission.

I had an old disconnected interface in my LAGG that I removed and it seems to have fixed the issue....so far anyway.

Not in the normal pfSense config. nginx listens on all IP addresses.

CE did come preinstalled on some Netgate devices. The Minnowboard Turbot (MBT) for example.

But, yes, from 2.7.0 run certctl rehash to see the update.

No. YOu can only policy route traffic as it enters the firewall so usually from some internal subnet. Traffic from localhost is already inside the firewall. By the time it is leaving an interface and could be filtered outbound the routing decision has already been taken.

@viragomann

I wish to do this using a proxy service that I have subscribe to however they provide a hostname and port so I don't think I can use the GW method here.

@brookheather ~ After almost 8 days up time, this is what it shows:

MTU: 1400
In/out packets: 116406954/41636681 (134.50 GiB/6.15 GiB)
In/out errors: 0/2
Collisions: 0

Also, my Internet connection is 1Gbps up and down fiber.

RPSmith...

@Gertjan said in Normal traffic graph in "idle"?:

A Windows OS ? You ever heard about telemetry data ? The keylogger you installed on your PC

It's Ubuntu though ;)

@Gertjan said in Normal traffic graph in "idle"?:

What is that ?

A website to check what is behind an IP. For example:
https://otx.alienvault.com/indicator/ip/34.149.144.89

@Gertjan said in Normal traffic graph in "idle"?:

That's your browser doing auto-captive-portal detection. This is port destination 80 TCP traffic, right ?

Yep port 80 traffic

@Gertjan said in Normal traffic graph in "idle"?:

You were actually using all this stuff all the time. It's always a good thing to find out how things work.

I am still trying to figure things out. I haven't gotten into the packet capture part yet. Only superficially by checking Snort captures. I also googled what TCP Dup ACK is but I don't know if it is something to worry about or a normal occurance. The last couple of days I saw 3 out of 5 Windows computers make outgoing connections to malicious IPs that are flagged on otx.alienvault and it makes me worried. Even on a fresh Windows install I had this happen by a service that should only communicate on LAN (Windows LanmanServer). I just blocked the whole IP range to be safe. It was also blocked by Snort with "ET INFO Packed Executable Download", Misc activity 3. I hope it's just a false positive.

@stephenw10 said in Normal traffic graph in "idle"?:

No. The source and destination are stll the same.

Ok great. Thank you :)

@stephenw10 Yes, I meant Wh it went from ~900 watt hours to ~825 watt hours per day.
2025-06-10 13_46_34-Microsoft Excel - Yesterday.txt.png