Messages

On the two Unbound settings:

Forward TCP upstream: This tells Unbound to use TCP instead of UDP when forwarding queries to DNSCrypt. Leave this off unless you are seeing UDP truncation errors. DNSCrypt handles transport internally and the default UDP forwarding works fine for most setups.

Forward first: This tells Unbound to attempt recursive resolution itself first and only use the forwarder if that fails. You want this OFF when DNSCrypt is your upstream. With it on, Unbound may bypass DNSCrypt entirely and resolve queries directly, which defeats the purpose. Turn it off so all queries flow to DNSCrypt.

For the DNS leak when DNSCrypt is disabled: when you disable the DNSCrypt forwarder, Unbound has no upstream configured and falls back to the DNS servers set on your WAN interface, which come from DHCP and are your ISP's servers. To fix this, go to System > Settings > General and set explicit DNS servers there, such as 1.1.1.1 or 9.9.9.9. These override the DHCP-provided DNS and will be used by Unbound as fallback when DNSCrypt is not active.

When DNSCrypt is running and configured as the Unbound forwarder, none of this matters because all queries go through it. But when you toggle DNSCrypt off for testing, having ISP DNS as the fallback is expected unless you set static upstream servers in General settings.

To confirm DNSCrypt is handling queries when active, run a quick check from the OPNsense shell:

dig @127.0.0.1 whoami.akamai.net

If it returns your real IP via a non-ISP resolver, DNSCrypt is working.

Hey,

The "IP packet with unknown IP version=0" error is a classic symptom of an MTU mismatch causing fragmentation at the wrong layer. When an OpenVPN tunnel receives a fragment that starts with 0x00 instead of 0x40 (IPv4) or 0x60 (IPv6), you get exactly this message. It means a partial or mis-aligned packet is arriving at the tun interface.

MSS clamping helps for TCP but does nothing for UDP traffic or for fragmentation happening at the OpenVPN layer itself. The more reliable fix is to set fragment and tun-mtu in the client config.

Try adding these to your custom options on the client:

fragment 1300
mssfix 1260
tun-mtu 1400

The fragment directive tells OpenVPN to fragment packets at the VPN layer before they hit the tunnel, which prevents the underlying IP fragmentation that causes the version=0 issue. The tun-mtu value accounts for the overhead of the OpenVPN header plus your ECC TLS handshake frames.

The P-521 certificate itself is not adding per-packet overhead once the session is established -- the asymmetric key size only matters during the handshake. But it is worth double-checking your tunnel uses UDP rather than TCP, because OpenVPN over TCP adds an extra layer of retransmission that can compound fragmentation problems significantly.

One other thing to check: if you have any compression enabled (compress or comp-lzo), disable it. Compression can misalign packet boundaries and produce exactly this error, and it offers almost no benefit on already-compressed traffic.

If the fragment + tun-mtu adjustment does not help, enabling verb 4 logging will show you the exact sequence of events leading up to the disconnect and make the root cause clearer.

Hope this is useful.