Messages

1

24.7 Production Series / Re: pfsync in HA setup leads to regular tcp stalls

« on: November 12, 2024, 02:11:26 pm »

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

2

24.7 Production Series / Re: 24.7.8 rebooting every few hours

« on: November 11, 2024, 08:13:23 am »

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

3

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 27, 2024, 05:21:23 pm »

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).

4

24.7 Production Series / Re: Disable CRC offloading command line

« on: September 25, 2024, 04:53:43 pm »

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

5

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 04:38:52 pm »

> 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.

6

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 04:14:36 pm »

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]

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.

7

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 04:06:23 pm »

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

8

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 03:53:30 pm »

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]

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]

tcpdump -i wan-interface host 8.8.8.8 and port 53


9

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 03:40:50 pm »

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.

10

24.7 Production Series / Re: [24.7.4] Some UDP traffic causes packet loss

« on: September 25, 2024, 02:51:21 pm »

I'd be disabling RSS and re-testing

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

11

24.7 Production Series / Re: Data Ciphers are missing in OpenVPN export configuration. Is it a bug?

« on: September 25, 2024, 08:49:57 am »

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'.

12

24.7 Production Series / Re: Disable CRC offloading command line

« on: September 25, 2024, 08:13:20 am »

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

13

24.7 Production Series / Re: Data Ciphers are missing in OpenVPN export configuration. Is it a bug?

« on: September 24, 2024, 07:56:54 am »

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]

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

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

Code: [Select]

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

14

24.7 Production Series / Re: Do I need to enable PowerD on modern Intel CPUs compatible with EIST

« on: September 18, 2024, 08:52:02 am »

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]

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

15

24.7 Production Series / Re: Do I need to enable PowerD on modern Intel CPUs compatible with EIST

« on: September 18, 2024, 08:48:50 am »

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]

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]

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]

sysctl dev.cpu |grep cx