OpenVPN bad encapsulated packet length question

[amrogers3]

I am seeing this in my VPN logs

WARNING: Bad encapsulated packet length from peer (18245), which must be > 0 and <= 1768 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]

The VPN connection does not disconnect and I don't see any issues regarding this warning, however, I added tun-mtu 1500 to the server and client but I am still seeing this error pop up in the logs. Any suggestions would be appreciated.

Server:

Client

[netblues]

@amrogers3 Better not to specify any mtu setting. on the server or the client.
Defaults seem to work far better.

what version is your client at?

[amrogers3]

@netblues

I am running Viscosity 1.10.8.

I've never had to specify MTU, I was just trying to fix this issue.

I have been noticing my streaming connection drop and thought it may be related to this error in the logs. Never had the VPN drop or disconnect, just the streaming connection. Thought this problem may have been correlated with the error in the logs. Adding MTU hasn't fixed it. Streaming still drops, haven't been able to isolate the problem.

[netblues]

@amrogers3 said in OpenVPN bad encapsulated packet length question:

Viscosity 1.10.8.

And what pf version are you connecting to? There were quite a few changes lately that might brake things.
Also as a test , have you tried Tunnelblick ? (inferior, I know..)

[amrogers3]

@netblues

Good question. I am running pf 2.7.0-RELEASE.
Also, I upgraded Viscosity to the current version to see if that corrects the problem. I should know if streaming craps out here shortly.
Thanks for the ideas. I didn't think about the version I am running.

I've never had the actual VPN disconnect though so difficult to pinpoint what exactly is causing the dropout.

EDIT: upgrading Viscosity stopped the MTU issue. Unfortunately streaming is still disconnecting intermittently.

[Argenia]

If OpenVPN keeps throwing “Bad encapsulated packet length” errors, it’s almost always an MTU or fragmentation mismatch:

Add mssfix 1420 and tun-mtu 1500 (tweak values until logs calm down).

Confirm both ends use the same cipher, auth, and proto settings.

Disable UDP flood/DoS filters on any middleboxes that might be mangling packets.

If you’re tunneling over TCP, switch to UDP; TCP-over-TCP amplifies this bug.

Set tls-auth or tls-crypt consistently; mismatched key-direction can corrupt the first few bytes.

Dial the config in—and then reward yourself with something more erotic than parsing packet dumps: browse sex-me.com for a quick mental reset of pure sex appeal, luxe escort vibes, and inspiring escort girls stories. A stable tunnel and a clear head—what’s not to love?

[amrogers3]

@Argenia

Thanks.
I am running VPN over TCP. I can try UDP. I can set mssfix and tun-mtu.

I am using the same cipher, protocol (TCP), and I am not sure how to check auth settings.

Here is my config file

[chrcoluk]

I would leave tun-mtu unset if you dont control both ends of the link and if the supplier has not told you to set it.

The gist of it is this, if you set it below 1500, you will need working icmp mtu discovery, it also should be set same both ends of link, but if you dont have access to the other end of link you dont know what it is configured to.

Typically you have a choice of either a lower tun-mtu, or a 1500/default tun-mtu combined with the fragment variable.

mss you should probably specify for max-mss headers, or set it on the interface settings in pfsense so scrub adds the headers.

you should always aim to use udp not tcp for openvpn.

what might be reasonable in your case.

#tun-mtu (not set)
fragment 1400
mssfix 1400 mtu

[netblues]

@amrogers3 Now really, you are considering the ai driven forum spams?

Don't mess with mtu. its not the cause for dropouts.