Messages

Are you using unicast sync on both opnsense and pfsense?

The opnsense documentation seems to suggest specifying a unicast address, but the pfsense documentation seems to lean more towards 'not' and using multicast.

EDIT: Going back a bit, looks like someone else had an issue with Unicast:

https://forum.opnsense.org/index.php?topic=34522.0

There were Intel NIC driver changes in 24.7.8 - if you have a saved boot environment, you could try rolling back.

This is very odd, I will admit there are things that just don't make sense to me :)

- That you DO see (tcpdump) the DNS request enter the LAN interface and pass out of the PPPoE interface.  Which means it's passing through opnsense, i.e is not being blocked, dropped, etc.

- That you DONT see the issue with OpenWRT, suggests the connection itself is good

- That you DO still see the problem with a completely (completely-completely?) clean install

Have you ruled out things like specific ports (on the device, or switch ports, etc), cables, etc?

If it's easy-ish to do, I think opnsense 24.1 would be interesting to test (i.e FreeBSD 13, rather than 14.1).

I'd also make use of the Cloud Backups .... again, a life saver for when the drive decides to 'give up the ghost' at LOL o'clock :)

https://docs.opnsense.org/manual/how-tos/cloud_backup.html

> Do you mean the provider's firewall?

Your firewall, opnsense :)

From your tcpdump, you see the DNS request in the PPPoE interface dump, so it makes it through opnsense and gets 'dropped onto the wire' of the WAN interface.

Well, it seems to make it through the firewall...

Can you dig @1.1.1.1 when you see the problems with 8.8.8.8?

Are you sure your ISP doesn't rate limit UDP traffic?  If you remove opnsense completely from the equation, if you can, and use an ISP router, do you see the same then?

From your timestamps, I'm guessing you're in South East Asia (GMT+7) somewhere?  I know for a fact some of the ISPs in that region do filter/limit traffic.

EDIT: I also missed this:

Code Select Expand

21:04:17.791183 IP 100.68.87.90.50947

... you're behind CGNAT? 

I think the next step is to prove that you don't see the same problem, when you remove opnsense, i.e using the ISP supplier router if you have one.

Another question: Did you see this problem on 24.1?  Or have you only ever run 24.7?

I don't see this mentioned here ... so ...

... have you checked the firewall logs for drops? 

If you tcpdump the LAN side interface, do you see your DNS requests ingress to the interface?  For example:

Code Select Expand

tcpdump -i lan-interface host 8.8.8.8 and port 53


If you do, then if you tcpdump the WAN side interface, do you see your DNS requests egress the WAN interface?

Code Select Expand

tcpdump -i wan-interface host 8.8.8.8 and port 53


Don't disable RSS.

This is something that Crowdsec might be responsible for...is it running ?

This makes zero sense.

The default install, is with RSS disabled.  If you have problems, the absolute first thing anyone should do, is go back to stock/default.

I'd be disabling RSS and re-testing :)

... i.e defaults, for everything, no custom stuff at all. Re-test.

I'm not sure this patch fixes the problem - I added an update to the github issue.

Although it is not really a 'problem' - it's not really an error, just a 'note'.

Seek and you shall find ... on the next page of forum posts :)

System makes backups anyway - option 13 on the console:

https://forum.opnsense.org/index.php?topic=42951.0

I would like to make sure if it really uses "Data Ciphers AES256-GCM" with OpenVPN client (Community edition)?

Did you view the client side connection log?

Recent versions of OpenVPN support cipher negotiation between server and client - so, even if you have, for example, AES-128-CBC set in the config, you'll likely see a 'PUSH' line ...

Code Select Expand

PUSH: Received control message: 'PUSH_REPLY, ................... cipher AES-256-GCM'


...with AES-256-GCM and then....

Code Select Expand

Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

N.B. data-ciphers-fallback is a server-side option to support older clients, where 'data-ciphers' is not supported:

https://community.openvpn.net/openvpn/wiki/CipherNegotiation

i have an i5-5200u CPU, this cpu has only speedstep tecnology available.
Without turning ON powerD, the cpu didn't scale its frequency.

Speed Step - you need to use Power D.

Speed Shift, you don't use Power D and rely on the CPU.

For Speed Shift, you need to see the below in dmesg/boot log:

Code Select Expand

hwpstate_intel0: <Intel Speed Shift> on cpu0

As you state, you need to use Speed Step and PowerD - as this is what the CPU supports:

https://www.intel.com/content/www/us/en/products/sku/85212/intel-core-i55200u-processor-3m-cache-up-to-2-70-ghz/specifications.html

Therefore, I set machdep.hwpstate_pkg_ctrl=0 as a Tunable value? Same as I did with:

I think you have to reboot for this one, not sure/clear if you did?

Code Select Expand

dev.hwpstate_intel.0.epp


There is 1 per core, in my case 0 -> 7

After enabling it in Tunables I didn't notice any difference in power consumption.

To be sure, make sure you're setting for each core in your machine, then reboot and check after a restart - with PowerD disabled as well.

Then, check the core frequency - and see if it scales under load/UI access etc.

Code Select Expand

sysctl dev.cpu | grep freq


where I did some comparisons with Linux, and I think there are some opportunities to optimize power consumption with FreedBSD, if it was possible with Linux.

FreeBSD != Linux - the latter, in my experience, undoubtedly has better power management.  Linux has more users that require power management, laptops etc.

At the 11-13 watts you state in the other post, I think you have to be content with that - I'm content with 35-40 ish, on baremetal hardware.  But I have all ASPM disabled in the BIOS for stability, 8 x 1G and 4 x 10G interfaces.

I had stability issues with lower than C1 C-states some while ago, maybe even on different hardware than I'm running now, I can't remember, so by default I now disable anything lower than C1 in the BIOS anyway.

But you can see what C states are being used, what percentage of the time:

Code Select Expand

sysctl dev.cpu |grep cx