OpenVPN bad encapsulated packet length question

[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.

[amrogers3]

@chrcoluk
@netblues

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 mtu

So this in server and client or just server?

fragment 1400
mssfix 1400 mtu
max-mss headers

I 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

[chrcoluk]

@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.

[JKnott]

@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.

[netblues]

@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.

[amrogers3]

@netblues

UDP using port 443 ok?
Had no idea there was ai driven spam now. Thought that was one weird post.

Going to change it here to UDP over 443 and download a new client Viscosity bundle. Glad I posted about the TCP error. I learned a bit.

[netblues]

@amrogers3
Well, you can do that, technically all ports are the same , however quic will be using udp on 443.
And if it is a firewall that you need to bypass, udp won't cut it either.
Most todays firewals can do dpi and will detect openvpn on any port.

Unless you have other reasons, consider using the default 1194 port, or maybe 1193 or 1195, just to avoid random scans.
Obscurity is not security, and sometimes creates more issues than it solves, e.g. in a penetration test audit.

[stephenw10]

It should work using TCP on port 443. It's relatively common to use that combination to avoid restrictive networks.

But I too would advice starting out at something close to the default values setup by the wizard and make sure it works as expected there first.

[amrogers3]

@netblues
Thank you, I was using 443 because I sometimes log into my VPN through different networks and never know how restrictive firewalls will be and if they lockdown anything other than 80/443.

I wasn't trying to do security through obscurity, it was what port would be the most unrestricted. I figured 443 is pretty universal and would be allowed everywhere. My other option I was thinking about was 80. I was unaware of the speed degradation issues with TCP but it makes sense because all of the handshakes and overhead with TCP. Also, if DPI is utilized I guess it really doesn't matter what port I use, they can block openvpn if they see it, although it seems openvpn over encrypted connection be be harder to inspect??? maybe it would be the handshake that alerts?

Have you had any issues using 1194 through various networks?