Messages

Zoals de topic aangeeft heb ik een DEC740 te koop. Top machine maar in onbruik geraakt.

- Aangekocht op 13/11/2023.
- In perfecte staat.
- Minimum bod - 500€

This tutorial is 100% spot on and works as advertised, love it!

Did you ever try this with IPv6? I would like to use Destination routing instead of based on source.
It works well for IPv4 but nowadays a ton of sites do have AAAA records too.

I've tried adding the IP address that you get in the .conf to the Interface/Peer but I run into the unknown with the gateways.
You can only add one gateway to an instance .. which makes this hard. Should I make an IPv6 only instance?

Awesome, that worked! Thanks @Franco!

I have an expired certificate in the Trust section that doesn't want to renew (CA key missing) and cannot be deleted because it is in use by NTOPNG, but that isn't installed. Any suggestions on how to get rid of this one?

You just need to turn off 'proxying' in Cloudflare.

For this to work you need to point your ha / pikvm DNS records to the IP address of the Caddy proxy. This can either be your internal FW ip or if you have turned on hairpinning you can use your external IP address.

I'm using it in the exact same fashion as what you are trying to achieve.

I'm using a DDNS record for my router at Bunny and CNAME all the internal domains I want accessible to that DDNS record. This way I can use hairpinning to the services on my DMZ to which I proxy.

Have a look at this topic :

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

See if reverting your kernel to the non_sa version makes life better. I still got a ton of blocked icmp ipv6 issues with the 24.7.x kernel before this.

Are these also known to -hog- a device like the DEC740? I really saw lag spikes / interrupt spikes when it was turned on.

You can easily check if the SA is the culprit by trying the kernel with the SA completely removed via

Code Select Expand

opnsense-update -zkr 24.7.3-no_sa

and reboot, see this.

With that kernel and the logging set to various errors, the issue is gone. I do get a lot of

Code Select Expand


<13>1 2024-09-06T15:34:20+02:00 opn.x100.be kernel - - [meta sequenceId="68"] pf: dropping packet with ip options
<13>1 2024-09-06T15:34:21+02:00 opn.x100.be kernel - - [meta sequenceId="69"] pf: dropping packet with ip options


The underlying cause is indeed not solved -- but changing the logging level stopped it from creating the entries in my log files. Removed the [solved] tag for now.

Turning the logging lower also stopped my latency spikes.

Firewall > Settings > Advanced : Debug - Generate debug messages for various errors

This was the culprit. Still means there is something wrong in the ND/PF story. Might this be worth looking at, @Franco?

I've done a tcpdump on the internal interface (LAN) and it's a 100% match with the ND process NS/NA on that interface.

At this moment, my logs are flooded with the "pf: ICMP error message too short (ip6)" message.
Grepping & counting the latest.log gives me 53k entries and it spams at a rate of 10/s.

Does anyone know/understand where this comes from and what I need to do to stop it?

Going back a few days gives me numbers of up to 350k/day.

I saw a lot more power being consumed with the IPv6 issues & the health reporting hogging the CPU.
Fixed with the -nd kernel.

There is an issue being tracked : https://github.com/opnsense/src/issues/218

Useful to follow that one.