Re: job dies with ERR=error:0A000119:SSL routines::decryption failed or bad record mac

On Wed, Mar 5, 2025, at 4:12 PM, Udo Kaune wrote:
> Am 05.03.25 um 17:08 schrieb Dan Langille:
> 
>> I would be curious to see if you are able to send traffic directly from host to host without any VPN involved, though I think simply testing the remote end's ability to download a large file successfully could be more important. 
>> The hosts have been in place for years. This is not a new VPN - it's been around about 10 years. What is new: the gateway. It was replaced. It went from pfSense to vanilla FreeBSD. I think I'm missing some of the magic pfSense did in the configuration.
>> 
> 
> Hi Dan,
> 
> This smells like packet size. Standard ICMP (ping) packets are too small to see anything. Did you fiddle with max-mtu/link-mtu in the OpenVPN config?

No, nothing in there:

[22:25 gw01 dvl ~] % sudo grep -i mtu /usr/local/etc/openvpn/openvpn.conf
[22:25 gw01 dvl ~] % 


> Try to perform Path MTU Discovery manually (ping -M do -s xxxx <client address>). Then on the client side set OpenVPN *link-mtu* value to the actual MTU minus 28. Or rely on OpenVPN to discover the correct value by using mtu-test in the client config.

First, I tried mtu-test on one client:

Mar  5 22:32:48 r720-02 openvpn[17649]: Attempting to send data packet while data channel offload is in use. Dropping packet
Mar  5 22:36:29 r720-02 openvpn[17649]: NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

Interesting, It's OpenVPN 2.6.13

In this case, are you suggesting I set mtu on the client to 1472? And I tried: mtu 1472 - but openvpn doesn't like that and refuses to start ("Unrecognized option").

For testing the MTU, on FreeBSD, that's this:

[22:48 gw01 dvl ~] % sudo ping -D -s 1472 10.140.0.217
PING 10.140.0.217 (10.140.0.217): 1472 data bytes
1480 bytes from 10.140.0.217: icmp_seq=0 ttl=64 time=13.657 ms
1480 bytes from 10.140.0.217: icmp_seq=1 ttl=64 time=6.396 ms
1480 bytes from 10.140.0.217: icmp_seq=2 ttl=64 time=8.549 ms
1480 bytes from 10.140.0.217: icmp_seq=3 ttl=64 time=5.987 ms
√1480 bytes from 10.140.0.217: icmp_seq=4 ttl=64 time=7.602 ms
1480 bytes from 10.140.0.217: icmp_seq=5 ttl=64 time=7.889 ms
^C
--- 10.140.0.217 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.987/8.346/13.657/2.529 ms

[22:48 gw01 dvl ~] % sudo ping -D -s 1474 10.140.0.217
PING 10.140.0.217 (10.140.0.217): 1474 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
^C
--- 10.140.0.217 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

> 
> The ping will fail for me on xxxx=1474 and suffice on xxxx=1472 against one of my OpenVPN clients.

Seems to be the same for me.

> 
> https://www.reddit.com/r/networking/comments/18b3y8h/packet_size_issues_over_vpn/
> 
> https://community.zyxel.com/en/discussion/14013/ssl-vpn-disconnect-due-to-invalid-packet-size
>  

Thank you.

--
  Dan Langille
  [email protected]

_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users