OpenVPN bad encapsulated packet length question
-
@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?
-
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.
-
@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..) -
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.
-
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?
-
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
-
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 -
@amrogers3 Now really, you are considering the ai driven forum spams?
Don't mess with mtu. its not the cause for dropouts.
-
Thank you.
@netblues said in OpenVPN bad encapsulated packet length question:
ai driven forum spams
I am not sure what you mean by ai driven forum spams
Also, is this messing with mtu? mssfix 1400 mtuSo this in server and client or just server?
fragment 1400 mssfix 1400 mtu max-mss headersI connected to my VPN through a different network and it has not had any issues. Connection has been stable. The dropout must be due to something happening connecting through the other network. I am glad it is not my VPN server that is the issue. I will have to run that down later.
As for the Bad encapsulated packet error, I am still getting that.
Aug 2 14:29:19 openvpn 16903 202.93.141.18:61001 WARNING: Bad encapsulated packet length from peer (5635), 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...]I did some research on 202.93.141.18. It appears to be a malicious IP address.
I also see same packet length error from 149.50.96.5:54758, 45.135.232.205.From what I gathered, I do not think I can mitigate this error. The Bad encapsulated packet length error appears to be scanning activity. I am using 443 so probably very common from what I am reading.
If these will help block the error, I can give these a try.
fragment 1400 mssfix 1400 mtu max-mss headers -
@amrogers3 said in OpenVPN bad encapsulated packet length question:
max-mss headers
This reply seems to be the first post you made clear you also control the server.
I dont recall saying to put 'max-mss headers' as a line in the config.
'mssfix 1400 mtu' does not change the mtu, the mtu part just affects how it calculates what size mss to use.
Since you have access to the server it is easy for you to verify the MTU configured on both ends of the tunnel. This is basic nix commands to check MTU size, ifconfig on BSD and ip on linux.
-
@amrogers3 said in OpenVPN bad encapsulated packet length question:
I am running VPN over TCP. I can try UDP.
You shouldn't use TCP, unless you need it to get through a firewall, etc.. With TCP you wind up with double flow control, which can hit performance.
-
@amrogers3 said in OpenVPN bad encapsulated packet length question:
I am not sure what you mean by ai driven forum spams
A user giving random advice, just signed up and then suggesting sex related sites, is an advanced form of spam.
Now.. tell me that you don't also have a tls key.
And never ever use tcp for a vpn, unless you don't have any option.
